* Shawn Pearce <spearce@spearce.org> [2006-11-15]:
quoted text
> 
> So what about making git-merge take a -m "msg" argument to supply
> the commit message, in which case it does the current behavior
> (and thus git-pull needs to change to supply -m); and then make
> git-merge without any -m parameter invoke "git pull . $@" ?

Sounds good to me.

When I'm merging in my own projects, I currently always use merge
(possibly preceded by fetch) rather than pull.  Why?  Because I don't
want my history full of commit messages like

Merge branch "trial_hack" from "../scratch_dir_with_silly_name"

In contrast to Linus's case of wanting to record where the remote merge
came from, I expressly don't want to record that - I want the merge
commit to describe conceptually what was being merged with what.

OK, I could use probably use pull with --no-commit, but I've already
trained my fingers to type out the merge syntax.  They'd be happier with
'git merge -m "Merge feature foo with fixes for bar" bar" though.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html