* Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
From: Jonathan Nieder @ 2013-02-01 22:38 UTC (permalink / raw)
To: Jongman Heo; +Cc: Jeff King, Junio C Hamano, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <27376267.797831359716377823.JavaMail.weblogic@epml01>
Jongman Heo wrote:
>> But it doesn't stimulate any prerequisites in make, which is weird.
>> What's in builtin/.depend/fetch.o.d?
[...]
> please see below~.
>
> $ cat builtin/.depend/fetch.o.d
> fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
That's the problem. See the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/185625/focus=185680
Currently when COMPUTE_HEADER_DEPENDENCIES=auto git tests for
dependency generation support by checking the output and exit status
from the following command:
$(CC) $(ALL_CFLAGS) -c -MF /dev/null -MMD -MP \
-x c /dev/null -o /dev/null 2>&1
Perhaps this can be improved? Even something as simple as a ccache
version test could presumably help a lot.
Hope that helps,
Jonathan
^ permalink raw reply
* [PATCH resend] Makefile: explicitly set target name for autogenerated dependencies
From: Jonathan Nieder @ 2013-02-01 22:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jongman Heo, Jeff King, Thomas Rast, git, Antoine Pelisse,
Nguyễn Thái Ngọc Duy
In-Reply-To: <27376267.797831359716377823.JavaMail.weblogic@epml01>
Date: Fri, 18 Nov 2011 17:23:24 -0600
"gcc -MF depfile -MMD -MP -c -o path/to/file.o" produces a makefile
snippet named "depfile" describing what files are needed to build the
target given by "-o". When ccache versions before v3.0pre0~187 (Fix
handling of the -MD and -MDD options, 2009-11-01) run, they execute
gcc -MF depfile -MMD -MP -E
instead to get the final content for hashing. Notice that the "-c -o"
combination is replaced by "-E". The result is a target name without
a leading path.
Thus when building git with such versions of ccache with
COMPUTE_HEADER_DEPENDENCIES enabled, the generated makefile snippets
define dependencies for the wrong target:
$ make builtin/add.o
GIT_VERSION = 1.7.8.rc3
* new build flags or prefix
CC builtin/add.o
$ head -1 builtin/.depend/add.o.d
add.o: builtin/add.c cache.h git-compat-util.h compat/bswap.h strbuf.h \
After a change in a header file, object files in a subdirectory are
not automatically rebuilt by "make":
$ touch cache.h
$ make builtin/add.o
$
Luckily we can prevent trouble by explicitly supplying the name of the
target to ccache and gcc, using the -MQ option. Do so.
Reported-and-tested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Reported-by: : 허종만 <jongman.heo@samsung.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 731b6a8..5a2e02d 100644
--- a/Makefile
+++ b/Makefile
@@ -973,7 +973,8 @@ endif
ifeq ($(COMPUTE_HEADER_DEPENDENCIES),auto)
dep_check = $(shell $(CC) $(ALL_CFLAGS) \
- -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+ -c -MF /dev/null -MQ /dev/null -MMD -MP \
+ -x c /dev/null -o /dev/null 2>&1; \
echo $$?)
ifeq ($(dep_check),0)
override COMPUTE_HEADER_DEPENDENCIES = yes
@@ -1843,7 +1844,7 @@ $(dep_dirs):
missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
dep_file = $(dir $@).depend/$(notdir $@).d
-dep_args = -MF $(dep_file) -MMD -MP
+dep_args = -MF $(dep_file) -MQ $@ -MMD -MP
ifdef CHECK_HEADER_DEPENDENCIES
$(error cannot compute header dependencies outside a normal build. \
Please unset CHECK_HEADER_DEPENDENCIES and try again)
--
1.8.1
^ permalink raw reply related
* Re: [PATCH] gitk-git/.gitignore: add rule for gitk-wish
From: Jonathan Nieder @ 2013-02-01 23:52 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Paul Mackerras, Christian Couder, Junio C Hamano
In-Reply-To: <1359456750-29342-1-git-send-email-artagnon@gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> 8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed
> "/gitk-git/gitk-wish" from the toplevel .gitignore, with the intent of
> moving it to gitk-git/.gitignore in a later patch. This was never
> realized.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> Minor patch, so I didn't bother sending it through Paul.
All gitk patches go through Paul's repo. I keep forgetting the
address, so I look it up each time.
$ git log -1 --oneline gitk-git/
9a6c84e Merge git://ozlabs.org/~paulus/gitk
Looks like this was fixed in the week since last pull.
http://thread.gmane.org/gmane.comp.version-control.git/214312
Paul, would it be safe for Junio to pull again?
Thanks,
Jonathan
^ permalink raw reply
* Re: Files excluded but not ignored
From: Ben Aveling @ 2013-02-01 23:54 UTC (permalink / raw)
To: Jason Wenger; +Cc: Junio C Hamano, git
In-Reply-To: <7v38ximyr2.fsf@alter.siamese.dyndns.org>
On 31/01/2013 3:17 AM, Junio C Hamano wrote:
> Jason Wenger <jcwenger@gmail.com> writes:
>
>> Trying to start up discussion of whether there would be merit to a "half-
>> ignored" state -- Files which are excluded from tracking, but which still
>> show in git status, and which are removed by git clean.
> I see no merit for "ignored and never to be tracked, but are still
> shown loudly in the untracked list" myself. Use cases for "ignored
> and never to be tracked, but not expendable" class were mentioned
> often in the past, though.
A new state seems over the top.
Jason, would adding a parameter to "git status" telling it to ignore all
.gitignores give you what you need?
Regards, Ben
^ permalink raw reply
* Re: [PATCH resend] Makefile: explicitly set target name for autogenerated dependencies
From: Jeff King @ 2013-02-02 0:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Jongman Heo, Thomas Rast, git, Antoine Pelisse,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20130201224519.GI12368@google.com>
On Fri, Feb 01, 2013 at 02:45:19PM -0800, Jonathan Nieder wrote:
> After a change in a header file, object files in a subdirectory are
> not automatically rebuilt by "make":
>
> $ touch cache.h
> $ make builtin/add.o
> $
>
> Luckily we can prevent trouble by explicitly supplying the name of the
> target to ccache and gcc, using the -MQ option. Do so.
Thanks, I missed the original thread last year, but this does look like
the same problem. The fixed version of ccache is a few years old, but
the OP did mention RHEL5, so that makes sense.
> missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
> dep_file = $(dir $@).depend/$(notdir $@).d
> -dep_args = -MF $(dep_file) -MMD -MP
> +dep_args = -MF $(dep_file) -MQ $@ -MMD -MP
This looks like a nice simple solution. The only downside would be if
-MQ is not supported by some gcc versions (in which case we would do
better to improve the "can we use computed dependencies" check, and
punish people on old ccache, not people on old gcc who otherwise could
work without -MQ).
As far as I can tell, though, -MQ came along with the other dependency
generation options in 2001:
http://gcc.gnu.org/news/dependencies.html
which means it's not a problem to rely on. So the patch looks good to
me.
-Peff
^ permalink raw reply
* Re: [PATCH] gitk-git/.gitignore: add rule for gitk-wish
From: Junio C Hamano @ 2013-02-02 0:33 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, Paul Mackerras, Christian Couder
In-Reply-To: <20130201235209.GK12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Looks like this was fixed in the week since last pull.
>
> http://thread.gmane.org/gmane.comp.version-control.git/214312
>
> Paul, would it be safe for Junio to pull again?
Thanks. I think I pulled a few days ago, and the result should have
already been propagated out.
commit 9a6c84e6e9078b0ef4fd2c50b200e8552a28c6fa
Merge: 070c57d a8b38d9
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jan 30 13:52:44 2013 -0800
Merge git://ozlabs.org/~paulus/gitk
* git://ozlabs.org/~paulus/gitk:
gitk: Ignore gitk-wish buildproduct
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
From: David Aguilar @ 2013-02-02 1:59 UTC (permalink / raw)
To: Sven Strickroth; +Cc: Sebastian Schuberth, git, Junio C Hamano, Jeff King
In-Reply-To: <510C229E.2050705@tu-clausthal.de>
On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> TortoiseMerge caused to whole
> argument instead of just the file name to be quoted
s/caused to whole/caused the whole/
I think this commit message is very nice. Is it too late to replace
the current patch with this one?
--
David
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
From: Junio C Hamano @ 2013-02-02 2:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Sven Strickroth, Sebastian Schuberth, git, Jeff King
In-Reply-To: <CAJDDKr4L3efzp6eBdTKQxXu8sfvyT91bK6MNh5OhXzWvms8TtQ@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth
> <sven.strickroth@tu-clausthal.de> wrote:
>> TortoiseMerge caused to whole
>> argument instead of just the file name to be quoted
>
> s/caused to whole/caused the whole/
>
> I think this commit message is very nice. Is it too late to replace
> the current patch with this one?
Haven't merged it to 'next'; I will replace with this, with a bit of
retitling to make it shorter.
commit 81ed7b9581f7eafb334824264abb492d85a5ffb8
Author: Sven Strickroth <sven.strickroth@tu-clausthal.de>
Date: Fri Feb 1 21:16:30 2013 +0100
mergetools: teach tortoisemerge to handle filenames with SP correctly
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused the whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces [2] (as written above).
[1] http://www.mingw.org/wiki/Posix_path_conversion
[2] https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Martin von Zweigbergk @ 2013-02-02 8:21 UTC (permalink / raw)
To: Phil Hord; +Cc: git, phil.hord, Neil Horman, Junio C Hamano
In-Reply-To: <510C2E10.1050403@cisco.com>
On Fri, Feb 1, 2013 at 1:05 PM, Phil Hord <hordp@cisco.com> wrote:
>
> This is probably right, but it is not exactly the case that caused my itch.
> I think my branch looked like [...]
That also makes sense. I'll add tests for both cases. Your patch makes
both of them pass.
>> # a---b---c
>> # \ \
>> # d \
>> # \ \
>> # e \
>> # \ \
>> # C---l
>>
>> As you say, your patch doesn't try to handle this case, but at least
>> the new behavior seems better. I think we would ideally want the
>> recreated 'l' to have only 'C' as parent in this case. Does that make
>> sense?
>
> This is not what I meant, but it is a very interesting corner case. I
> am not sure I have a solid opinion on what the result should be here.
Neither do I, so I'll just drop the test case. Thanks.
> Here is the corner case I was thinking of. I did not test this to see
> if this will happen, but I conceived that it might. Suppose you have
> this tree where
>
> # a---b---c
> # \
> # d---g---l
> # \ /
> # C
>
> where 'C' introduced the same changes as 'c'.
>
> When I execute 'git rebase -p l c', I expect that I will end up with
> this:
>
> # a---b---c---d---
> # \ \
> # ---g---l
>
> That is, 'C' gets skipped because it introduces the same changes already
> seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd',
> so 'g' now has two parents, both of whom are 'd'.
>
> I think it should collapse to this instead:
>
> # a---b---c---d---g---l
I think this is actually what you will get. But I think it will only
be linearized if the branch that should be dropped is the second
parent. I have two tests for this, but I need to simplify them a
little to see that that (parent number) is the only difference.
> I hope this is clear, but please let me know if I made it too confusing.
Very clear. Thanks.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Duy Nguyen @ 2013-02-02 9:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130201101503.GG30644@sigill.intra.peff.net>
On Fri, Feb 1, 2013 at 5:15 PM, Jeff King <peff@peff.net> wrote:
> The short-sha1 is a clever idea. Looks like it saves us on the order of
> 4MB for linux-2.6 (versus the full 20-byte sha1). Not as big as the
> savings we get from dropping the other 3 sha1's to uint32_t, but still
> not bad.
We could save another 4 bytes per commit by using 3 bytes for storing
.idx offsets. linux-2.6 only has 3M objects. It'll take many years for
big projects to reach 16M objects and need the fourth byte in
uint32_t.
> I guess the next steps in iterating on this would be:
>
> 1. splitting out the refactoring here into separate patches
>
> 2. squashing the cleaned-up bits into my patch 4/6
>
> 3. deciding whether this should go into a separate file or as part of
> index v3. Your offsets depend on the .idx file having a sorted sha1
> list. That is not likely to change, but it would still be nice to
> make sure they cannot get out of sync. I'm still curious what the
> performance impact is for mmap-ing N versus N+8MB.
4. Print some cache statistics in "count-objects -v"
>> The length of SHA-1 is chosen to be able to unambiguously identify any
>> cached commits. Full SHA-1 check is done after to catch false
>> positives.
>
> Just to be clear, these false positives come because the abbreviation is
> unambiguous within the packfile, but we might be looking for a commit
> that is not even in our pack, right?
It may even be ambiguous within the pack, say an octopus (i.e. not
cached) commit that shares the same sha-1 prefix with one of the
cached commits.
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Shawn Pearce @ 2013-02-02 10:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Duy Nguyen
In-Reply-To: <20130201091130.GB30644@sigill.intra.peff.net>
On Fri, Feb 1, 2013 at 1:11 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote:
>
>> On Tue, Jan 29, 2013 at 1:14 AM, Jeff King <peff@peff.net> wrote:
>> > Coupled with using compression level 0 for trees (which do not compress
>> > well at all, and yield only a 2% increase in size when left
>> > uncompressed), my "git rev-list --objects --all" time drops from ~40s to
>> > ~25s.
>>
>> This uhm.... is nice?
>>
>> But consider reachability bitmaps. ~40s to ~80ms. :-)
>
> Yeah, yeah. I'm working my way up to it. :)
:-)
> At this point I'm convinced that my 25s is about the best we will do for
> reachability analysis with a graph traversal. The repeated hashcmps to
> see that we've visited each node are starting to dominate. So the next
> obvious step is to try reachability bitmaps.
Yea, its hard to make a big N go fast when you still have a big N...
> I was hoping to iron out
> the "pack metadata goes here" issues with the commit cache stuff,
> though, as the actual cache implementation is quite simple (whereas the
> bitmap stuff is more on the complex side, but can build on the same
> metadata base).
Junio and I were talking about putting these in an index v3, below the
current tables where he thought there was a hole in v2. I am inclined
to agree with his comment elsewhere that we don't want 50 auxiliary
files next to a pack in 5 years.
But if we go that route I also suggested we append the index below the
pack file itself, so its a single file, and that we rename the file to
be SHA1(all-bits) not SHA1(sorted-object-list). Both steps make it
much safer to perform git gc on Windows while the repository is being
accessed.
>> Yup. I have also futzed with the one in JGit for quite a while now. I
>> pull some tricks there like making it a 2 level directory to reduce
>> the need to find a contiguous array of 8M entries when processing the
>> Linux kernel, and I try to preallocate the first level table based on
>> the number of objects in pack-*.idx files. But the bottleneck is
>> basically the cache lookups and hits, these happen like 100M times on
>> 2M objects, because its every link in nearly every tree.
>
> Right. I tried some multi-level tricks (and even a radix trie), but I
> couldn't get anything to beat the simple-and-stupid single hash table
> with linear probing.
O(1) lookup is hard for big N. Lets go shopping^Wcoding instead.
>> If we modified pack-objects' delta compressor for tree objects to only
>> generate delta instructions at tree record boundaries, a delta-encoded
>> tree can be processed without inflating the full content of that tree.
>> Because of the way deltas are created, "most" tree deltas should have
>> their delta base scanned by the object traversal before the delta is
>> considered. This means the tree delta just needs to consider the much
>> smaller records that are inserted into the base. We know these are
>> different SHA-1s than what was there before, so they are more likely
>> to be new to the lookup_object table.
>
> So sort of a magic shortcut tree diff you get while accessing the
> object. Neat idea.
Yes, exactly.
>> So the --objects traversal algorithm can change to get the delta base
>> SHA-1 and raw tree delta from the pack storage. Perform a
>> lookup_object on the base to see if it has been scanned. If it has,
>> just scan the delta insert instructions. If the base has not yet been
>> scanned, inflate the tree to its normal format and scan the entire
>> tree.
>
> This would not perform well if we hit the deltas before the bases. In
> general, though, our "use the larger as the base" heuristic should mean
> that our traversal hits the bases first.
It won't perform worse than the current code. And its actually the
time heuristic that should kick in here for trees. Most trees are
roughly the same size, or are only slightly bigger because a new
source file was added. More recent trees should appear earlier in the
delta window and be suitable candidates for older trees. So we should
get a large percentage of trees covered by this trick.
>> This is an approximation of what Nico and I were talking about doing
>> for pack v4. But doesn't require a file format change. :-)
>
> Yeah. It just needs to be very careful that the deltas it is looking at
> all fall on record boundaries, since we might get deltas generated by
> other versions of git. Can we necessarily identify that case for sure,
> though? I imagine a tree delta like that would look something like:
>
> delete bytes 100-120
> add 20 bytes at offset 100: \x12\x34\x56...
Of course we can't know without some flag. I assumed it was obvious we
would need to tag the pack somehow with extra metadata to say "every
tree delta in this pack is on a record boundary". That does make delta
reuse more complex as a tree delta can only be reused if it is coming
from a pack that has the same promise about record boundaries.
Otherwise the delta must be regenerated during packing.
> Without looking at the base object, and without knowing whether the
> delta was generated by our particular implementation, how can we be sure
> this is a sha1 replacement and not the renaming of part of a file? Or
> are you proposing some flag in the packfile to indicate "yes, this tree
> really was delta'd only at record boundaries"?
Yes, some sort of flag would be required on the pack. :-\
> It could be a big win, but it does seem quite complex and error-prone.
It is complex. But it seems so simple on the Internet...
> And it only helps with reachability, not regular traversals, so it's not
> very generic.
It should also help with path filter traversals. If we require the
deltas to be only at tree record boundaries then the mode and path
will be part of the delta, even if it is unmodified from the base
tree. A path filter can avoid scanning the base sections if its
already seen that base tree before. This could be a substantial
reduction in the number of tree records a path filter needs to examine
to get a `git log -- path` or `git blame path` completed.
> Which makes me think the bitmap route is a much better way
> to go.
Bitmaps discard a lot of useful data in favor of being really freaking
small. Colby was toying around with some other allocations of bitmaps
today. I think he managed to bitmap basically every commit in the
Linux kernel history since September... and its only 3M of data to
store on disk / cache in RAM. Very useful for serving fetch requests
to clients that are at varying points in history, but not so good for
doing things like new delta compression or path limited history
traversal.
<thought type="random" why="look at the Date header">
What if we built a bitmap for each path? Linux kernel history is
~41.5k paths. If the packer constructs a bitmap for each path that
sets a commit's bit if the path is impacted in that commit, you can do
some incredibly fast path traversal operations. Naive implementation
would cost around 1.7G of disk, but I wonder how well that set of maps
might compress.
</thought>
^ permalink raw reply
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Shawn Pearce @ 2013-02-02 10:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130201091431.GC30644@sigill.intra.peff.net>
On Fri, Feb 1, 2013 at 1:14 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
>
>> >> - System resource cost we incur by having to keep 50 file
>> >> descriptors open and maintaining 50 mmap windows will reduce by
>> >> 50 fold.
>> >
>> > I wonder how measurable that is (and if it matters on Linux versus less
>> > efficient platforms).
>>
>> It does matter. We know it has a negative impact on JGit even on Linux
>> for example. You don't want 300 packs in a repository. 50 might be
>> tolerable. 300 is not.
>
> I'd love to see numbers if you have them. It's not that I don't believe
> it is slower, but knowing _how much_ is important when thinking about
> what kind of performance increase we are looking to get (which in turn
> impacts how much effort to put into the repacking).
Never done a formal experiment. Just working from memory where 4 years
and 3 desks ago I got called because one of our Git servers was
struggling to keep up with user git fetch commands. Turns out the
repository had O(200) pack files. git gc that normally took only about
5 minutes took a hellva lot longer, like an hour or more.
The problem happened because the server was saving every push to a
pack and never exploding incoming packs to loose objects. This meant
the thin packs from the wire got delta bases appended to them.
pack-objects was looking at O(50) different alternatives for most
objects when trying to decide which one it should copy into the output
pack... for either a fetch/clone client, or the gc I was trying to run
to fix the repository.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-02-02 11:57 UTC (permalink / raw)
To: git
In-Reply-To: <20130131193844.GA14460@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
On Thu, 31 Jan 2013 14:38:45 -0500 Jeff King <peff@peff.net> wrote:
JK> On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
>> Jeff, is there a way for git-credential to currently support
>> authinfo/netrc parsing? I assume that's the right way, instead of using
>> Michal's proposal to parse internally?
>>
>> I'd like to add that, plus support for the 'string' and "string"
>> formats, and authinfo.gpg decoding through GPG. I'd write it in Perl,
>> if there's a choice.
JK> Yes, you could write a credential helper that understands netrc and
JK> friends; git talks to the helpers over a socket, so there is no problem
JK> with writing it in Perl. See Documentation/technical/api-credentials.txt
JK> for an overview, or the sample implementation in credential-store.c for a
JK> simple example.
I wrote a Perl credential helper for netrc parsing which is pretty
robust, has built-in docs with -h, and doesn't depend on external
modules. The netrc parser regex was stolen from Net::Netrc.
It will by default use ~/.authinfo.gpg, ~/.netrc.gpg, ~/.authinfo, and
~/.netrc (whichever is found first) and this can be overridden with -f.
If the file name ends with ".gpg", it will run "gpg --decrypt FILE" and
use the output. So non-interactively, that could hang if GPG was
waiting for input. Does Git handle that, or should I check for a TTY?
Take a look at the proposed patch and let me know if it's usable, if you
need a formal copyright assignment, etc.
Thanks
Ted
[-- Attachment #2: Add git-credential-netrc --]
[-- Type: text/x-patch, Size: 6016 bytes --]
commit 3d28bc2a610ebcc988eba5443d82d0ded92c24bc
Author: Ted Zlatanov <tzz@lifelogs.com>
Date: Sat Feb 2 06:42:13 2013 -0500
Add contrib/credentials/netrc with GPG support
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
new file mode 100755
index 0000000..92fc306
--- /dev/null
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -0,0 +1,242 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Data::Dumper;
+
+use Getopt::Long;
+use File::Basename;
+
+my $VERSION = "0.1";
+
+my %options = (
+ help => 0,
+ debug => 0,
+
+ # identical token maps, e.g. host -> host, will be inserted later
+ tmap => {
+ port => 'protocol',
+ machine => 'host',
+ path => 'path',
+ login => 'username',
+ user => 'username',
+ password => 'password',
+ }
+ );
+
+foreach my $v (values %{$options{tmap}})
+{
+ $options{tmap}->{$v} = $v;
+}
+
+foreach my $suffix ('.gpg', '')
+{
+ foreach my $base (qw/authinfo netrc/)
+ {
+ my $file = glob("~/.$base$suffix");
+ next unless (defined $file && -f $file);
+ $options{file} = $file ;
+ }
+}
+
+Getopt::Long::Configure("bundling");
+
+# TODO: maybe allow the token map $options{tmap} to be configurable.
+GetOptions(\%options,
+ "help|h",
+ "debug|d",
+ "file|f=s",
+ );
+
+if ($options{help})
+{
+ my $shortname = basename($0);
+ $shortname =~ s/git-credential-//;
+
+ print <<EOHIPPUS;
+
+$0 [-f AUTHFILE] [-d] get
+
+Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+
+Options:
+ -f AUTHFILE: specify a netrc-style file
+ -d: turn on debugging
+
+To enable (note that Git will prepend "git-credential-" to the helper
+name and look for it in the path):
+
+ git config credential.helper '$shortname -f AUTHFILE'
+
+And if you want lots of debugging info:
+
+ git config credential.helper '$shortname -f AUTHFILE -d'
+
+Only "get" mode is supported by this credential helper. It opens
+AUTHFILE and looks for entries that match the requested search
+criteria:
+
+ 'port|protocol':
+ The protocol that will be used (e.g., https). (protocol=X)
+
+ 'machine|host':
+ The remote hostname for a network credential. (host=X)
+
+ 'path':
+ The path with which the credential will be used. (path=X)
+
+ 'login|user|username':
+ The credential’s username, if we already have one. (username=X)
+
+Thus, when we get "protocol=https\nusername=tzz", this credential
+helper will look for lines in AUTHFILE that match
+
+port https login tzz
+
+OR
+
+protocol https login tzz
+
+OR... etc. acceptable tokens as listed above. Any unknown tokens are
+simply ignored.
+
+Then, the helper will print out whatever tokens it got from the line,
+including "password" tokens, mapping e.g. "port" back to "protocol".
+
+The first matching line is used. Tokens can be quoted as 'STRING' or
+"STRING".
+
+No caching is performed by this credential helper.
+
+EOHIPPUS
+
+ exit;
+}
+
+my $mode = shift @ARGV;
+
+# credentials may get 'get', 'store', or 'erase' as parameters but
+# only acknowledge 'get'
+die "Syntax: $0 [-f AUTHFILE] [-d] get" unless defined $mode;
+
+# only support 'get' mode
+exit unless $mode eq 'get';
+
+my $debug = $options{debug};
+my $file = $options{file};
+
+die "Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE"
+ unless defined $file;
+
+die "Sorry, the specified netrc $file is not accessible"
+ unless -f $file;
+
+if ($file =~ m/\.gpg$/)
+{
+ $file = "gpg --decrypt $file|";
+}
+
+my @data = load($file);
+chomp @data;
+
+die "Sorry, we could not load data from [$file]"
+ unless (scalar @data);
+
+# the query
+my %q;
+
+foreach my $v (values %{$options{tmap}})
+{
+ undef $q{$v};
+}
+
+while (<STDIN>)
+{
+ next unless m/([a-z]+)=(.+)/;
+
+ my ($token, $value) = ($1, $2);
+ die "Unknown search token $1" unless exists $q{$token};
+ $q{$token} = $value;
+}
+
+# build reverse token map
+my %rmap;
+foreach my $k (keys %{$options{tmap}})
+{
+ push @{$rmap{$options{tmap}->{$k}}}, $k;
+}
+
+# there are CPAN modules to do this better, but we want to avoid
+# dependencies and generally, complex netrc-style files are rare
+
+if ($debug)
+{
+ foreach (sort keys %q)
+ {
+ printf STDERR "searching for %s = %s\n",
+ $_, $q{$_} || '(any value)';
+ }
+}
+
+LINE: foreach my $line (@data)
+{
+
+ print STDERR "line [$line]\n" if $debug;
+ my @tok;
+ # gratefully stolen from Net::Netrc
+ while (length $line &&
+ $line =~ s/^("((?:[^"]+|\\.)*)"|((?:[^\\\s]+|\\.)*))\s*//)
+ {
+ (my $tok = $+) =~ s/\\(.)/$1/g;
+ push(@tok, $tok);
+ }
+
+ my %tokens;
+ while (@tok)
+ {
+ my ($k, $v) = (shift @tok, shift @tok);
+ next unless defined $v;
+ next unless exists $options{tmap}->{$k};
+ $tokens{$options{tmap}->{$k}} = $v;
+ }
+
+ foreach my $check (sort keys %q)
+ {
+ if (exists $tokens{$check} && defined $q{$check})
+ {
+ print STDERR "comparing [$tokens{$check}] to [$q{$check}] in line [$line]\n" if $debug;
+ next LINE unless $tokens{$check} eq $q{$check};
+ }
+ else
+ {
+ print STDERR "we could not find [$check] but it's OK\n" if $debug;
+ }
+ }
+
+ print STDERR "line has passed all the search checks\n" if $debug;
+ foreach my $token (sort keys %rmap)
+ {
+ print STDERR "looking for useful token $token\n" if $debug;
+ next unless exists $tokens{$token}; # did we match?
+
+ foreach my $rctoken (@{$rmap{$token}})
+ {
+ next if defined $q{$rctoken}; # don't re-print given tokens
+ }
+
+ print STDERR "FOUND: $token=$tokens{$token}\n" if $debug;
+ printf "%s=%s\n", $token, $tokens{$token};
+ }
+
+ last;
+}
+
+sub load
+{
+ my $file = shift;
+ # this supports pipes too
+ my $io = new IO::File($file) or die "Could not open $file: $!\n";
+
+ return <$io>; # whole file
+}
^ permalink raw reply related
* Re: [PATCH 4/6] introduce a commit metapack
From: Junio C Hamano @ 2013-02-02 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, git, Duy Nguyen
In-Reply-To: <20130201094237.GE30644@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote:
> ...
>> If we are going to change the index to support extension sections and
>> I have to modify JGit to grok this new format, it needs to be index v3
>> not index v2. If we are making index v3 we should just put index v3 on
>> the end of the pack file.
>
> I'm not sure what you mean by your last sentence here.
I am not Shawn, but here is a summary of what I think I discussed
with him in person, lest I forget.
You could imagine that a new pack system (from pack-objects,
index-pack down to read_packed_sha1() call) that works with a
packfile that
* is a single file, whose name is pack-$SHA1.$sfx (where $sfx
is something other than 'pack', perhaps);
* has the pack data stream, including the concluding checksum of
the stream contents at the end, at the beginning of the file; and
* has the index v3 data blob appended to the pack data stream.
The pack data is streamed over the wire exactly the same way,
interoperating with existing software. When receiving, the new
index-pack can read such a pack stream and add index at the end.
When re-indexing an existing pack (think: upgrading existing
packfiles from the current system), the index-pack can read from the
packfile and do what it does currently (notably, it knows where the
pack stream ends and can stop reading at that point, so even if you
feed the new pack to it, it will stop at the end of the pack data,
ignoring the index v3 already at the end of the input).
One potential advantage of using a single file, instead of the
primary .pack file with 3 (or 47) auxiliary files, is that it lets
you repack without having to deal with this sequence, which happens
currently when you repack:
* create a new .pack file and the corresponding auxiliary files
under temporary filename;
* move existing pack files that describe the same set of objects
away;
* rename these new files, one at a time, to their final name,
making sure that you rename .idx the last, because that happens
to be the key to the pack aware programs.
Instead you can rename only one thing (the new one) to the final
name (possibly atomically replacing the existing one). With the
current system, when you need to replace a pack with a new pack with
the same packname (e.g. you repack everything with a better pack
parameter in a repository that has everything packed into one),
there is a very small window other concurrent users will not find
the object data between the time when you rename the old ones away
and the time when you move the new ones in. The hairly logic
between "Ok we have prepared all new packfiles" and "End of pack
replacement" can be done with a single rename(2) of the new packfile
(which contains everything) to the final name, which atomically
replaces the old one.
This will become even safer if we picked $SHA1 (the name of the
packfile) to represent the hash of the whole thing, not the hash of
the sorted object names in the pack, as that will let us know there
is no need to even "replace" the files.
^ permalink raw reply
* [PATCH] Handle path completion and colon for tcsh script
From: Marc Khouzam @ 2013-02-02 19:43 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: manlio.perillo@gmail.com, gitster@pobox.com
Recent enhancements to git-completion.bash provide
intelligent path completion for git commands. Such
completions do not add the '/' at the end of directories
for recent versions of bash. However, the '/' is needed
by tcsh, so we must tell the bash script to append it
by using a compatibility method available for older
bash versions.
Also, tcsh does not handle the colon as a completion
separator so we remove it from the list of separators.
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
---
Hi,
Here is the update for tcsh completion which is needed to handle
the cool new path completion feature just pushed to 'next'.
Also, Manlio reported that tcsh completion was broken when using
the colon, and this patch fixes the issue.
I haven't quite figured out the process to indicate which branch
a patch is meant for. Do I just mention it in the email? Or are all
patches meant for the 'pu' branch? In this case, 'pu' or 'next'
would be appropriate.
Thanks!
Marc
contrib/completion/git-completion.tcsh | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/contrib/completion/git-completion.tcsh b/contrib/completion/git-completion.tcsh
index 3e3889f..eaacaf0 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -52,6 +52,18 @@ cat << EOF > ${__git_tcsh_completion_script}
source ${__git_tcsh_completion_original_script}
+# Remove the colon as a completion separator because tcsh cannot handle it
+COMP_WORDBREAKS=\${COMP_WORDBREAKS//:}
+
+# For file completion, tcsh needs the '/' to be appended to directories.
+# By default, the bash script does not do that.
+# We can achieve this by using the below compatibility
+# method of the git-completion.bash script.
+__git_index_file_list_filter ()
+{
+ __git_index_file_list_filter_compat
+}
+
# Set COMP_WORDS in a way that can be handled by the bash script.
COMP_WORDS=(\$2)
--
1.8.1.367.g8e14972.dirty
^ permalink raw reply related
* Re: [PATCH] Handle path completion and colon for tcsh script
From: Junio C Hamano @ 2013-02-02 20:10 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git@vger.kernel.org, manlio.perillo@gmail.com
In-Reply-To: <E59706EF8DB1D147B15BECA3322E4BDC09AA38@eusaamb103.ericsson.se>
Marc Khouzam <marc.khouzam@ericsson.com> writes:
> Recent enhancements to git-completion.bash provide
> intelligent path completion for git commands. Such
> completions do not add the '/' at the end of directories
> for recent versions of bash.
> ...
> Here is the update for tcsh completion which is needed to handle
> the cool new path completion feature just pushed to 'next'.
>
> Also, Manlio reported that tcsh completion was broken when using
> the colon, and this patch fixes the issue.
>
> I haven't quite figured out the process to indicate which branch
> a patch is meant for. Do I just mention it in the email?
Yes, instead of wondering "Do I mention it here?", saying "This
should come on top of Manlio's completion update." is good.
But I have to wonder if this is sweeping a problem under the rug.
Shouldn't the completion for bash users end completed directory name
with '/', even if we didn't have to worry about tcsh?
^ permalink raw reply
* [PATCH] Honor configure's htmldir switch
From: Christoph J. Thompson @ 2013-02-02 21:25 UTC (permalink / raw)
To: git
Honor autoconf's --htmldir switch. This allows relocating HTML docs
straight from the configure script.
Signed-off-by: Christoph J. Thompson <cjsthompson@gmail.com>
---
config.mak.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.in b/config.mak.in
index e8a9bb4..d7c49cd 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -19,6 +19,7 @@ template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
mandir = @mandir@
+htmldir = @htmldir@
srcdir = @srcdir@
VPATH = @srcdir@
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] Honor configure's htmldir switch
From: Junio C Hamano @ 2013-02-03 1:27 UTC (permalink / raw)
To: Christoph J. Thompson; +Cc: git
In-Reply-To: <20130202212504.GA16412@gmail.com>
"Christoph J. Thompson" <cjsthompson@gmail.com> writes:
> Honor autoconf's --htmldir switch. This allows relocating HTML docs
> straight from the configure script.
>
>
> Signed-off-by: Christoph J. Thompson <cjsthompson@gmail.com>
> ---
> config.mak.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/config.mak.in b/config.mak.in
> index e8a9bb4..d7c49cd 100644
> --- a/config.mak.in
> +++ b/config.mak.in
> @@ -19,6 +19,7 @@ template_dir = @datadir@/git-core/templates
> sysconfdir = @sysconfdir@
>
> mandir = @mandir@
> +htmldir = @htmldir@
>
> srcdir = @srcdir@
> VPATH = @srcdir@
Hmph, in the output of "git grep -e mandir config.mak.in", I see
export exec_prefix mandir
which makes me wonder if we should either export htmldir as well, or
drop mandir from the "export". Off-hand, I am not sure which is the
right way, but in either case the inconsistency disturbs me.
Thanks.
^ permalink raw reply
* [RFC/PATCH] config.mak.in: remove unused definitions
From: Junio C Hamano @ 2013-02-03 1:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
When 5566771 (autoconf: Use autoconf to write installation
directories to config.mak.autogen, 2006-07-03) introduced support
for autoconf generated config.mak file, it added a few "export",
in addition to definitions of srcdir and VPATH.
These "export" logically does not belong there. The common make
variables like mandir, prefix, etc, should be exported to submakes
for people who use config.mak and people who use config.mak.autogen
the same way, so if we want to get these exported, that should be in
the main Makefile, no?
We do use mandir and htmldir in Documentation/Makefile, so let's
add export for them in the main Makefile instead.
We may eventually want to support VPATH, and srcdir may turn out to
be useful for that purpose, but right now nobody uses it, so it is
useless to define them in this file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* As everybody knows, I do not use autoconf/configure, so this may
be breaking things for those who do. Comments, objectsions, and
general education etc. are very much appreciated.
Makefile | 2 +-
config.mak.in | 7 -------
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 731b6a8..e946402 100644
--- a/Makefile
+++ b/Makefile
@@ -384,7 +384,7 @@ lib = lib
# DESTDIR =
pathsep = :
-export prefix bindir sharedir sysconfdir gitwebdir localedir
+export prefix bindir sharedir mandir htmldir sysconfdir gitwebdir localedir
CC = cc
AR = ar
diff --git a/config.mak.in b/config.mak.in
index e8a9bb4..f87c18c 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -11,7 +11,6 @@ DIFF = @DIFF@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
prefix = @prefix@
-exec_prefix = @exec_prefix@
bindir = @bindir@
gitexecdir = @libexecdir@/git-core
datarootdir = @datarootdir@
@@ -19,9 +18,3 @@ template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
mandir = @mandir@
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-export exec_prefix mandir
-export srcdir VPATH
^ permalink raw reply related
* Re: [PATCH] Honor configure's htmldir switch
From: Junio C Hamano @ 2013-02-03 3:31 UTC (permalink / raw)
To: Christoph Thompson; +Cc: git
In-Reply-To: <CA+7ShCrB_1Q=aKw5sP5hLkM1o0v-P1WR5+1iL983X7WQCHP=oQ@mail.gmail.com>
Christoph Thompson <cjsthompson@gmail.com> writes:
> Will the --htmldir switch still work by exporting mandir and htmldir from
> the Makefile instead of
> config.mak.in ?
It should not make a difference where you export them from. Lets
see...
-- cut here -- >8 -- cut here --
$ cat >Makefile <<\EOF
# The default target of this Makefile is ...
all:
var1 = one
var2 = two
var5 = five
var7 = seven
var8 = eight
include config.mak
export var2 var4 var8
all:
env | grep '^var'
EOF
$ cat >config.mak <<\EOF
var3 = three
var4 = four
var6 = six
var7 = siete
var8 = ocho
export var1 var3 var7
EOF
$ make
env | grep '^var'
var1=one
var3=three
var2=two
var4=four
var7=siete
var8=ocho
-- cut here -- 8< -- cut here --
Everything behaves as I expect, I think.
^ permalink raw reply
* Re: [PATCH] Honor configure's htmldir switch
From: Junio C Hamano @ 2013-02-03 4:50 UTC (permalink / raw)
To: Christoph Thompson; +Cc: git
In-Reply-To: <CA+7ShCqxDKHw0dzC6ASH=qpjG_MP-QZxOyMxQmoTKhXc7ZYHuA@mail.gmail.com>
Christoph Thompson <cjsthompson@gmail.com> writes:
[administrivia: why do you keep dropping git@vger from Cc???]
> I was under the impression that configure passed on the value of it's
> --htmldir switch by doing
> some substitution work like the following :
>
> sed 's|@htmldir@|$(htmldir)|g' config.mak.in > config.mak
The information flow goes more like this:
* configure.ac is used to generate the configure script with
autoconf;
* configure script is driven by the user and finds the system
characteristics and user's wish;
* what configure found out is used to generate config.mak.autogen,
using config.mak.in as a template; and then
* the primary Makefile reads config.mak.autogen if exists and then
config.mak if exists.
Note that use of ./configure is entirely optional for the build
system of Git. You can give parameters to make on its command line
(without having config.mak or config.mak.autogen), or you can give
these parameters in handwritten config.mak and just say "make".
You can also use ./configure to write some reasonable values in
config.mak.autogen, but if ./configure guesses things incorrrectly,
you can still override them in your handwritten config.mak exactly
because it is read after config.mak.autogen is read by Makefile.
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: Junio C Hamano @ 2013-02-03 5:44 UTC (permalink / raw)
To: David Aguilar, John Keeping; +Cc: git
In-Reply-To: <7vwqur8z4s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Regarding these two topics....
> * da/mergetool-docs (2013-01-30) 7 commits
> - doc: generate a list of valid merge tools
> - mergetool--lib: list user configured tools in '--tool-help'
> - fixup! doc: generate a list of valid merge tools
> - fixup! mergetool--lib: add functions for finding available tools
> - mergetool--lib: add functions for finding available tools
> - mergetool--lib: improve the help text in guess_merge_tool()
> - mergetool--lib: simplify command expressions
> (this branch uses jk/mergetool.)
>
> Build on top of the clean-up done by jk/mergetool and automatically
> generate the list of mergetool and difftool backends the build
> supports to be included in the documentation.
>
> Will merge to 'next', after squashing the fixup! commits from John
> Keeping.
>
>
> * jk/mergetool (2013-01-28) 8 commits
> - mergetools: simplify how we handle "vim" and "defaults"
> - mergetool--lib: don't call "exit" in setup_tool
> - mergetool--lib: improve show_tool_help() output
> - mergetools/vim: remove redundant diff command
> - git-difftool: use git-mergetool--lib for "--tool-help"
> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
> - git-mergetool: remove redundant assignment
> - git-mergetool: move show_tool_help to mergetool--lib
> (this branch is used by da/mergetool-docs.)
>
> Cleans up mergetool/difftool combo.
>
> This is looking ready for 'next'.
Do the tips of these two topics look reasonable to both of you, or
are there anything you sent but I missed?
^ permalink raw reply
* [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Nguyễn Thái Ngọc Duy @ 2013-02-03 5:48 UTC (permalink / raw)
To: git; +Cc: Jonathan Niedier, Nguyễn Thái Ngọc Duy
In-Reply-To: <1359461574-24529-1-git-send-email-pclouds@gmail.com>
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
- Incorporate Jonathan's version of checking
- Show original branch name, e.g. "(rebasing foo)", when possible
builtin/branch.c | 40 +++++++++++++++++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ea6498b..40f20ad 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -550,6 +550,44 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct stat st;
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf result = STRBUF_INIT;
+ int bisect = 0;
+ int ret;
+ if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
+ ret = strbuf_read_file(&sb, git_path("rebase-merge/head-name"), 0);
+ else if (!access(git_path("rebase-apply/rebasing"), F_OK))
+ ret = strbuf_read_file(&sb, git_path("rebase-apply/head-name"), 0);
+ else if (!access(git_path("BISECT_LOG"), F_OK)) {
+ ret = strbuf_read_file(&sb, git_path("BISECT_START"), 0);
+ bisect = 1;
+ } else
+ return xstrdup(_("(no branch)"));
+
+ if (ret <= 0)
+ return xstrdup(bisect ? _("(bisecting)") : _("_(rebasing)"));
+
+ while (sb.len && sb.buf[sb.len - 1] == '\n')
+ strbuf_setlen(&sb, sb.len - 1);
+
+ if (bisect) {
+ unsigned char sha1[20];
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(&result, _("(bisecting)"));
+ else
+ strbuf_addf(&result, _("(bisecting %s)"), sb.buf);
+ } else {
+ if (!prefixcmp(sb.buf, "refs/heads/"))
+ strbuf_addf(&result, _("(rebasing %s)"), sb.buf + 11);
+ else
+ strbuf_addstr(&result, _("(rebasing)"));
+ }
+ strbuf_release(&sb);
+ return strbuf_detach(&result, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +595,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
struct ref_item item;
- item.name = xstrdup(_("(no branch)"));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..90968d5 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
cp .git/BISECT_START saved &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
- test_i18ngrep "* (no branch)" branch.output > /dev/null &&
+ test_i18ngrep "* (bisecting other)" branch.output > /dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
--
1.8.1.1.459.g5970e58
^ permalink raw reply related
* [PATCH v3] status: show the branch name if possible in in-progress info
From: Nguyễn Thái Ngọc Duy @ 2013-02-03 5:53 UTC (permalink / raw)
To: git
Cc: Matthieu Moy, Jonathan Niedier, Junio C Hamano,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359471493-32531-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
- avoid hardcoding SHA-1 in t7512
- I did not act on Junio's --format=%s idea because frankly I don't
care much about the "on 'xxx'" part. It was Matthieu's idea and he
did not make any comments on --format=%s
t/t7512-status-help.sh | 87 +++++++++++++++++++++++++++-------------------
wt-status.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++----
wt-status.h | 2 ++
3 files changed, 142 insertions(+), 41 deletions(-)
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index b3f6eb9..51ab894 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -73,10 +73,11 @@ test_expect_success 'prepare for rebase conflicts' '
test_expect_success 'status when rebase in progress before resolving conflicts' '
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD^^) &&
test_must_fail git rebase HEAD^ --onto HEAD^^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''.
# (fix conflicts and then run "git rebase --continue")
# (use "git rebase --skip" to skip this patch)
# (use "git rebase --abort" to check out the original branch)
@@ -97,12 +98,13 @@ test_expect_success 'status when rebase in progress before resolving conflicts'
test_expect_success 'status when rebase in progress before rebase --continue' '
git reset --hard rebase_conflicts &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD^^) &&
test_must_fail git rebase HEAD^ --onto HEAD^^ &&
echo three >main.txt &&
git add main.txt &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''.
# (all conflicts fixed: run "git rebase --continue")
#
# Changes to be committed:
@@ -130,10 +132,11 @@ test_expect_success 'prepare for rebase_i_conflicts' '
test_expect_success 'status during rebase -i when conflicts unresolved' '
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short rebase_i_conflicts) &&
test_must_fail git rebase -i rebase_i_conflicts &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''.
# (fix conflicts and then run "git rebase --continue")
# (use "git rebase --skip" to skip this patch)
# (use "git rebase --abort" to check out the original branch)
@@ -154,11 +157,12 @@ test_expect_success 'status during rebase -i when conflicts unresolved' '
test_expect_success 'status during rebase -i after resolving conflicts' '
git reset --hard rebase_i_conflicts_second &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short rebase_i_conflicts) &&
test_must_fail git rebase -i rebase_i_conflicts &&
git add main.txt &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''.
# (all conflicts fixed: run "git rebase --continue")
#
# Changes to be committed:
@@ -182,10 +186,11 @@ test_expect_success 'status when rebasing -i in edit mode' '
FAKE_LINES="1 edit 2" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~2) &&
git rebase -i HEAD~2 &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -206,11 +211,12 @@ test_expect_success 'status when splitting a commit' '
FAKE_LINES="1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -236,11 +242,12 @@ test_expect_success 'status after editing the last commit with --amend during a
FAKE_LINES="1 2 edit 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "foo" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''amend_last'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -265,11 +272,12 @@ test_expect_success 'status: (continue first edit) second edit' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git rebase --continue &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -285,12 +293,13 @@ test_expect_success 'status: (continue first edit) second edit and split' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git rebase --continue &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -311,12 +320,13 @@ test_expect_success 'status: (continue first edit) second edit and amend' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git rebase --continue &&
git commit --amend -m "foo" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -332,12 +342,13 @@ test_expect_success 'status: (amend first edit) second edit' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "a" &&
git rebase --continue &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -353,13 +364,14 @@ test_expect_success 'status: (amend first edit) second edit and split' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "b" &&
git rebase --continue &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -380,13 +392,14 @@ test_expect_success 'status: (amend first edit) second edit and amend' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "c" &&
git rebase --continue &&
git commit --amend -m "d" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -402,14 +415,15 @@ test_expect_success 'status: (split first edit) second edit' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
git add main.txt &&
git commit -m "e" &&
git rebase --continue &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -425,15 +439,16 @@ test_expect_success 'status: (split first edit) second edit and split' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
git add main.txt &&
git commit --amend -m "f" &&
git rebase --continue &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -454,15 +469,16 @@ test_expect_success 'status: (split first edit) second edit and amend' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
git add main.txt &&
git commit --amend -m "g" &&
git rebase --continue &&
git commit --amend -m "h" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -558,7 +574,7 @@ test_expect_success 'status when bisecting' '
git bisect good one_bisect &&
cat >expected <<-\EOF &&
# Not currently on any branch.
- # You are currently bisecting.
+ # You are currently bisecting branch '\''bisect'\''.
# (use "git bisect reset" to get back to the original branch)
#
nothing to commit (use -u to show untracked files)
@@ -577,10 +593,11 @@ test_expect_success 'status when rebase conflicts with statushints disabled' '
test_commit two_statushints main.txt two &&
test_commit three_statushints main.txt three &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD^^) &&
test_must_fail git rebase HEAD^ --onto HEAD^^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''statushints_disabled'\'' on '\''$ONTO'\''.
#
# Unmerged paths:
# both modified: main.txt
diff --git a/wt-status.c b/wt-status.c
index d7cfe8f..983e2f4 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -872,7 +872,14 @@ static void show_rebase_in_progress(struct wt_status *s,
struct stat st;
if (has_unmerged(s)) {
- status_printf_ln(s, color, _("You are currently rebasing."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently rebasing."));
if (advice_status_hints) {
status_printf_ln(s, color,
_(" (fix conflicts and then run \"git rebase --continue\")"));
@@ -882,17 +889,38 @@ static void show_rebase_in_progress(struct wt_status *s,
_(" (use \"git rebase --abort\" to check out the original branch)"));
}
} else if (state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
- status_printf_ln(s, color, _("You are currently rebasing."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently rebasing."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (all conflicts fixed: run \"git rebase --continue\")"));
} else if (split_commit_in_progress(s)) {
- status_printf_ln(s, color, _("You are currently splitting a commit during a rebase."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently splitting a commit while rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently splitting a commit during a rebase."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (Once your working directory is clean, run \"git rebase --continue\")"));
} else {
- status_printf_ln(s, color, _("You are currently editing a commit during a rebase."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently editing a commit while rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently editing a commit during a rebase."));
if (advice_status_hints && !s->amend) {
status_printf_ln(s, color,
_(" (use \"git commit --amend\" to amend the current commit)"));
@@ -923,16 +951,57 @@ static void show_bisect_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- status_printf_ln(s, color, _("You are currently bisecting."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently bisecting branch '%s'."),
+ state->branch);
+ else
+ status_printf_ln(s, color,
+ _("You are currently bisecting."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (use \"git bisect reset\" to get back to the original branch)"));
wt_status_print_trailer(s);
}
+/*
+ * Extract branch information from rebase/bisect
+ */
+static void read_and_strip_branch(struct strbuf *sb,
+ const char **branch,
+ const char *path)
+{
+ unsigned char sha1[20];
+
+ strbuf_reset(sb);
+ if (strbuf_read_file(sb, git_path("%s", path), 0) <= 0)
+ return;
+
+ while (sb->len && sb->buf[sb->len - 1] == '\n')
+ strbuf_setlen(sb, sb->len - 1);
+ if (!sb->len)
+ return;
+ if (!prefixcmp(sb->buf, "refs/heads/"))
+ *branch = sb->buf + strlen("refs/heads/");
+ else if (!prefixcmp(sb->buf, "refs/"))
+ *branch = sb->buf;
+ else if (!get_sha1_hex(sb->buf, sha1)) {
+ const char *abbrev;
+ abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
+ strbuf_reset(sb);
+ strbuf_addstr(sb, abbrev);
+ *branch = sb->buf;
+ } else if (!strcmp(sb->buf, "detached HEAD")) /* rebase */
+ ;
+ else /* bisect */
+ *branch = sb->buf;
+}
+
static void wt_status_print_state(struct wt_status *s)
{
const char *state_color = color(WT_STATUS_HEADER, s);
+ struct strbuf branch = STRBUF_INIT;
+ struct strbuf onto = STRBUF_INIT;
struct wt_status_state state;
struct stat st;
@@ -947,17 +1016,28 @@ static void wt_status_print_state(struct wt_status *s)
state.am_empty_patch = 1;
} else {
state.rebase_in_progress = 1;
+ read_and_strip_branch(&branch, &state.branch,
+ "rebase-apply/head-name");
+ read_and_strip_branch(&onto, &state.onto,
+ "rebase-apply/onto");
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
state.rebase_interactive_in_progress = 1;
else
state.rebase_in_progress = 1;
+ read_and_strip_branch(&branch, &state.branch,
+ "rebase-merge/head-name");
+ read_and_strip_branch(&onto, &state.onto,
+ "rebase-merge/onto");
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
state.cherry_pick_in_progress = 1;
}
- if (!stat(git_path("BISECT_LOG"), &st))
+ if (!stat(git_path("BISECT_LOG"), &st)) {
state.bisect_in_progress = 1;
+ read_and_strip_branch(&branch, &state.branch,
+ "BISECT_START");
+ }
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -969,6 +1049,8 @@ static void wt_status_print_state(struct wt_status *s)
show_cherry_pick_in_progress(s, &state, state_color);
if (state.bisect_in_progress)
show_bisect_in_progress(s, &state, state_color);
+ strbuf_release(&branch);
+ strbuf_release(&onto);
}
void wt_status_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 236b41f..81e1dcf 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,6 +79,8 @@ struct wt_status_state {
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ const char *branch;
+ const char *onto;
};
void wt_status_prepare(struct wt_status *s);
--
1.8.1.1.459.g5970e58
^ permalink raw reply related
* Getting started contributing.
From: adamfraser @ 2013-02-03 6:21 UTC (permalink / raw)
To: git
Hi,
I would like to start contributing to git and am looking for a small project
idea to get started with. On the Small Project Ideas wiki
<https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
suggestion for adding a 'git rebase --status' command that sounds like it
would be good for someone who has little knowledge of the code base. Is this
project still wanted? Aside from that, I've done a little searching and
haven't been able to find an official bug tracker for git is there somewhere
I can find some bugs to help fix?
Apologies if this isn't the correct place to be posting.
Thanks
Adam Fraser
--
View this message in context: http://git.661346.n2.nabble.com/Getting-started-contributing-tp7576834.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox