* stash-p broken? @ 2014-07-29 0:38 Michael Migdol 2014-07-29 0:56 ` Michael Migdol 0 siblings, 1 reply; 12+ messages in thread From: Michael Migdol @ 2014-07-29 0:38 UTC (permalink / raw) To: git I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so, "git stash -p" stopped working. (It apparently is ignoring the -p parameter). I'm not sure what version I was using previously, but after some experimentation, I see that: version 1.7.12.2 : stash -p DOES work version 1.9.3 : doesn't work version 2.0.3 : doesn't work Osse on the IRC channel was helping out with this and saw some very odd behavior while trying to bisect where the regression occurred; he said he'd comment further tomorrow. But I thought I would send a note to the list for archival... Cheers, Michael ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 0:38 stash-p broken? Michael Migdol @ 2014-07-29 0:56 ` Michael Migdol 2014-07-29 2:59 ` brian m. carlson 0 siblings, 1 reply; 12+ messages in thread From: Michael Migdol @ 2014-07-29 0:56 UTC (permalink / raw) To: git Sorry for error -- I meant: git stash list -p, not git stash -p. On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol <michael-spam@migdol.net> wrote: > I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so, > "git stash -p" stopped working. (It apparently is ignoring the -p > parameter). I'm not sure what version I was using previously, but after > some experimentation, I see that: > > version 1.7.12.2 : stash -p DOES work > version 1.9.3 : doesn't work > version 2.0.3 : doesn't work > > Osse on the IRC channel was helping out with this and saw some very odd > behavior while trying to bisect where the regression occurred; he said > he'd comment further tomorrow. But I thought I would send a note to the > list for archival... > > Cheers, > Michael ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 0:56 ` Michael Migdol @ 2014-07-29 2:59 ` brian m. carlson 2014-07-29 6:45 ` Øystein Walle 2014-07-29 9:23 ` Jeff King 0 siblings, 2 replies; 12+ messages in thread From: brian m. carlson @ 2014-07-29 2:59 UTC (permalink / raw) To: Michael Migdol; +Cc: git [-- Attachment #1: Type: text/plain, Size: 957 bytes --] On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote: > Sorry for error -- I meant: git stash list -p, not git stash -p. > > On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol <michael-spam@migdol.net> wrote: > > I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so, > > "git stash -p" stopped working. (It apparently is ignoring the -p > > parameter). I'm not sure what version I was using previously, but after > > some experimentation, I see that: > > > > version 1.7.12.2 : stash -p DOES work > > version 1.9.3 : doesn't work > > version 2.0.3 : doesn't work Under the hood, we do: git log --format="%gd: %gs" -g "$@" refs/stash -- But it looks like git log ignores -p if -g is provided. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 2:59 ` brian m. carlson @ 2014-07-29 6:45 ` Øystein Walle 2014-07-29 9:23 ` Jeff King 1 sibling, 0 replies; 12+ messages in thread From: Øystein Walle @ 2014-07-29 6:45 UTC (permalink / raw) To: git brian m. carlson <sandals <at> crustytoothpaste.net> writes: > > On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote: > > Sorry for error -- I meant: git stash list -p, not git stash -p. > > > > On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol <michael-spam <at> migdol.net> wrote: > > > I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so, > > > "git stash -p" stopped working. (It apparently is ignoring the -p > > > parameter). I'm not sure what version I was using previously, but after > > > some experimentation, I see that: > > > > > > version 1.7.12.2 : stash -p DOES work > > > version 1.9.3 : doesn't work > > > version 2.0.3 : doesn't work > > Under the hood, we do: > > git log --format="%gd: %gs" -g "$ <at> " refs/stash -- > > But it looks like git log ignores -p if -g is provided. > Unfortunately I don't have much to add... I have a weird issue where `git stash list -p` does not show a diff, but `~/usr/bin/git stash list -p` does, for the exact same version of Git. However, the underlying command does not show a diff in either case, even though I can tell that is the one being executed (with set -x inserted into .../libexec/git-stash). This is so weird that I think it's my system's fault. I have to do some more digging. Øsse ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 2:59 ` brian m. carlson 2014-07-29 6:45 ` Øystein Walle @ 2014-07-29 9:23 ` Jeff King 2014-07-29 17:00 ` Junio C Hamano 1 sibling, 1 reply; 12+ messages in thread From: Jeff King @ 2014-07-29 9:23 UTC (permalink / raw) To: Michael Migdol, git On Tue, Jul 29, 2014 at 02:59:40AM +0000, brian m. carlson wrote: > On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote: > > Sorry for error -- I meant: git stash list -p, not git stash -p. > > > > On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol <michael-spam@migdol.net> wrote: > > > I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so, > > > "git stash -p" stopped working. (It apparently is ignoring the -p > > > parameter). I'm not sure what version I was using previously, but after > > > some experimentation, I see that: > > > > > > version 1.7.12.2 : stash -p DOES work > > > version 1.9.3 : doesn't work > > > version 2.0.3 : doesn't work > > Under the hood, we do: > > git log --format="%gd: %gs" -g "$@" refs/stash -- > > But it looks like git log ignores -p if -g is provided. Almost. It's not ignored, but rather it is a noop on merge commits without "-c" or "--cc". And every stash is a merge commit (between the base commit and the index content). So why did it work in v1.7.12.2? It didn't. It just looked like it worked. :) When we do a reflog walk, we replace the parents of each commit with the prior reflog entry, simulating a linear string of development, moving from one reflog entry to another. Prior to 838f9a1 (log: use true parents for diff when walking reflogs, 2013-08-03), we used those "fake" parents when diffing, too. But that doesn't make much sense. It will show the diff between two adjacent reflog entries, which may not even be related (especially for stashes!). What the user is generally after is to walk the reflog, but to show each commit in isolation as a diff against its parents. So v1.7.12.2 showed _a_ diff, but it was the diff against the prior stash, which was generally nonsensical. After 838f9a1, we actually show the diff against the real parents, but you need "-p --cc" to see anything, because each stash is a merge. Unfortunately, the resulting diff is often a bit uglier than necessary. Here's an example: git init echo one >file && git add file && git commit -m one echo two >>file git stash git stash list -p --cc yields: stash@{0}: WIP on master: d0e237c one diff --cc file index 5626abf,5626abf..814f4a4 --- a/file +++ b/file @@@ -1,1 -1,1 +1,2 @@@ one ++two It's a combined-diff, because we are showing the changes from both the original base commit and the index. But the index was the same as the base, so each changed line gets two "++" markers (and two "--", and two spaces for context lines). And in many cases, I'd guess the index is untouched (in fact, "git stash show" explicitly shows _only_ the diff between the working tree and the base!). When we create the stash, we could notice that the trees for the index and base are identical, and just skip making the index commit (and therefore make the stash itself a regular commit rather than a merge). That might break later users of the stash, though, who would want to check "stash@{0}" against "stash@{0}^2" to see what was in the index (they could infer from the lack of a second parent that it was empty, but that is not backwards compatible). So perhaps we could do something better on the viewing side, and "simplify" combined merges for files with all-identical parents. With the patch below, these commands (on top of the earlier ones): echo two >>file && git add file echo three >>file git stash git stash list -p --cc --simplify-combined-diff yields: stash@{0}: WIP on master: d0e237c one diff --cc file index 5626abf,814f4a4..4cb29ea --- a/file +++ b/file @@@ -1,1 -1,2 +1,3 @@@ one + two ++three stash@{1}: WIP on master: d0e237c one diff --git file index 5626abf..814f4a4 --- a/file +++ b/file @@ -1,1 +1,2 @@ one +two I.e., we show the combined diff when it is relevant (in the first stash, where the index actually had something interesting), and a normal diff otherwise. And then we could make "--cc --simplify-combined-diff" the default for "stash list" (which would only trigger if you provided "--raw" or "-p" yourself). The patch for --simplify-combined-diff is below. Note that it either simplifies to a single parent, or does not simplification at all. In theory we could simplify an octopus merge of "A,B,A" into "A,B", but I think that just ends up being more confusing (and ambiguous; you don't know which parent was dropped). -Peff --- diff --git a/combine-diff.c b/combine-diff.c index 6c00c4b..6a27436 100644 --- a/combine-diff.c +++ b/combine-diff.c @@ -900,7 +900,11 @@ static void show_combined_header(struct combine_diff_path *elem, if (rev->loginfo && !rev->no_commit_id) show_log(rev); - dump_quoted_path(dense ? "diff --cc " : "diff --combined ", + dump_quoted_path(num_parent == 1 ? + "diff --git " : + dense ? + "diff --cc " : + "diff --combined ", "", elem->path, line_prefix, c_meta, c_reset); printf("%s%sindex ", line_prefix, c_meta); for (i = 0; i < num_parent; i++) { @@ -955,6 +959,15 @@ static void show_combined_header(struct combine_diff_path *elem, line_prefix, c_meta, c_reset); } +static int simplify_parents(struct combine_diff_path *p, int nr) +{ + int i; + for (i = 1; i < nr; i++) + if (hashcmp(p->parent[i].sha1, p->parent[i-1].sha1)) + return nr; + return 1; +} + static void show_patch_diff(struct combine_diff_path *elem, int num_parent, int dense, int working_tree_file, struct rev_info *rev) @@ -979,6 +992,9 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent, if (DIFF_OPT_TST(opt, ALLOW_TEXTCONV)) textconv = userdiff_get_textconv(userdiff); + if (rev->simplify_combined_diffs) + num_parent = simplify_parents(elem, num_parent); + /* Read the result of merge first */ if (!working_tree_file) result = grab_blob(elem->sha1, elem->mode, &result_size, @@ -1181,6 +1197,8 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re if (rev->loginfo && !rev->no_commit_id) show_log(rev); + if (rev->simplify_combined_diffs) + num_parent = simplify_parents(p, num_parent); if (opt->output_format & DIFF_FORMAT_RAW) { printf("%s", line_prefix); @@ -1247,12 +1265,16 @@ static void free_combined_pair(struct diff_filepair *pair) * but currently nobody uses it, so this should suffice for now. */ static struct diff_filepair *combined_pair(struct combine_diff_path *p, - int num_parent) + int num_parent, + struct rev_info *rev) { int i; struct diff_filepair *pair; struct diff_filespec *pool; + if (rev->simplify_combined_diffs) + num_parent = simplify_parents(p, num_parent); + pair = xcalloc(1, sizeof(*pair)); pool = xcalloc(num_parent + 1, sizeof(struct diff_filespec)); pair->one = pool + 1; @@ -1277,7 +1299,8 @@ static struct diff_filepair *combined_pair(struct combine_diff_path *p, static void handle_combined_callback(struct diff_options *opt, struct combine_diff_path *paths, int num_parent, - int num_paths) + int num_paths, + struct rev_info *rev) { struct combine_diff_path *p; struct diff_queue_struct q; @@ -1287,7 +1310,8 @@ static void handle_combined_callback(struct diff_options *opt, q.alloc = num_paths; q.nr = num_paths; for (i = 0, p = paths; p; p = p->next) - q.queue[i++] = combined_pair(p, num_parent); + q.queue[i++] = combined_pair(p, num_parent, rev); + opt->format_callback(&q, opt, opt->format_callback_data); for (i = 0; i < num_paths; i++) free_combined_pair(q.queue[i]); @@ -1498,7 +1522,8 @@ void diff_tree_combined(const unsigned char *sha1, (DIFF_FORMAT_NUMSTAT|DIFF_FORMAT_DIFFSTAT)) needsep = 1; else if (opt->output_format & DIFF_FORMAT_CALLBACK) - handle_combined_callback(opt, paths, num_parent, num_paths); + handle_combined_callback(opt, paths, num_parent, + num_paths, rev); if (opt->output_format & DIFF_FORMAT_PATCH) { if (needsep) diff --git a/revision.c b/revision.c index b8b0ea3..27eba77 100644 --- a/revision.c +++ b/revision.c @@ -1820,6 +1820,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg revs->diff = 1; revs->dense_combined_merges = 1; revs->combine_merges = 1; + } else if (!strcmp(arg, "--simplify-combined-diffs")) { + revs->simplify_combined_diffs = 1; } else if (!strcmp(arg, "-v")) { revs->verbose_header = 1; } else if (!strcmp(arg, "--pretty")) { diff --git a/revision.h b/revision.h index a620530..29689a1 100644 --- a/revision.h +++ b/revision.h @@ -122,6 +122,7 @@ struct rev_info { ignore_merges:1, combine_merges:1, dense_combined_merges:1, + simplify_combined_diffs:1, always_show_header:1; /* Format info */ ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 9:23 ` Jeff King @ 2014-07-29 17:00 ` Junio C Hamano 2014-07-29 17:43 ` Jeff King 0 siblings, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2014-07-29 17:00 UTC (permalink / raw) To: Jeff King; +Cc: Michael Migdol, git Jeff King <peff@peff.net> writes: > So perhaps we could do something better on the viewing side, and > "simplify" combined merges for files with all-identical parents. Or you can ask to show the difference with the first parent, no? I do not think giving a single-parent diff when --cc/-c is asked for, which is a clear indication that the caller is aware that the commit in question is a merge, is such a good idea. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 17:00 ` Junio C Hamano @ 2014-07-29 17:43 ` Jeff King 2014-07-29 18:23 ` Junio C Hamano 2014-07-29 19:27 ` Junio C Hamano 0 siblings, 2 replies; 12+ messages in thread From: Jeff King @ 2014-07-29 17:43 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michael Migdol, git On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > So perhaps we could do something better on the viewing side, and > > "simplify" combined merges for files with all-identical parents. > > Or you can ask to show the difference with the first parent, no? Yeah, though there is no way to do the other thing (--second-parent to show only the index side). I doubt anybody wants that, though. Just passing --first-parent would probably be fine (that would match "git stash show", too, though like that "stash show" it is impossible to override to see the index portion then). But... > I do not think giving a single-parent diff when --cc/-c is asked > for, which is a clear indication that the caller is aware that the > commit in question is a merge, is such a good idea. I think that is my point, though. The user is _not_ aware that the commit in question is a merge. They stashed some stuff, and now they want to see the result. I'd like to show them a vanilla commit if the index is irrelevant, and otherwise show them something more interesting. I definitely don't think that should be the default behavior, but I don't see a problem with it being part of stash. We pick apart the stash already in git-stash.sh, so for "git stash show" we can do it ourselves. But during a traversal, we need support from "git log", since the answer is different for each stash (and even for each path). -Peff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 17:43 ` Jeff King @ 2014-07-29 18:23 ` Junio C Hamano 2014-07-31 0:23 ` Jeff King 2014-07-29 19:27 ` Junio C Hamano 1 sibling, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2014-07-29 18:23 UTC (permalink / raw) To: Jeff King; +Cc: Michael Migdol, git Jeff King <peff@peff.net> writes: > On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote: > >> Jeff King <peff@peff.net> writes: >> >> > So perhaps we could do something better on the viewing side, and >> > "simplify" combined merges for files with all-identical parents. >> >> Or you can ask to show the difference with the first parent, no? > > Yeah, though there is no way to do the other thing (--second-parent to > show only the index side). I doubt anybody wants that, though. Just > passing --first-parent would probably be fine (that would match "git > stash show", too, though like that "stash show" it is impossible to > override to see the index portion then). > > But... > >> I do not think giving a single-parent diff when --cc/-c is asked >> for, which is a clear indication that the caller is aware that the >> commit in question is a merge, is such a good idea. > > I think that is my point, though. The user is _not_ aware that the > commit in question is a merge. Oh, don't get me wrong. I am not opposed to give better output from "stash show -p". I do not want to see us change what "git log --cc" does without being asked to do something different. I see you added --simplify-combined-diffs to avoid breaking "log", so that is not too bad, but I am still unsure what should happen when the first parent and the result is the same and only the second parent is different (i.e. you have changes in the index and your working tree changes have been reverted---then you create a stash). Should it show as "single source diff, with all changes reverted"? Should it show as a normal "combined diff for a merge"? Should it show as "no changes whatsoever"? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 18:23 ` Junio C Hamano @ 2014-07-31 0:23 ` Jeff King 2014-07-31 16:49 ` Junio C Hamano 0 siblings, 1 reply; 12+ messages in thread From: Jeff King @ 2014-07-31 0:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michael Migdol, git On Tue, Jul 29, 2014 at 11:23:16AM -0700, Junio C Hamano wrote: > I see you added --simplify-combined-diffs to avoid breaking "log", > so that is not too bad, but I am still unsure what should happen > when the first parent and the result is the same and only the second > parent is different (i.e. you have changes in the index and your > working tree changes have been reverted---then you create a stash). > Should it show as "single source diff, with all changes reverted"? > Should it show as a normal "combined diff for a merge"? Should it > show as "no changes whatsoever"? Interesting question. I think right now we would show nothing in the combined diff, as we simply took one side. This is really showing the weakness of the "stash is a merge" storage format. If we use it as a storage format, and pick it apart in "git stash", that's fine. But as soon as we start treating it like a real merge and expecting "git log" to behave, the cracks begin to show. Hmph. To be honest, I am starting to wonder if implying "--first-parent" is a more sensible option for "stash list". It matches "stash show", at least, and it is not unreasonable to simply present the changes in the working tree by default, and ignore the index. People who are more clueful can pick apart the commits using "git log" themselves. -Peff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-31 0:23 ` Jeff King @ 2014-07-31 16:49 ` Junio C Hamano 0 siblings, 0 replies; 12+ messages in thread From: Junio C Hamano @ 2014-07-31 16:49 UTC (permalink / raw) To: Jeff King; +Cc: Michael Migdol, git Jeff King <peff@peff.net> writes: > Hmph. To be honest, I am starting to wonder if implying "--first-parent" > is a more sensible option for "stash list". It matches "stash show", at > least, and it is not unreasonable to simply present the changes in the > working tree by default, and ignore the index. People who are more > clueful can pick apart the commits using "git log" themselves. Yup, I tend to agree. After thinking about this a lot, I really wish that we did not have "stash apply" and "stash pop", but just "stash save" and a single "stash restore" that either checks out the original branch (if its head have not moved) or detaches the HEAD at the original commit (otherwise), and then restores the state of the index and the working tree (with or without untracked) and nothing else, but the details are too long to fit in this topic ;-) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 17:43 ` Jeff King 2014-07-29 18:23 ` Junio C Hamano @ 2014-07-29 19:27 ` Junio C Hamano 2014-07-31 0:16 ` Jeff King 1 sibling, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2014-07-29 19:27 UTC (permalink / raw) To: Jeff King; +Cc: Michael Migdol, git Jeff King <peff@peff.net> writes: > I think that is my point, though. The user is _not_ aware that the > commit in question is a merge. They stashed some stuff, and now they > want to see the result. I'd like to show them a vanilla commit if the > index is irrelevant, and otherwise show them something more interesting. I actually think "git stash list" users should be made very aware that they are looking at merge commits, and also what two states each of these merge commits represents. "git stash --help" says that "list" takes any random option that you can give to "git log", and at that point you need to be very well aware what you are telling "log" to show and how. It probably *was* a UI mistake to make "list" just delegate to "log" and it was a graver UI mistake that it was documented as such; otherwise we could have limited option set "git stash list" would take, which can be totally independent from what "git log" takes, and we could just have said "git stash list -p" is a way to view each entry with patch in a reasonable representation. But that ideal world no longer exists X-<. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: stash-p broken? 2014-07-29 19:27 ` Junio C Hamano @ 2014-07-31 0:16 ` Jeff King 0 siblings, 0 replies; 12+ messages in thread From: Jeff King @ 2014-07-31 0:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michael Migdol, git On Tue, Jul 29, 2014 at 12:27:07PM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > I think that is my point, though. The user is _not_ aware that the > > commit in question is a merge. They stashed some stuff, and now they > > want to see the result. I'd like to show them a vanilla commit if the > > index is irrelevant, and otherwise show them something more interesting. > > I actually think "git stash list" users should be made very aware > that they are looking at merge commits, and also what two states > each of these merge commits represents. Yeah, I kind of agree, but I also am not optimistic about most users understanding that. I was trying to gamble on the fact that: 1. Naive users who do not understand the index will not stage files and then stash in the first place. To them, the stash would be a simple diff between two states, the commit and the working tree. 2. Advanced users would see the more complicated diff, but only because they were doing more interesting things with the index. They know what the index is, and therefore know that stash must be saving it somehow. Of course that breaks down when the naive user somehow ends up with staged content in the index (e.g., they are resolving a merge and try to stash). Then they are thrust into the more complicated situation either way. I dunno. I suspect that gamble would work _most_ of the time, and makes an OK default. On the other hand, "git stash list" was completely useless for showing diffs for many years, and since becoming useful has required "--cc" to show anything good. And this is the first complaint we've seen on the list. Maybe people don't actually care, and educating people to use "--cc -p" (or "--first-parent -p") is fine. -Peff ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-07-31 16:49 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-29 0:38 stash-p broken? Michael Migdol 2014-07-29 0:56 ` Michael Migdol 2014-07-29 2:59 ` brian m. carlson 2014-07-29 6:45 ` Øystein Walle 2014-07-29 9:23 ` Jeff King 2014-07-29 17:00 ` Junio C Hamano 2014-07-29 17:43 ` Jeff King 2014-07-29 18:23 ` Junio C Hamano 2014-07-31 0:23 ` Jeff King 2014-07-31 16:49 ` Junio C Hamano 2014-07-29 19:27 ` Junio C Hamano 2014-07-31 0:16 ` Jeff King
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.