On Tuesday, March 11, 2014 12:10:06 PM UTC+1, Daniel Fanjul wrote:
>
> 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? 
>
> <https://github.com/daniel-fanjul-alcuten>
>
I can't really say much about the validity of the feature, as I haven't 
thought it over :)

But one quick answer is that feature requests should go to the Git dev list 
[1], although it's fine to have some user-related discussions on this list 
before you bring it to the devs.

[1] https://gist.github.com/tfnico/4441562

-- 
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to