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