Re: Feature request: "author branch" in commit object

From: Ed Hutchins <eh@demeterr.com>
Date: Jul 3, 2013, 17:31 UTC
Message-ID: <CADL+T9bbnGSxCjUBqoL3qm7Ss-j9jxorED0L1A6v1NbeLBpRQg@mail.gmail.com>
In-Reply-To: <CALWbr2zJFjbaCdA3d1eaFuP4HGShAwnK=gisRD=KHKWWi-XuTg@mail.gmail.com>

I might be able to switch our corporate workflow to adding non-ff merge commits, but the reason we moved away from using github's big red button in the first place was to avoid the extra noise of merge-only commits.

Actually you've pointed out an inconsistency: why is it okay for merge commits to automatically mention branch names, but for regular commits this is considered harmful?

On Wed, Jul 3, 2013 at 9:16 AM, Antoine Pelisse <apelisse@gmail.com> wrote:

Show 28 quoted lines

> On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins <eh@demeterr.com> wrote:
>> On the other hand
>> trying to figure
>> out the history of events from a large directed graph of commits
>> without any clue about
>> what topics first spawned each commit is actively harmful in many
>> cases (trying to display
>> a clear history of who did what for what reasons, for example).
>
> I think this is exactly what Junio does with git.git:
> - Each branch is named "$initials/$topicname" before being merged.
> - Branches are always merged with --no-ff.
>
> I think it answers your question: Who (initials) does what (topic)
> The name of the branch is also stuck as part of the history as the
> merge reads the name of the merged branch:
>
> e.g. Merge branch 'rr/remote-branch-config-refresh'
>
> You can of course provide more information than the simple commit
> header line (that would give the "what reasons").
>
> Of course, it's even easier to read if you always merge in the same
> direction (that allows you to easily find the first commit of the
> branch).
>
> Hope that helps,
> Antoine