# [PATCH] git-merge: make it usable as the first class UI 7 messages from 2006-11-19 to 2006-11-22. Participants: Junio C Hamano, Jakub Narebski, linux@horizon.com. Thread: https://gitlist.dev/t/43434 ## linux@horizon.com, 2006-11-19 21:26 Subject: Feature request: git-pull -e/--edit Message-ID: <20061119212611.13038.qmail@science.horizon.com> URL: https://gitlist.dev/e/20061119212611.13038.qmail%40science.horizon.com ``` 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. Assuming it's just as much of a pain for someone else, would it still be worth the effort? Can git-merge be cleaned up? The manual option is to use "git merge --no-commit" and then supply the arguments to git-commit in the usual way. But I notice that --no-commit actually changes git's merging technique. If it's specified, the trivial in-index merge doesn't appear to be attempted. I don't think it makes a huge difference, ``` ## Junio C Hamano, 2006-11-20 02:17 Subject: Re: Feature request: git-pull -e/--edit Message-ID: <7vy7q67tf2.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7q67tf2.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061119212611.13038.qmail@science.horizon.com> ``` 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. ``` ## linux@horizon.com, 2006-11-20 02:43 Subject: Re: Feature request: git-pull -e/--edit Message-ID: <20061120024308.18620.qmail@science.horizon.com> URL: https://gitlist.dev/e/20061120024308.18620.qmail%40science.horizon.com In-Reply-To: <7vy7q67tf2.fsf@assigned-by-dhcp.cox.net> ``` > How often is this desired, when the merge is clean? Well, if I could quote your own words: >> 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 ``` ## Junio C Hamano, 2006-11-20 03:21 Subject: Re: Feature request: git-pull -e/--edit Message-ID: <7v8xi67qhq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xi67qhq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061120024308.18620.qmail@science.horizon.com> ``` linux@horizon.com writes: >> How often is this desired, when the merge is clean? > > Well, if I could quote your own words: > >>> 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. That is more or less irrelevant example. I was only saying that it is a workaround to emulate "git pull . topicA~3"; if that form worked, I would keep the automated fmt-merge-msg output that is currently recorded in the merge and I do not see any need to edit it further. > (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.) That is a lot more relevant example. For example, I could imagine that Linus coming up with a wrapper that is fed a series of e-mails and: * if it is a patch, run git-applymbox on it as before, * if it is a pull request, then extract the URL and branch, run "git pull" on that, match the "diff ORIG_HEAD" output against what is in the pull request and, - warn if there are huge discrepancies; - otherwise annotate the commit message with the explanation of the series taken from the pull request message. But even in that workflow, "annotate the commit" comes after pull happens and the merge result is verified, so I do not quite see "commit --amend" as a "workaround" as you said. Having said that, I think the real reason that the whole "merge" message generation feels awkward comes from the historical division of labor between pull and merge. "git merge" started its life as the first level command (with a funny syntax that does not even take command line option -m, because you are supposed to give the whole merge message and "git merge" itself does not do anything to affect the merge message on its own). When it was pushed further back to the "worker behind the scene" status, the task of coming up with a fancier automated merge message were still left to the "git pull" command which (1) is the UI level command that the users are expected to use, and (2) knows much more about the context where the merge is generated than "git merge" itself. As a result, "git merge" still takes the whole message prepared and it does not do anything on its own. So if we rename the current "git merge" to "git-merge--record" (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). ``` ## Jakub Narebski, 2006-11-20 08:02 Subject: Re: Feature request: git-pull -e/--edit Message-ID: URL: https://gitlist.dev/e/ejrnbg%24sg5%241%40sea.gmane.org In-Reply-To: <7v8xi67qhq.fsf@assigned-by-dhcp.cox.net> ``` 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 option to git-pull (and perhaps also common other message generation options: -F , --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 ``` ## Junio C Hamano, 2006-11-20 10:17 Subject: [PATCH] git-merge: make it usable as the first class UI Message-ID: <7vu00u4e2d.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vu00u4e2d.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v8xi67qhq.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > So if we rename the current "git merge" to "git-merge--record" > (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 did a moral equivalent of the above without renaming the command "git merge" and will be pushing the result out in "pu" shortly. The following is for commenting only -- it depends on an earlier patch in "pu". -- >8 -- [PATCH] git-merge: make it usable as the first class UI This teaches the oft-requested syntax git merge $commit to implement merging the named commit to the current branch. This hopefully would make "git merge" usable as the first class UI instead of being a mere backend for "git pull". Most notably, $commit above can be any committish, so you can say for example: git merge js/shortlog~2 to merge early part of a topic branch without merging the rest of it. A custom merge message can be given with the new --message= parameter. The message is prepended in front of the usual "Merge ..." message autogenerated with fmt-merge-message. Signed-off-by: Junio C Hamano --- Documentation/git-merge.txt | 18 +++++++++--- git-merge.sh | 61 ++++++++++++++++++++++++++++++++++++++----- 2 files changed, 67 insertions(+), 12 deletions(-) diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index bebf30a..e2954aa 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -8,12 +8,14 @@ git-merge - Grand Unified Merge Driver SYNOPSIS -------- -'git-merge' [-n] [--no-commit] [-s ]... ... - +[verse] +'git-merge' [-n] [--no-commit] [--squash] [-s ]... + [--reflog-action=] + -m= ... DESCRIPTION ----------- -This is the top-level user interface to the merge machinery +This is the top-level interface to the merge machinery which drives multiple merge strategy scripts. @@ -27,13 +29,19 @@ include::merge-options.txt[] to give a good default for automated `git-merge` invocations. :: - our branch head commit. + Our branch head commit. This has to be `HEAD`, so new + syntax does not require it :: - other branch head merged into our branch. You need at + Other branch head merged into our branch. You need at least one . Specifying more than one obviously means you are trying an Octopus. +--reflog-action=:: + This is used internally when `git-pull` calls this command + to record that the merge was created by `pull` command + in the `ref-log` entry that results from the merge. + include::merge-strategies.txt[] diff --git a/git-merge.sh b/git-merge.sh index 84c3acf..25deb1e 100755 --- a/git-merge.sh +++ b/git-merge.sh @@ -3,7 +3,8 @@ # Copyright (c) 2005 Junio C Hamano # -USAGE='[-n] [--no-commit] [--squash] [-s ]... +' +USAGE='[-n] [--no-commit] [--squash] [-s ] [--reflog-action=] [-m=] +' + . git-sh-setup LF=' @@ -92,7 +93,7 @@ finish () { case "$#" in 0) usage ;; esac -rloga= +rloga= have_message= while case "$#" in 0) break ;; esac do case "$1" in @@ -125,17 +126,63 @@ do --reflog-action=*) rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;; + -m=*|--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*) + merge_msg=`expr "z$1" : 'z-[^=]*=\(.*\)'` + have_message=t + ;; + -m|--m|--me|--mes|--mess|--messa|--messag|--message) + shift + case "$#" in + 1) usage ;; + esac + merge_msg="$1" + have_message=t + ;; -*) usage ;; *) break ;; esac shift done -merge_msg="$1" -shift -head_arg="$1" -head=$(git-rev-parse --verify "$1"^0) || usage -shift +# This could be traditional "merge HEAD ..." and the +# way we can tell it is to see if the second token is HEAD, but some +# people might have misused the interface and used a committish that +# is the same as HEAD there instead. Traditional format never would +# have "-m" so it is an additional safety measure to check for it. + +if test -z "$have_message" && + second_token=$(git-rev-parse --verify "$2^0" 2>/dev/null) && + head_commit=$(git-rev-parse --verify "HEAD" 2>/dev/null) && + test "$second_token" = "$head_commit" +then + merge_msg="$1" + shift + head_arg="$1" + shift +else + # We are invoked directly as the first-class UI. + head_arg=HEAD + + # All the rest are the commits being merged; prepare + # the standard merge summary message to be appended to + # the given message. If remote is invalid we will die + # later in the common codepath so we discard the error + # in this loop. + merge_name=$(for remote + do + rh=$(git-rev-parse --verify "$remote"^0 2>/dev/null) + if git show-ref -q --verify "refs/heads/$remote" + then + what=branch + else + what=commit + fi + echo "$rh $what '$remote'" + done | git-fmt-merge-msg + ) + merge_msg="${merge_msg:+$merge_msg$LF$LF}$merge_name" +fi +head=$(git-rev-parse --verify "$head_arg"^0) || usage # All the rest are remote heads test "$#" = 0 && usage ;# we need at least one remote head. -- 1.4.4.gbacc ``` ## Junio C Hamano, 2006-11-22 23:02 Subject: Re: Feature request: git-pull -e/--edit Message-ID: <7v3b8bozje.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3b8bozje.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061119212611.13038.qmail@science.horizon.com> ``` linux@horizon.com writes: > But I notice that --no-commit actually changes git's merging > technique. If it's specified, the trivial in-index merge doesn't > appear to be attempted. I don't think it makes a huge difference, > but is any difference desirable? This was done in response to a specific request from the list but I do not remember the details. If I were to research the background I would (1) first, look at the authordate of the commit that introduced the change. For this, I would most likely use: git log -p -S--no-commit -- git-pull.sh (2) go back to the list archive and find the thread that predates that commit by a few days. ```