On Thursday 15 May 2014 11:17:50 John Ralls wrote: > On May 14, 2014, at 10:06 AM, Geert Janssens <janssens- [email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
