Re: default behaviour for `gitmerge` (no arguments)

From: Jeff King <peff@peff.net>
Date: Jan 12, 2010, 18:25 UTC
Message-ID: <20100112182550.GA15696@coredump.intra.peff.net>
In-Reply-To: <7vhbqr2nxt.fsf@alter.siamese.dyndns.org>

On Tue, Jan 12, 2010 at 10:11:26AM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Hmm. If we had the oft-discussed-but-never-agreed-upon shorthand for
> > "the upstream of" then we wouldn't need a special merge option. You
> > could just do:
> >
> >   git merge %HEAD ;# (or git merge %, IIRC the proposal correctly)
> 
> I don't think "whatever _HEAD_ tracks" makes sense at the semantic level
> (i.e. you don't do "branch.HEAD.merge") but a syntax for "whatever the
> named _branch_ tracks" with "if a branch is not named, the current branch
> is implied" (i.e. the one in parentheses) would.

The patch that Dscho provided would actually convert HEAD@{upstream} into the upstream of whatever HEAD pointed at. Which I think makes sense. We don't do it for reflogs, but that is because it is useful to distinguish between the reflog for a symref and the thing it points to. But since one would presumably not make such a configuration for a symref, that distinction is not useful.

> It is an entirely different matter what the special syntax to trigger that
> "upstream-ness" should be.  I vaguely recall @{upstream} or @{u} were the
> concensus?

Ah, right. I remembered hating "%" even as I typed it, but I had forgotten about the followup discussion. Looking at it again, I note:

  1. The last posted patch still has a misplaced free() (patch below),
     but I think otherwise is not buggy.

  2. We don't complain on "git show @{usptream}" and we probably should.
     I remember there being some complications because the contents of
     @{} were passed to approxidate, but I think we can get around that
     by letting approxidate complain if _nothing_ in the date was
     useful. So "git show @{2.weeks.and.7.hot.dogs.ago}" would still
     work, but "git show @{totally.bogus.input}" would complain.

  3. I have actually been running with Dscho's patch for the last couple
     of months, and I don't remember using it once. So perhaps it is not
     as useful as I might have thought. :)

Anyway, fixup patch is below. I don't expect you to pick up the topic or anything, but since I went to the trouble to find the bug once upon a time, I thought I would post the fix for anybody who does want to pick it up.

diff --git a/sha1_name.c b/sha1_name.c
index b73b93e..da90ebe 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -275,9 +275,9 @@ static char *substitute_branch_name(const char **string, int *len)
 		char *ref = xstrndup(*string, *len - ret);
 		struct branch *tracking = branch_get(*ref ? ref : NULL);
 
-		free(ref);
 		if (!tracking)
 			die ("No tracking branch found for '%s'", ref);
+		free(ref);
 		if (tracking->merge && tracking->merge[0]->dst) {
 			*string = xstrdup(tracking->merge[0]->dst);
 			*len = strlen(*string);