On 2019-04-16 15:03:54, Paul Wise wrote:
> On Tue, 2019-04-16 at 00:26 -0400, Antoine Beaupré wrote:
>
>> Ouch? Any practical way to do that?
>
> I think a normal `git bisect` but running `git cherry-pick` before
> doing tests should work, untested though.
>
>> And how would i reliable backport that patch systematically within
>> bisect anyways?
>
> Looks like it applies fine with `git cherry-pick` after checking out
> 1.20160123 so I suspect it will work fine with all the intermediary
> commits anyway. To determine if the commit is included in the current
> commit during the bisect, you can just `git grep is_active` or ask git
> with the `git merge-base --is-ancestor 15e7a50 HEAD` exit code. If the
> commit is already included, don't run `git cherry-pick`.
Okay, so here's an interesting data point. On Debian stretch, I can't
reproduce the bug, even when running from git, using on current master
(1.20180726-30-g6cf8003).
So maybe something else is going on here, outside of myrepos itself...
I'll try to reproduce with the cherry-picking when I get back home on
that buster machine later.
A.
--
Sous un gouvernement qui emprisonne injustement, la place de l’homme
juste est aussi en prison.
- La désobéissance civile, Henry David Thoreau
