* Shawn Pearce <spearce@xxxxxxxxxxx> [2006-11-15]: > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html