From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] replace: parse revision argument for -d
Date: Mon, 29 Oct 2012 11:08:50 +0100 [thread overview]
Message-ID: <508E55B2.6060502@drmicha.warpmail.net> (raw)
In-Reply-To: <20121029090419.GA29464@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 29.10.2012 10:04:
> On Mon, Oct 29, 2012 at 10:02:47AM +0100, Michael J Gruber wrote:
>
>> Jeff King venit, vidit, dixit 29.10.2012 07:58:
>>> On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
>>>
>>>> for (p = argv; *p; p++) {
>>>> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>>>> + q = *p;
>>>> + if (get_sha1(q, sha1))
>>>> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
>>>> + else
>>>> + q = sha1_to_hex(sha1);
>>>
>>> Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
>>> else, it would not work anyway)?
>>
>> What is "this"???
>>
>> So far, "git replace -d <rev>" only accepts a full sha1, because it uses
>> it literally as a ref name "resf/replace/<rev>" without resolving anything.
>>
>> The patch makes it so that <rev> gets resolved to a sha1 even if it is
>> abbreviated, and then it gets used.
>>
>> Or do you mean the warning?
>
> Sorry, yeah, I meant the warning and fallback.
>
> If I understand correctly, the fallback will never work unless we are
> fed a 40-byte sha1. But get_sha1 should always return a 40-byte sha1
> without doing any further processing.
You do understand correctly, and I misunderstood get_sha1(). I does not
check for the presence of that sha1 in the object db, so that it
succeeds no matter what, that is: if it's valid hex. So I should
probably rewrite the error handling: no more need to check for lengths.
Michael
next prev parent reply other threads:[~2012-10-29 10:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 13:33 [PATCH] replace: parse revision argument for -d Michael J Gruber
2012-10-26 15:25 ` Christian Couder
2012-10-29 6:58 ` Jeff King
2012-10-29 9:02 ` Michael J Gruber
2012-10-29 9:04 ` Jeff King
2012-10-29 10:08 ` Michael J Gruber [this message]
2012-10-29 13:23 ` [PATCHv2] " Michael J Gruber
2012-11-09 16:48 ` Jeff King
2012-11-12 8:51 ` Michael J Gruber
2012-11-12 14:18 ` [PATCHv3] " Michael J Gruber
2012-11-12 20:42 ` Jeff King
2012-11-13 10:25 ` Michael J Gruber
2012-11-13 10:34 ` [PATCHv4] " Michael J Gruber
2012-11-13 13:37 ` Jeff King
2012-11-13 10:30 ` Notes in format-patch (was: Re: [PATCHv3] replace: parse revision argument for -d) Michael J Gruber
2012-11-13 13:38 ` Jeff King
2012-11-13 16:29 ` Notes in format-patch Junio C Hamano
2012-11-13 16:56 ` Junio C Hamano
2012-11-13 17:26 ` Junio C Hamano
2012-11-13 18:09 ` Junio C Hamano
2012-11-14 9:17 ` Michael J Gruber
2012-11-14 13:15 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=508E55B2.6060502@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).