On Tue, Jan 10, 2012 at 02:54:27PM -0800, Linus Torvalds wrote: > On Tue, Jan 10, 2012 at 2:27 PM, Mark Brown > > Especially in the cases where the lack of the bug fix breaks the new > > code it sems sensible enough to want to do the merges so that the > > history includes things that actually work. > So I don't mind merges if they have a lear reason for existing. OK, good - I figured that was the case but wanted to make sure as you were stating things rather more strongly than that. Just to warn you there's also a whole stack of similar merges going to come in via the sound tree too due to the same workflow, I *could* try to rebuild the history and ask Takashi to redo his tree using that but there's a lot of history there and it'd be hard to figure out which of the merges was actually important. Is it OK to leave things as they are for this release? > So right now "git merge" (and "git pull") make it too easy to make > those meaningless merge commits. If instead of seven pointless merges > you had (say) had two merges that had messages about *why* they > weren't pointless, I'd be perfectly happy. > Addid junio and git to the cc just to bring up this issue of bad UI > once again. I realize it could break old scripts to start up an editor > window, but still.. I'd use a configuration option that popped up an editor by default, even if I did have to manually enable it. -- 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