linux@horizon.com writes:
The last end-user use I can think of for git-merge instead
of git-pull is providing a custom commit message.
Would it be possible to add -m and -e options to git-pull?
The problem I can see is that the latter would have to be added to
git-merge, and the guts there are a bit intricate; it uses git-commit-tree
directly rather than git-commit, so I can't just pass through the
arguments.
How often is this desired, when the merge is clean?
If the answer is "not so often", you can already use "commit
--amend" after "pull" creates an automated merge commit.
How often is this desired, when the merge is clean?
Well, if I could quote your own words:
quoted
I use "git pull . topicA topicB" for a tetrapus, so that is not
a reason for me, but when a topicA's older parts are worthy to
be in 'next' while later parts are not yet, I often do (on 'next'):
git merge "Merge early part of branch 'topicA'" HEAD topicA~3
I can't speak from personal experience, but a merge can bring in a lot
of changes, and sometimes the auto-generated message doesn't say quite
as much as you'd like.
The commits on the branch speak for themselves, of course, but sometimes
it's nice to add the same sort of overview that appears in a [PATCH 0/13]
e-mail. We wouldn't have that convention if there wasn't a frequent
desire for it.
(Indeed, it might be nice to come up with a way of including a piece of
the "please pull" e-mail, similar to the way that git-applypatch works.)
If the answer is "not so often", you can already use "commit
--amend" after "pull" creates an automated merge commit.
It's not done very often right now, but how much of that is due to
the awkwardness? I agree it works perfectly, but "commit --amend"
has very much the feel of a workaround.
I'm not going to besiege Troy for a decade over the idea, but it seemed