git merge remote branch says "Merge commit ..."?

I noticed that if I do 'git merge origin/branch' that the log message
says (using --log):

Merge commit 'origin/branch'

   * commit 'origin/branch':
     Fixed some bug.

If I do the same thing from a local tracking branch of origin/branch, it says:

Merge branch 'branch'

   * branch:
     Fixed some bug.

Is it expected that it say "commit" instead of "branch" when the
branch is not a local tracking branch? I sometimes merge from remote
branches when I don't need to do anything with that branch locally
(e.g. I already did the work on another computer and I'm just merging
the result into my test machine before I push to the shared server).

On Thu, May 21, 2009 at 12:50:48PM -0700, skillzero@gmail.com wrote:

I noticed that if I do 'git merge origin/branch' that the log message
says (using --log):

Merge commit 'origin/branch'

   * commit 'origin/branch':
     Fixed some bug.

If I do the same thing from a local tracking branch of origin/branch, it says:

Merge branch 'branch'

   * branch:
     Fixed some bug.

Is it expected that it say "commit" instead of "branch" when the
branch is not a local tracking branch? I sometimes merge from remote
branches when I don't need to do anything with that branch locally
(e.g. I already did the work on another computer and I'm just merging
the result into my test machine before I push to the shared server).

I think doing a "git merge origin/master" is perfectly normal for some
workflows. For example:

  $ git fetch origin ;# grab it
  $ gitk origin/master...master ;# check if it is good to merge
  $ git merge origin/master ;# and merge it

The final step _could_ be a pull, but there is no point in repeating the
fetch (which might be costly).

There is already code in fmt-merge-msg to handle remote branches; it
looks like we just need to signal that code the same way "git fetch"
would. Maybe something like the patch below (which is really just a
cut-and-paste of the code directly above it to special-case real
branches).

It gives a sensible "Merge" line but you end up with

  * remote branch 'origin/master':
    ...

instead of

  * origin/master:
    ...

So it probably requires some deeper digging into what git-fetch is
doing, and to emulate that (I am pretty ignorant of this part of the
code).

---

diff --git a/builtin-merge.c b/builtin-merge.c
index 0b58e5e..a74a4d0 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c

@@ -378,6 +378,17 @@ static void merge_name(const char *remote, struct strbuf *msg)
 		goto cleanup;
 	}
 
