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

Johannes Schindelin [off-list ref] writes:

quoted

I wondered why it doesn't hook into interpret_branch_name(), and instead 
adds itself to the static substitute_branch_name(); it forbids the use 
of the syntax from by callers of strbuf_branchname().

I _think_ it was to allow something like

	git log -g @{u}

but frankly, this is so long ago, I do not remember, I reconstructed this 
reasoning as being the most likely.

That is not the question I was asking.

If you compare substitute_branch_name() and interpret_branch_name() before
your patch, you will notice that they are _meant_ to do the same thing,
with different external API, only because many callers in sha1_name.c do
not use strbuf to hold their names.  The primary API is the latter (which
is extern), and the former (which is static) is merely a helping wrapper
that is internal to sha1_name.c

But with your patch, they suddenly have different semantics, and the
function that implements the primary API doesn't know anything about
this new @{upstream} syntax.

This discrepancy will affect callers of strbuf_branchname(), e.g.
merge_name() in builtin-merge.c that prepares the "Merge branch nitfol of
remote frotz" message, or delete_branches() in builtin-branch.c.

Note that I am not saying "branch -d @{upstream}" should or should not
work (at least not yet---I haven't thought the issues through).  But I
wanted to know if this subtle change in the semantics was a deliberate
choice, and if so wanted to see the reason behind it described clearly.

Hi,

On Wed, 13 Jan 2010, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

quoted

I wondered why it doesn't hook into interpret_branch_name(), and 
instead adds itself to the static substitute_branch_name(); it 
forbids the use of the syntax from by callers of strbuf_branchname().

I _think_ it was to allow something like

	git log -g @{u}

but frankly, this is so long ago, I do not remember, I reconstructed this 
reasoning as being the most likely.

That is not the question I was asking.

If you compare substitute_branch_name() and interpret_branch_name() before
your patch, you will notice that they are _meant_ to do the same thing,
with different external API, only because many callers in sha1_name.c do
not use strbuf to hold their names.  The primary API is the latter (which
is extern), and the former (which is static) is merely a helping wrapper
that is internal to sha1_name.c

So you meant to say that substitute_branch_name() calls 
interpret_branch_name(), so the change should be in the latter.  (This is 
supposed to be the summary of your 4 paragraphs.)

I have no problems with that, except that I do not have the time to do it 
myself.

Ciao,
Dscho

Johannes Schindelin [off-list ref] writes:

So you meant to say that substitute_branch_name() calls 
interpret_branch_name(), so the change should be in the latter.  (This is 
supposed to be the summary of your 4 paragraphs.)

Not quite.  What I was asking was:

	*PROVIDED* *IF* you wanted to keep the same semantics between
         them, then you would have patched i-b-n, but you didn't.  Was there
         a reason callers of s-b-n should know about @{u} but callers of i-b-n
	shouldn't?

Expected answer was either:

	(a) Codepath X that uses i-b-n shouldn't interpret @{upstream} as
            a symbolic name given by the user, but it should treat it as a
            mere SHA-1 expression instead for *this and that* reason.
            Otherwise we will see *this* breakage when the user does
            *that*.  That is why i-b-n doesn't know about the new syntax;
            or

	(b) It was a thinko; all codepaths that use i-b-n should know the
            new syntax as they _are_ interested in learning the symbolic
            name when the user gives @{upstream}.

Hi,

On Wed, 13 Jan 2010, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

What I was asking was:

	*PROVIDED* *IF* you wanted to keep the same semantics between
         them, then you would have patched i-b-n, but you didn't.  Was there
         a reason callers of s-b-n should know about @{u} but callers of i-b-n
	shouldn't?

Expected answer was either:

	(a) Codepath X that uses i-b-n shouldn't interpret @{upstream} as
            a symbolic name given by the user, but it should treat it as a
            mere SHA-1 expression instead for *this and that* reason.
            Otherwise we will see *this* breakage when the user does
            *that*.  That is why i-b-n doesn't know about the new syntax;
            or

	(b) It was a thinko; all codepaths that use i-b-n should know the
            new syntax as they _are_ interested in learning the symbolic
            name when the user gives @{upstream}.

And I gave answer (c): I do not remember.

Ciao,
Dscho