Re: Regulator updates for 3.3

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 10, 2012, 22:54 UTC
Message-ID: <CA+55aFxvQF=Bm4ae6euB_UO8otMCuN9Lv37Zn3TpE-L7JH3Kzw@mail.gmail.com>
In-Reply-To: <20120110222711.GK7164@opensource.wolfsonmicro.com>

On Tue, Jan 10, 2012 at 2:27 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

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

This is actually one of my major gripes with the git UI, and one of the few areas where I really think I screwed up: I made merging *too* easy by default. I should have made it always start up an editor for a merge message, the way it does for a commit - rather than just do a trivial pointless merge without even asking the user for a reason for the merge.

So looking at that almost two months of regulator history in

   gitk d52739c62e00..269d430131b6

I would not have reacted badly at all if there were one or two of those merges, and they actually had a reason associated with them. Sadly, due to that git UI mess-up, that's harder to do than it should be. Oh, it's easy enough with "git merge --no-commit" followed by just "git commit", and then you get the normal git editor window.

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

                       Linus