On Wed, May 8, 2013 at 12:06 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> ...oops, I see I forgot the trailing && on this line. Do you want a
>> resend, or fix up yourself?
>
> I've pushed out a heavily fixed-up version on 'pu', mostly for
> styles and some log message changes to descri
Johan Herland writes:
> ...oops, I see I forgot the trailing && on this line. Do you want a
> resend, or fix up yourself?
I've pushed out a heavily fixed-up version on 'pu', mostly for
styles and some log message changes to describe "when it is not a
symref".
--
To unsubscribe from this list: se
On Tue, May 7, 2013 at 11:31 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> On Mon, May 6, 2013 at 7:52 PM, Junio C Hamano wrote:
>>> It is interesting that this bug has stayed so long with us, which
>>> may indicate that nobody actually uses the feature at all.
>>
>> I don't know if peopl
Johan Herland writes:
> On Mon, May 6, 2013 at 7:52 PM, Junio C Hamano wrote:
>> Johan Herland writes:
>>
>>> ... there is AFAICS _no_ way for sscanf() - having
>>> already done one or more format extractions - to indicate to its caller
>>> that the input fails to match the trailing part of the
Johan Herland writes:
> New version coming up. I'm going to rip this patch out of the
> surrounding series, since it doesn't really belong there anyway.
Thanks; will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor
On Mon, May 6, 2013 at 7:52 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> ... there is AFAICS _no_ way for sscanf() - having
>> already done one or more format extractions - to indicate to its caller
>> that the input fails to match the trailing part of the format string.
>
> Yeah, we ca
Johan Herland writes:
> ... there is AFAICS _no_ way for sscanf() - having
> already done one or more format extractions - to indicate to its caller
> that the input fails to match the trailing part of the format string.
Yeah, we can detect when we did not have enough, but we cannot tell
where i
On Sun, May 5, 2013 at 1:55 AM, Johan Herland wrote:
> When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
> we use the ref_rev_parse_rules list of expansion patterns. This list
> allows "origin" to be expanded into "refs/remotes/origin/HEAD", by
> using the "refs/remotes/%.*s/HE
When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
we use the ref_rev_parse_rules list of expansion patterns. This list
allows "origin" to be expanded into "refs/remotes/origin/HEAD", by
using the "refs/remotes/%.*s/HEAD" pattern from that list.
shorten_unambiguous_ref() exists
9 matches
Mail list logo
