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