"private-kvp" merge reverted other changes since November.

[Geert Janssens]

On Thursday 15 May 2014 11:17:50 John Ralls wrote:
> On May 14, 2014, at 10:06 AM, Geert Janssens <janssens-
geert at telenet.be> wrote:
> > Interesting. Did you close and re-open SourceTree after you switched
> > to master ?
> 
> No, but I don’t remember which branch I was checked out in when I
> opened it. Doesn’t seem to matter, though. FWIW, I just tried to
> reproduce the switching yard with gitk in F18, and couldn’t.
> 
> 
> That’s after starting with master checked out, checking out maint,
> redrawing in gitk, check out master, and redraw again.

It's odd this doesn't happen for you... I see this consistently when I 
start gitk with
gitk --all
and master was checked out. Just running gitk doesn't. But if I then 
check out maint on the command line and refresh the gitk window the 
switching yard reappears.

> > On gitk that seems to make a difference. If master is the active
> > branch when I open gitk I get the switching-yard. However if maint
> > is the active branch I get a much cleaner ladder like SourceTree
> > shows. And that clean ladder remains if I then swith the master
> > within gitk.
> > 
> > Meanwhile I have also tried qgit but it behaves exactly the same.
> > Both tools appear to get their input from git log and are probably
> > pretty dumb in how to parse that.
> 
> Git rev-list, for which git log is a front end.
> 
> It appears from the graphs that getting the commits in the right order 
is the main issue: The switching-yard look comes from having the other-
branch merge parents out of date order, as if the graph was produced by 
gluing together chunks of output from runs of git rev-list on each 
branch. Browsing through the rev-list man page I find:
> > --topo-order
> > Show no parents before all of its children are shown, and avoid
> > showing commits on multiple lines of history intermixed.> 
> > For example, in a commit history like this:
> >     ---1----2----4----7
> >     
> >         \              \
> >         
> >          3----5----6----8---
> > 
> > where the numbers denote the order of commit timestamps, git
> > rev-list and friends with --date-order show the commits in the
> > timestamp order: 8 7 6 5 4 3 2 1.
> > 
> > With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 3
> > 1); some older commits are shown before newer ones in order to
> > avoid showing the commits from two parallel development track mixed
> > together.
> Switching to the gitk man page,
> 
> > To control which revisions to show, the command takes options
> > applicable to the git rev-list command (see git-rev-list(1)). This
> > manual page describes only the most frequently used options.
> So perhaps a little experimentation is in order; In particular, try
> `gitk —date-order`.

That does the trick !
Even gitk --date-order --all still results in a clean ladder. I can make 
an alias for this.

> > Perhaps I should report this as a bug or enahncement request in
> > gitk...
> I’d do some research first. Searching “gitk commit order” yielded
> (among much else, of course)
> http://git.661346.n2.nabble.com/Gitk-commit-order-leads-to-unnecessar
> ily-long-lines-td7567302.html which led to
> http://thread.gmane.org/gmane.comp.version-control.git/18097/focus=181
> 03 suggesting that it’s a well-known issue.

Well if they haven't fixed it by now they probably have reason not to. I 
haven't read through the whole thread on gmane. Perhaps it was explained 
later on.

With this workaround I have no more issues with long lived topic 
branches that periodically are merged back into master. That's my final 
conclusion.

Geert
> 
> Regards,
> John Ralls