Re: [PATCH 2/2] contrib/git-resurrect.sh: use hash-agnostic OID pattern
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Oct 8, 2020, 22:11 UTC
- Message-ID
- <20201008221101.GO1392312@camp.crustytoothpaste.net>
- In-Reply-To
- <20201008161345.GD2823778@coredump.intra.peff.net>
On 2020-10-08 at 16:13:45, Jeff King wrote:
Show 15 quoted lines
> On Wed, Oct 07, 2020 at 11:44:40PM -0700, Denton Liu wrote:
>
> > diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
> > index 57a77c03f9..d843df3afd 100755
> > --- a/contrib/git-resurrect.sh
> > +++ b/contrib/git-resurrect.sh
> > @@ -37,19 +37,18 @@ search_reflog_merges () {
> > )
> > }
> >
> > -_x40="[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]"
> > -_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
> > +oid_pattern=$(git hash-object --stdin </dev/null | sed -e 's/./[0-9a-f]/g')
>
> This looks correct, although...We could write this more simply as this:
oid_pattern=$(git hash-object /dev/null | sed -e 's/./[0-9a-f]/g')
I'm almost certain that works just fine, even on Windows, and I think the hashing code may be able to optimize better if we avoid --stdin (since it knows the size ahead of time). The performance benefit, if any, won't be that significant, though, since we're only hashing 7 bytes.
This is, of course, not worth a reroll in itself.
Show 17 quoted lines
> > search_merges () {
> > git rev-list --all --grep="Merge branch '$1'" \
> > --pretty=tformat:"%P %s" |
> > - sed -ne "/^$_x40 \($_x40\) Merge .*/ {s//\1/p;$early_exit}"
> > + sed -ne "/^$oid_pattern \($oid_pattern\) Merge .*/ {s//\1/p;$early_exit}"
> > }
> >
> > search_merge_targets () {
> > git rev-list --all --grep="Merge branch '[^']*' into $branch\$" \
> > --pretty=tformat:"%H %s" --all |
> > - sed -ne "/^\($_x40\) Merge .*/ {s//\1/p;$early_exit} "
> > + sed -ne "/^\($oid_pattern\) Merge .*/ {s//\1/p;$early_exit} "
> > }
>
> in both cases we are matching output we asked for, so we really matching
> [0-9a-f]\+ would be correct and sufficient. That's a little simpler. I
> don't feel too strongly either way, though.The problem here is that we'd need to write [0-9a-f][0-9a-f]* because this is a BRE and a backslashed + here is a GNU extension.
I'm fine with this patch (and patch 1) as it stands or with that change. I don't think this can be ambiguous, although if we think it can be (even with silly user behavior), then we should adopt this solution.
Show 7 quoted lines
> Side note: It's a shame that there is no way to convince rev-list not > to print the "commit ..." header, which is really what we're avoiding > here. We probably should have suppressed it with user-formats when > they were introduced, but it's too late to make that change. I wonder > if it would be worth adding a command-line option, though. I've often > had to hack around this when parsing rev-list output (and sometimes > even resort to using git-log if it's a one-off).
Yeah, I use git log for scripting more often than I'd like because rev-list can't remove the header. That would indeed be a welcome feature.
-- brian m. carlson: Houston, Texas, US