Re: first parent, commit graph layout, and pull merge direction

From: Andreas Krey <a.krey@gmx.de>
Date: May 24, 2013, 17:24 UTC
Message-ID: <20130524172440.GC9448@inner.h.apk.li>
In-Reply-To: <519F81B6.4010807@ira.uka.de>

On Fri, 24 May 2013 17:05:26 +0000, Holger Hellmuth (IKS) wrote:

> Am 24.05.2013 15:42, schrieb Andreas Krey:

...

> >The branch name is almost completely meaningless. I could just
> >do my feature in my local master and never have a different name.
> 
> In which case parent switching in the commit wouldn't help you either.

Oh, it does; I tried. Names are meaningless, the parent ordering isn't. ( [And at least, it's already in there.]

> But even you could keep your master always on the left side of gitk if 
> you deem it special. And you could keep longer running cooperative 
> branches (the main develop and the release branch of your project for 
> example) in a seperate lane.

I need gitk (or similar) to do it. Will take some time to understand the code (and triggers the 'I can write it (the interesting part) faster than I can grok gitk').

...

> Without additional information about the commit history gitk can do 
> exactly what it does now.

Most definitely not. There are quite some situations where the graph deteriorates pretty heavily, even when not expecting it to pay attention to first parent. When you have two branches, of which one regularly gets merge into the other, it sometimes manages to display first the one, then the other branch, with a log of merge edges going upwards in parallel, for example.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800