Re: Cleaning up git user-interface warts

From: Richard CURNOW <richard.curnow@st.com>
Date: Nov 16, 2006, 07:51 UTC
Message-ID: <20061116075153.GA29363@tigerwolf.bri.st.com>
In-Reply-To: <20061115231542.GB25270@spearce.org>

* Shawn Pearce <spearce@spearce.org> [2006-11-15]:

Show 5 quoted lines

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