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

From: Holger Hellmuth (IKS) <hellmuth@ira.uka.de>
Date: May 24, 2013, 09:29 UTC
Message-ID: <519F32DC.0@ira.uka.de>
In-Reply-To: <20130523192512.GR9448@inner.h.apk.li>

Am 23.05.2013 21:25, schrieb Andreas Krey:

Show 11 quoted lines

> 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?