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

[Thomas Rast <trast@student.ethz.ch>]

Paul Mackerras wrote:
> 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