Looking for a way to turn off/modify ref disambiguation

Looking for a way to turn off/modify ref disambiguation

[Nathan W. Panike]

A colleague at $dayjob recently caused corruption in our git
repository by accidentally running the command

git rebase origin stable

where they meant to run

git rebase origin/stable

The git-rev-parse(1) man page says:

...
<refname>, e.g. master, heads/master, refs/heads/master

    A symbolic ref name. E.g. master typically means the commit object
referenced by refs/heads/master. If you happen to have both
heads/master and tags/master, you can explicitly say heads/master to
tell git which one you mean. When ambiguous, a <name> is disambiguated
by taking the first match in the following rules:

       1.          If $GIT_DIR/<name> exists, that is what you mean
(this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
MERGE_HEAD and CHERRY_PICK_HEAD);
       2.          otherwise, refs/<name> if it exists;
       3.          otherwise, refs/tags/<refname> if it exists;
       4.          otherwise, refs/heads/<name> if it exists;
       5.          otherwise, refs/remotes/<name> if it exists;
       6.          otherwise, refs/remotes/<name>/HEAD if it exists.
...

Is there any way to change this behavior, e.g., so that rule 6 becomes
an error? Say, by setting a config option?

==========
Nathan Panike

Re: Looking for a way to turn off/modify ref disambiguation

[Jeff King]

On Tue, Aug 23, 2011 at 02:26:48PM -0500, Nathan W. Panike wrote:

>        1.          If $GIT_DIR/<name> exists, that is what you mean
> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
> MERGE_HEAD and CHERRY_PICK_HEAD);
>        2.          otherwise, refs/<name> if it exists;
>        3.          otherwise, refs/tags/<refname> if it exists;
>        4.          otherwise, refs/heads/<name> if it exists;
>        5.          otherwise, refs/remotes/<name> if it exists;
>        6.          otherwise, refs/remotes/<name>/HEAD if it exists.
> ...
> 
> Is there any way to change this behavior, e.g., so that rule 6 becomes
> an error? Say, by setting a config option?

You can remove the remote HEAD reference with:

  git remote set-head origin -d

That will only fix that particular repo, though. There is no config
option to disable it for all newly cloned repos.

-Peff

Re: Looking for a way to turn off/modify ref disambiguation

[Junio C Hamano]

"Nathan W. Panike" <nathan.panike@gmail.com> writes:

>        1.          If $GIT_DIR/<name> exists, that is what you mean
> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
> MERGE_HEAD and CHERRY_PICK_HEAD);
>        2.          otherwise, refs/<name> if it exists;
>        3.          otherwise, refs/tags/<refname> if it exists;
>        4.          otherwise, refs/heads/<name> if it exists;
>        5.          otherwise, refs/remotes/<name> if it exists;
>        6.          otherwise, refs/remotes/<name>/HEAD if it exists.
> ...
>
> Is there any way to change this behavior, e.g., so that rule 6 becomes
> an error?

You will force people to say "git log origin/master..master" to measure
their progress if you did so, when "git log origin..master" has been the
way described in many git books and documentation pages floating on the
web.

I think it is _very_ unlikely that such a change is going to happen.

Re: Looking for a way to turn off/modify ref disambiguation

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 24.08.2011 00:03:
> "Nathan W. Panike" <nathan.panike@gmail.com> writes:
> 
>>        1.          If $GIT_DIR/<name> exists, that is what you mean
>> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
>> MERGE_HEAD and CHERRY_PICK_HEAD);
>>        2.          otherwise, refs/<name> if it exists;
>>        3.          otherwise, refs/tags/<refname> if it exists;
>>        4.          otherwise, refs/heads/<name> if it exists;
>>        5.          otherwise, refs/remotes/<name> if it exists;
>>        6.          otherwise, refs/remotes/<name>/HEAD if it exists.
>> ...
>>
>> Is there any way to change this behavior, e.g., so that rule 6 becomes
>> an error?
> 
> You will force people to say "git log origin/master..master" to measure
> their progress if you did so, when "git log origin..master" has been the
> way described in many git books and documentation pages floating on the
> web.

I haven't come across advice like that. In our own documentation, we
don't explain it, and in our user-manual "origin" is used as the name of
a branch.

I consider that advice very bad indeed:

If "origin..master" is resolved to "master ^origin/master", then
obviously "origin..next" is resolved to "next ^origin/next" - but it is
not, of course, and the fact that "origin" is resolved to
"origin/master" depends on the content of "origin/HEAD", which the
upstream repo owner controls (in the sense that upstream's HEAD
determines it), not downstream.

Thus, teaching "origin..master" as a way of measuring your progress is
grossly misleading. "@{u}.." does that when you're on the branch in
question, and we have no notation for "@{u(master)}..master".

Side note:

In fact, who groks symbolic refs anyway? I mean, git-reset sets HEAD and
git-checkout does so, right? ;)
(I'm afraid I need to clean up after myself in git-reset(1)...)

> I think it is _very_ unlikely that such a change is going to happen.

If messing with the origin..master notation is the only fall-out I'm all
for it.

But note that the OP only asked for a way to turn off disambiguation,
not for a change of defaults..

Michael

Re: Looking for a way to turn off/modify ref disambiguation

[Jonathan Nieder]

Michael J Gruber wrote:

> "@{u}.." does that when you're on the branch in
> question, and we have no notation for "@{u(master)}..master".

"master@{u}..master" works, though it's not very short.

Re: Looking for a way to turn off/modify ref disambiguation

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> I haven't come across advice like that....
> I consider that advice very bad indeed:
>
> If "origin..master" is resolved to...

Perhaps origin..master was a bad example for you [*1*]; but the point is
you can say "origin" to mean the commit at the tip of the remote tracking
branch that the repository you cloned from deemed as its primary branch
anywhere we expect a commit on the command line.

So if you do not like "log origin..master", then say "git log origin"
instead and the point still stands.

[Footnote]

*1* "origin..master" is still a perfectly good example in tutorials to
teach people who use the workflow with a single at the central repository,
i.e. the simplest for esapee from CVS/SVN. You may have "frotz" topic and
"nitfol" topic branches locally cooking your own changes, and you can
measure their progress against the central repository with "origin..frotz"
and "origin..nitfol".

Re: Looking for a way to turn off/modify ref disambiguation

[Clemens Buchacher]

Hi Nathan,

On Tue, Aug 23, 2011 at 02:26:48PM -0500, Nathan W. Panike wrote:
> 
> Is there any way to change this behavior, e.g., so that rule 6 becomes
> an error? Say, by setting a config option?

I know you're trying to improve git. I do not want to discourage
that. But with little UI annoyances like this, it's usually not
worth it.  Git has countless magic tricks like this.  It's a bit
like perl in that regard. Assuming that we agree on what we would
like to get rid of (which is the hard part), it would still break
backwards compatibility. Maintaining a switch, on the other hand,
is overhead and in the end it would make git even more complicated,
because now the behavior of core commands depends on user
configuration.

But once you accept the fact that this is what git is, you can
tackle the problem in a different way:

> A colleague at $dayjob recently caused corruption in our git
> repository by accidentally running the command
> 
> git rebase origin stable

Ok, mistakes happen. But that's exactly why you have git: To be
able to deal with mistakes gracefully. So use git to review and
test changes before they get declared as a stable release (stable
enough to be used internally, at least). Then mistakes usually
become a local problem and can be undone using the reflog.

Clemens