On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty wrote:
> Jokes apart, I'm not sure the chances of *both* those things happening
> -- an accidental hash-like string in the text *and* it matching an
> existing hash -- are high enough to bother. If it can be done without
> too much code, it probabl
On 07/03/2015 11:06 PM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> On 06/25/2015 05:41 AM, Junio C Hamano wrote:
>>> Sitaram Chamarty writes:
>>>
This *is* documented, but I'm curious why this distinction is made.
>>>
>>> I think it is from mere laziness, and also in a smaller de
Sitaram Chamarty writes:
> On 06/25/2015 05:41 AM, Junio C Hamano wrote:
>> Sitaram Chamarty writes:
>>
>>> This *is* documented, but I'm curious why this distinction is made.
>>
>> I think it is from mere laziness, and also in a smaller degree
>> coming from an expectation that --stdin would
On 06/25/2015 05:41 AM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> This *is* documented, but I'm curious why this distinction is made.
>
> I think it is from mere laziness, and also in a smaller degree
> coming from an expectation that --stdin would be fed by another
> script like rev
Sitaram Chamarty writes:
> This *is* documented, but I'm curious why this distinction is made.
I think it is from mere laziness, and also in a smaller degree
coming from an expectation that --stdin would be fed by another
script like rev-list where feeding full 40-hex is less work than
feeding u
Hi all,
"git name-rev" does not accept abbreviated SHAs if --stdin is used,
though it works when the SHA is given directly on the command line:
$ git version
git version 2.4.3
$ git name-rev --tags d73f544
d73f544 tags/v3.6.3~29
$ git name-rev --tags --stdin <<< d73f544
d7
6 matches
Mail list logo
