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

From: "Holger Hellmuth (IKS)" <hellmuth@ira.uka.de>
To: Andreas Krey <a.krey@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: first parent, commit graph layout, and pull merge direction
Date: Fri, 24 May 2013 11:29:00 +0200	[thread overview]
Message-ID: <519F32DC.0@ira.uka.de> (raw)
In-Reply-To: <20130523192512.GR9448@inner.h.apk.li>

Am 23.05.2013 21:25, schrieb Andreas Krey:
> On Thu, 23 May 2013 11:06:57 +0000, Andreas Krey wrote:
> ...
>> ...
>>> Don't do that, then.
>
> Ouch, you're right. The problem is not actually in the
> pull; only the *last* pull into a feature branch that
> then get pushed back ff to master needs to be reversed.
>
> And at that time you don't know it's the last one
> -> swap parents before the push if necessary.

if you have to be so careful to ensure the correct ordering of parents 
it almost defeats the initial objective to make commit graphs in gitk 
look nice without re-educating/restricting other users. A solution that 
works for everyone should work without users having to think about it.

Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that 
is updated)
2) unique identifier of repository is recorded in commit (optional)
3) simple configurable ordering and/or coloring scheme in gitk based on 
committer,branch name and repo (with wildcards).

With this users could pull and push as often as they like, the main 
branches would always be ordered and straight lines. If instead you 
already do the work to keep your history clean you could just use the 
coloring scheme and see committers color coded in gitk. Further benefit: 
the history of really old commits could be more easily remembered if you 
knew in what branch they originated

Is this a bad idea or just no one did it yet?