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 <apeli...@gmail.com> wrote:
> On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins <e...@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
> Hope that helps,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html