"Michael S. Tsirkin" <mst@xxxxxxxxxxxxxxxxxx> writes:
> Hi!
> I often like to fetch some code from others, review and
> then merge. So:
>
> git fetch <URL>
> git log -p FETCH_HEAD
> git merge FETCH_HEAD
>
> which is all good but gets me this message in commit log:
>
> Merge commit 'FETCH_HEAD' into master
>
> which is not very informative.
> I can always fix this up with git commit --amend, but
> I'd like to avoid the extra step.
>
> Would the following patch be appropriate?
>
> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxxxxxxxxxx>
Would "Hi!" and "Would the following be appropriate?" be part of
the final commit log message?
I often hear from people who seems to like "fetch & merge",
instead of "pull & reset ORIG_HEAD", as a workflow to avoid
undesirable merging. This might largely be a matter of taste,
but from philosophical point of view, fetch & merge is a sign of
distrust (your default is not to merge, and you merge only when
you choose to), and pull & reset is the opposite (your default
is to merge, and after you inspect you may choose not to merge).
Tool support to encourage the former feels somewhat wrong.
Having said that, since that comes up every now and then, I
suspect it might make sense to have an optional behaviour in
"git pull" that lets you say...
$ git pull --preview $URL $refspec
which runs the following:
. git fetch
. git log -p `sed -e '/ not-for-merge /d'\
. -e 's/ .*//' $GIT_DIR/FETCH_HEAD` \
. --not HEAD
. asks you if you want to conclude this with a merge
. git merge if told, otherwise abort.
The "git-log" above reads "give me the commits that are
reachable from commits that are scheduled for merge but not in
the current HEAD", i.e. the ones that will get merged.
> diff --git a/git-merge.sh b/git-merge.sh
> index 8759c5a..629611b 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -108,6 +108,10 @@ merge_name () {
> git-show-ref -q --verify "refs/heads/$truname" 2>/dev/null
> then
> echo "$rh branch '$truname' (early part) of ."
> + elif test -r "$GIT_DIR/$remote"
> + then
> + echo -n "$rh "
> + grep -v not-for-merge "$GIT_DIR/$remote"
> else
> echo "$rh commit '$remote'"
> fi
This 'not-for-merge' grep is only good while merging FETCH_HEAD,
and will not work for any other random stuff in "$GIT_DIR", so
at least it should be more specific, not just checking if it is
the name of a readable file in $GIT_DIR. Somebody might find
good usecases for doing "git merge ORIG_HEAD" or "git merge
refs/bases/tutorial", for example, and your echo & grep would do
something "interesting".
Every time I added "echo -n" from my sloppiness, somebody sent
in a patch to replace it with "printf". I think people on non
Linux platforms would hate you for using "echo -n" (I should bug
Tytso about this with git-mergetool).
I am not sure what you meant by echo -n and grep -v. Other
codepaths in the if-else chain seems to create $rh (the value of
the single commit being merged) followed by two tabs followed by
the message, and each line in $GIT_DIR/FETCH_HEAD is already in
that format, so I suspect your code duplicates the commit object
name twice?
Even when you fetch more than one branch in FETCH_HEAD, using
FETCH_HEAD as an SHA-1 expression always picks up the object
name on the first line (iow "git merge FETCH_HEAD" will not
create an Octopus), so grepping for lines without not-for-merge
marker is not correct either.
You would probably want something like:
...
elif test FETCH_HEAD = "$remote" && test -r "$GIT_DIR/FETCH_HEAD"
then
sed -e 's/ not-for-merge / /' \
-e 1q "$GIT_DIR/FETCH_HEAD"
else
...
-
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