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

[John Ralls]

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.

> 
> 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`.

> 
> 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-unnecessarily-long-lines-td7567302.html
which led to
http://thread.gmane.org/gmane.comp.version-control.git/18097/focus=18103
suggesting that it’s a well-known issue.

Regards,
John Ralls