On 2020-10-08 at 16:13:45, Jeff King wrote:
> 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.
> > 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.
> 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
Attachment:
signature.asc
Description: PGP signature
