Hi, In the man page of git-rev-parse<https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html>, we can read how to resolve abbreviated refs:
When ambiguous, a *<refname>* is disambiguated by taking the first match in the following rules: 1. If *$GIT_DIR/<refname>* 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/<refname>* if it exists; 3. otherwise, *refs/tags/<refname>* if it exists; 4. otherwise, *refs/heads/<refname>* if it exists; 5. otherwise, *refs/remotes/<refname>* if it exists; 6. otherwise, *refs/remotes/<refname>/HEAD* if it exists. It would be nice if there were more rules, specifically: 7. otherwise, refs/heads/*<username>*/<refname> if it exists; 8. otherwise, refs/remotes/*<username>*/<refname> if it exists; 9. otherwise, refs/remotes/*<username>*/<refname>/HEAD if it exists; People usually have many personal branches like dfanjul/topic1, dfanjul/topic2, being 'dfanjul' a username. It would be nice to run 'git checkout topic1' or other git commands knowing that git will try refs/topic1, refs/heads/topic1, refs/heads/dfanjul/topic1, etc. I know there are other alternatives like: - creating of symbolic refs: git symoblic-ref refs/heads/topic1 dfanjul/topic1 - change name of local branches: git config branch.topic1.merge refs/heads/dfanjul/topic1 But they don't do exactly the same and have different pros and cons. Questions: - Do you have more alternatives? - Would my proposal be useful for some/many people? - Is this mailing list the proper way to submit this feature request? Thanks in advance, Daniel. -- Daniel Fanjul Alcutén Tools Engineer @Spotify AB https://github.com/daniel-fanjul-alcuten -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
