Re: [GIT] Networking

[Junio C Hamano]

Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> On Thu, Mar 10, 2011 at 3:34 PM, David Miller <davem@xxxxxxxxxxxxx> wrote:
>> ...
> Look at that commit message:
>
>     Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
>
> That is literally the WHOLE message. Ask yourself: is that commit
> doing anything useful? Does the commit message explain what it is
> doing, and why you are doing it?
> ...
> Now, I admit that it's a git usability bug: for normal "git commit",
> git will _force_ you to write a message, and sadly, for merges, I made
> it instead just do the message automatically. My bad. I designed it
> for the kind of merges I do, where the the automatic merge message
> actually tells you what the merge is all about. But for back-merges,
> the automatic message is totally worthless, and it is DOUBLY worthless
> when you do it the way you do it, namely from some local directory of
> your own.

I admit that I back-merged a few times my own master to a largish topic
branch, when updates that happened on the master front since the topic
forked from it helped to clean up the topic.  When I did so, I knew better
to say "git commit --amend" to reword the merge message to say something
like:

	Merge 'master' to 'jc/frotz' for xyzzy feature

so it wasn't a huge problem for me personally to keep the history useful,
but I agree that it would be better to make it harder for mortals to just
backmerge without doing the rewording.

The question is how.  Perhaps when the merge is made from the default
upstream, i.e. with "git pull" (no parameters) or "git merge @{u}", we
should automatically give the user an editor?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/