Johan Herland wrote:
> Unfortunately, using "refs/remotes/%1/%*" instead of "refs/remotes/%*"
> breaks a number of git-svn tests which puts refs directly within
> refs/remotes/, and then does things like "git reset --hard trunk"
> (expecting trunk -> refs/remotes/trunk, which the refs/remotes/%1/%
Johan Herland writes:
> On Wed, May 15, 2013 at 9:39 AM, Johan Herland wrote:
>> On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty
>> wrote:
>>> "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to
>>> imply that the rule should only be attempted if the input has at least
>>>
On Wed, May 15, 2013 at 9:39 AM, Johan Herland wrote:
> On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty
> wrote:
>> "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to
>> imply that the rule should only be attempted if the input has at least
>> two components, whereas somethi
On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty wrote:
> On 05/14/2013 04:24 PM, Johan Herland wrote:
>> I am not sure why we would want "refs/remotes/%1/%2" instead of
>> "refs/remote/%*". Maybe I've been staring at this for too long, but I
>> find the latter shorter and more descriptive and th
On 05/14/2013 04:24 PM, Johan Herland wrote:
> On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>> Johan Herland writes:
Obviously, I named it '%1' since it expands into the _first_ component
of the (slash-separated) shorthand.
>>>
>>> OK, I can buy so
Johan Herland writes:
> I think I like "refs/peers/%1/heads/%*" better than
> "refs/peers/%1/heads/%2", since the latter sort of makes me wonder
> whether the 3rd, 4th, etc. components would be discarded.
Makes sense.
> I am not sure why we would want "refs/remotes/%1/%2" instead of
> "refs/rem
On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>> Johan Herland writes:
>>> Obviously, I named it '%1' since it expands into the _first_ component
>>> of the (slash-separated) shorthand.
>>
>> OK, I can buy something like
>>
>> %*
>> refs/%*
>>
Junio C Hamano writes:
> Johan Herland writes:
>
>> Obviously, I named it '%1' since it expands into the _first_ component
>> of the (slash-separated) shorthand.
>
> OK, I can buy something like
>
> %*
> refs/%*
> refs/heads/%*
> ...
> refs/remotes/%*/HEAD
>
Johan Herland writes:
> Obviously, I named it '%1' since it expands into the _first_ component
> of the (slash-separated) shorthand.
OK, I can buy something like
%*
refs/%*
refs/heads/%*
...
refs/remotes/%*/HEAD
refs/remotes/%1/%2
refs/pee
On Mon, May 13, 2013 at 6:56 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> The refname_expand() function no longer uses mkpath()/mksnpath() to
>> perform the pattern expansion. Instead, it uses strbuf_expand(), which
>> removes the need for using fixed-length buffers from the code.
>
> I
Johan Herland writes:
> The refname_expand() function no longer uses mkpath()/mksnpath() to
> perform the pattern expansion. Instead, it uses strbuf_expand(), which
> removes the need for using fixed-length buffers from the code.
It is a brilliant idea to use strbuf_expand() for this. I like it.
This patch is in preparation for extending the ways in which we expand
shorthand names into full refnames, and shorten full refnames into
unambiguous shorthand names.
We collect the logic for performing the expansion and shortening into two
functions: refname_expand() and refname_shorten(). refnam
12 matches
Mail list logo