Currently, branch_get() either accepts either a branch name, empty
string, or the magic four-letter word HEAD. Make it additionally
handle symbolic refs that point to a branch.
Update sha1_name.c:interpret_branch_name() to look for @{, not '@'
(since '@' is a valid symbolic ref).
These two
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Currently, branch_get() either accepts either a branch name, empty
string, or the magic four-letter word HEAD. Make it additionally
handle symbolic refs that point to a branch.
Update
Felipe Contreras wrote:
But why? I'm not familiar with branch_get, but my intuition tells me
you are changing the behavior, and now branch_get() is doing something
it wasn't intended to do. And for what?
Why is there a commit message? I've explained what the behavior change is.
Your
On Wed, May 1, 2013 at 1:44 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
But why? I'm not familiar with branch_get, but my intuition tells me
you are changing the behavior, and now branch_get() is doing something
it wasn't intended to do. And for what?
Why is
Felipe Contreras wrote:
As I said, the @@{u} thing can be fixed through other ways.
It's not just @@{u}. I can have lots of custom symbolic refs working
properly; I might choose D for my deleted-reflogs, M for master and so
on.
$ git log M..
The point is that my solution solves the
On Wed, May 1, 2013 at 2:50 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
As I said, the @@{u} thing can be fixed through other ways.
It's not just @@{u}. I can have lots of custom symbolic refs working
properly; I might choose D for my deleted-reflogs, M for
On Wed, May 1, 2013 at 3:57 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
If you are arguing in favor of arbitrary symbolic refs plus @{u} to
work, a patch that allows that, and nothing else, should make sense.
Such patch would trigger further discussion, for
7 matches
Mail list logo
