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

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

[skillzero]

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).

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

[Jeff King]

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] == '^';

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

[Eric Raible]

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

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

[Jeff King]

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

> 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?

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

Re: git merge remote branch says

[Eric Raible]

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

> On Fri, May 22, 2009 at 05:29:41PM +0000, Eric Raible wrote:
> 
> > 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?
> 
> 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

Re: git merge remote branch says

[Jeff King]

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

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

[Johannes Sixt]

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

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

[Jeff King]

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

> 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.

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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'".

I do not think it is worth doing that to lose information, either.

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

[Jeff King]

On Sat, May 23, 2009 at 02:26:58AM -0700, Junio C Hamano wrote:

> > 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'".
> 
> I do not think it is worth doing that to lose information, either.

So would you be in favor of this patch?

-- >8 --
Subject: [PATCH] merge: indicate remote tracking branches in merge message

Previously when merging directly from a local tracking
branch like:

  git merge origin/master

The merge message said:

   Merge commit 'origin/master'

     * commit 'origin/master':
       ...

Instead, let's be more explicit about what we are merging:

   Merge remote branch 'origin/master'

     * origin/master:
       ...

We accomplish this by recognizing remote tracking branches
in git-merge when we build the simulated FETCH_HEAD output
that we feed to fmt-merge-msg.

Signed-off-by: Jeff King <peff@peff.net>
---
This is not quite identical to the one I posted before; it adds the
magic "of ." at the end of the line, which matches how regular
non-remote branches are handled.

 builtin-merge.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/builtin-merge.c b/builtin-merge.c
index 0b58e5e..b6f60e9 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' of .\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] == '^';
-- 
1.6.3.1.250.g01b8b.dirty