reassign 955152 git
found 955152 + 1:2.26.0-1
notfound 955152 + 1:2.25.1-1 1:2.11.0-3+deb9u5
retitle 955152 git-rebase ignores or squashes GIT_REFLOG_ACTION
user debian...@lists.debian.org
usertags 955152 - needs-update
thanks
Hi all. Thanks to Paul for actually filing this bug.
tl;dr: I think this is a regression in src:git and that the test case
in src:dgit is correct and will pass once the git regression is gone.
Paul Gevers writes ("Bug#955152: git breaks dgit autopkgtest: gdr-newupstream
test failed"):
> pass fail
> git from testing 1:2.26.0-1
> dgit from testing 9.10
> all others from testing from testing
...
> I copied some of the output at the bottom of this report. Unfortunately
> I couldn't spot where the real error is reported.
Sorry that the test output is not as readable as it could be. I have
a patch to improve this but it would still not be very easy to see
since it's not clear from the log why the test is grepping as it does.
The real error, causing the test failure, is this:
[ some git-debrebase invocation etc. ]
+ git reflog
+ egrep 'debrebase new-upstream.*checkout'
+ rc=1
I have looked at the log and repro'd the bug.
git-debrebase (which lives in src:dgit but does not depend on dgit)
must invoke git-rebase. It sets GIT_REFLOG_ACTION so that the reflog
is comprehensible to the user. In previous versions of git this works
as expected. In 2.26.0-1 it does not.
This is easy to reproduce by running
GIT_REFLOG_ACTION='zeeks!' git rebase --onto <something> <somethingelse>
with arguments implying a nontrivial rebase.
The test suite in src:dgit, which is the checks that its
GIT_REFLOG_ACTION manipulation is effective, and it is this test which
has now failed and which is blocking the migration of git.
git-rebrebase in sid produces quite different looking reflog entries.
I guess the code for generating the messages has changed and that
git-rebase is now *setting* GIT_REFLOG_ACTION (or the equivalent
internal variable) rather than adding to it.
ISTM that to preserve the documented semantics, it is basically always
wrong of anything to unconditionally set GIT_REFLOG_ACTION. In
src:dgit I have a small bit of code to arrange to always *add* to
GIT_REFLOG_ACTION, if it is already set. There might be several
precise ways to add to GIT_REFLOG_ACTION but the failing test case
here should be happy with any reasonable choice.
So I think all will be well when there is a version of git in sid
which does not have this (new) bug.
> Currently this regression is blocking the migration of git to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?
I hope what I have done with the bug (i) has the right syntax and did
what I hoped and (ii) meets with everyone's approval.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