+	strbuf_setlen(&buf, 0);
+	strbuf_addstr(&buf, "refs/remotes/");
+	strbuf_addstr(&buf, remote);
+	resolve_ref(buf.buf, branch_head, 0, 0);
+
+	if (!hashcmp(remote_head->sha1, branch_head)) {
+		strbuf_addf(msg, "%s\t\tremote branch '%s'\n",
+				sha1_to_hex(branch_head), remote);
+		goto cleanup;
+	}
+
 	/* See if remote matches <name>^^^.. or <name>~<number> */
 	for (len = 0, ptr = remote + strlen(remote);
 	     remote < ptr && ptr[-1] == '^';

Jeff King <peff <at> peff.net> writes:

I think doing a "git merge origin/master" is perfectly normal for some
workflows. For example:

  $ git fetch origin ;# grab it
  $ gitk origin/master...master ;# check if it is good to merge
  $ git merge origin/master ;# and merge it

The final step _could_ be a pull, but there is no point in repeating the
fetch (which might be costly).

My understanding is that if the objects already exist
locally then this is not going to be costly at all.
The negotiation of what is needed is cheap, isn't it?

- Eric

On Fri, May 22, 2009 at 05:29:41PM +0000, Eric Raible wrote:

Jeff King <peff <at> peff.net> writes:

quoted

I think doing a "git merge origin/master" is perfectly normal for some
workflows. For example:

  $ git fetch origin ;# grab it
  $ gitk origin/master...master ;# check if it is good to merge
  $ git merge origin/master ;# and merge it

The final step _could_ be a pull, but there is no point in repeating the
fetch (which might be costly).

My understanding is that if the objects already exist
locally then this is not going to be costly at all.
The negotiation of what is needed is cheap, isn't it?

No, it is not terribly expensive. But you do have to talk to the server,
which may mean making an ssh connection, or the server may be overloaded
and slow. So it can take a few seconds instead of a few microseconds.

There is actually another reason not to pull, though: you just inspected
what is in origin/master, so that is what you are expecting to merge.
If there is new stuff on the remote, you probably don't want to merge it
without similarly inspecting it.

-Peff

Jeff King <peff <at> peff.net> writes:

On Fri, May 22, 2009 at 05:29:41PM +0000, Eric Raible wrote:

quoted

Jeff King <peff <at> peff.net> writes:

quoted

I think doing a "git merge origin/master" is perfectly normal for some
workflows. For example:

  $ git fetch origin ;# grab it
  $ gitk origin/master...master ;# check if it is good to merge
  $ git merge origin/master ;# and merge it

The final step _could_ be a pull, but there is no point in repeating the
fetch (which might be costly).

My understanding is that if the objects already exist
locally then this is not going to be costly at all.
The negotiation of what is needed is cheap, isn't it?

No, it is not terribly expensive. But you do have to talk to the server,
which may mean making an ssh connection, or the server may be overloaded
and slow. So it can take a few seconds instead of a few microseconds.

There is actually another reason not to pull, though: you just inspected
what is in origin/master, so that is what you are expecting to merge.
If there is new stuff on the remote, you probably don't want to merge it
without similarly inspecting it.

-Peff

I wasn't trying to argue that a pull would be a good idea, but more
that it's not that expensive because of the content-addressable
nature of git's object store.

And saying that is "might be costly" could be misleading to people
who haven't groked how a commit is a commit is a commit.

- Eric

On Fri, May 22, 2009 at 06:08:41PM +0000, Eric Raible wrote:

I wasn't trying to argue that a pull would be a good idea, but more
that it's not that expensive because of the content-addressable
nature of git's object store.

And saying that is "might be costly" could be misleading to people
who haven't groked how a commit is a commit is a commit.

OK, then I agree with you. My "costly" was just "I don't want to touch
the network if I don't have to".

-Peff

On Freitag, 22. Mai 2009, Jeff King wrote:

No, it is not terribly expensive. But you do have to talk to the server,
which may mean making an ssh connection, or the server may be overloaded
and slow. So it can take a few seconds instead of a few microseconds.

It's certainly doable without a remote connection with some digging in the 
configuration.

Git-gui has some magic to find out the remote when you request to merge a 
remote tracking branch. That is, even though you clickety-click through to do 
the equivalent of 'git merge origin/master', it comes up with a merge message 
that is the same as if you had said 'git pull origin master' on the command 
line. It doesn't need a connection to do that.

-- Hannes

On Fri, May 22, 2009 at 08:30:34PM +0200, Johannes Sixt wrote:

On Freitag, 22. Mai 2009, Jeff King wrote:

quoted

No, it is not terribly expensive. But you do have to talk to the server,
which may mean making an ssh connection, or the server may be overloaded
and slow. So it can take a few seconds instead of a few microseconds.

It's certainly doable without a remote connection with some digging in the 
configuration.

Er, I think we have gotten a bit off track.

Yes, it's clearly possible to pretend you fetched but not actually do so
when doing "git merge origin/master" (and the patch I posted does
something close, but doesn't fill in the actual remote name; you just
get "remote branch origin/master").

All the other part of this thread was just me claiming that:

  git fetch origin
  git log origin...
  git merge origin

Is a totally valid workflow, and that the answer should not be "those
people should just run pull".

Git-gui has some magic to find out the remote when you request to merge a 
remote tracking branch. That is, even though you clickety-click through to do 
the equivalent of 'git merge origin/master', it comes up with a merge message 
that is the same as if you had said 'git pull origin master' on the command 
line. It doesn't need a connection to do that.

Right. We could probably use similar logic in "git merge". I'm not sure
if it is worth the trouble to end up with "Merge branch 'master' of
origin" instead of "Merge remote branch 'origin/master'".

-Peff