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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html