Looking for a way to turn off/modify ref disambiguation

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

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

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

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

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.

Junio C Hamano venit, vidit, dixit 24.08.2011 00:03:

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

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

Michael J Gruber wrote:

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

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

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

Hi Nathan,

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

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:

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