Junio C Hamano wrote:
> So if we rename the current "git merge" to "git-merge--record"
or git-merge-driver
> (or any name "git pull" uses internally to record the merge
> commit), and make "git merge" a synonym to "git pull .", and
> give a command line option -m to "git pull" to _affect_ the
> resulting merge message, I would think everybody would become
> quite happy. It means:
>
> - People can say "git merge this-branch" (which is internally
> translated to "git pull . this-branch");
>
> - People can say "git pull -m 'I am doing this merge for such
> and such reason' $URL $branch" to _include_ that message in
> the resulting merge commit;
>
> - The same can be said about "git merge -m 'comment' $branch".
>
> I said _affect_ and _include_ in the above because I suspect
> that most of the time you do not want to _replace_ the
> autogenerated part ("Merge branch of repo", and if you are
> pulling from your subordinate trees the merge summary message as
> well).
I'm all for adding -m <msg> option to git-pull (and perhaps also common
other message generation options: -F <file>, --edit). I'm even for adding
-m option to git-merge.
Making "git merge" to be a synonym to "git pull ."... I'm not so sure.
I'd rather we don't lose the ability to give arbitrary refs ar "other"
heads like in
git merge "Merge early part of branch 'topicA'" HEAD topicA~3
example, and ability (if there is such ability) to not include HEAD (current
version of branch) as first parent like in
git checkout pu
git merge "Merge branch 'topicA', 'topicB'" topicA topicB
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
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