Re: [PATCH v2] gitk: fix direction of symmetric difference in optimized mode

From: Thomas Rast <trast@student.ethz.ch>
Date: Aug 6, 2009, 07:19 UTC
Message-ID: <200908060919.27780.trast@student.ethz.ch>
In-Reply-To: <19066.8802.98042.957009@cargo.ozlabs.ibm.com>

Paul Mackerras wrote:

Show 8 quoted lines

> Thomas Rast writes:
> 
> > The confusing part of this, but also how I stumbled across the real
> > bug, was that I was playing with --show-all and that flipped the
> > direction *again*.  Turns out the option is not recognized by gitk and
> > lets it go back to unoptimized mode, where the bug does not exist.
> 
> What does --show-all do?  Maybe I need to add support for it to gitk.

Support for _displaying_ it was added to gitk in 1407ade, even before the option was added to the revision walker. Since it's a debugging option, I doubt it's worth handling this in the optimized code path.

But anyway, it does not do what I hoped :-(

It shows commits that were walked, but found uninteresting, with a ^ in front. See the long explanation in 3131b71; you can try

  gitk --show-all origin/next..origin/pu

for a nice example in git.git.

I was _actually_ looking for an option to make --cherry-pick --left-right history connected again, as I was trying to make sense of an SVN history basically by saying

  gitk --left-right --cherry-pick svn/2.2...svn/trunk

(Incidentally this SVN is publicly available at https://secure.a-eskwadraat.nl/svn/domjudge, but I doubt it's worth the cloning.)

The problem with this is that it disconnects history, so I was looking for an option to either get back the commits omitted by --cherry-pick (but of course flagged in some way that shows they're duplicated) or fix the parent pointers so that history becomes connected again. Some of my guesses were --sparse, --full-history and --show-all, but none achieve this.

[I *think* --sparse comes closest, but it's about TREESAME-type uninteresting commits, not about --cherry-pick. --full-history is only about the merges that are TREESAME, so that's out. --show-all apparently is something entirely different.]

Sadly, it's really the underlying git-rev-list that is "broken" in the sense that it does not fix the parent lists. And git log --graph handles it much worse than gitk. I've added the authors of the relevant features to Cc; maybe you can help?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch