From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/5] rebase -r: demonstrate bug with conflicting merges
Date: Tue, 13 Nov 2018 11:12:18 +0100 (STD) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1811131109360.39@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqh8glyajx.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Tue, 13 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > When calling `merge` on a branch that has already been merged, that
> > `merge` is skipped quietly, but currently a MERGE_HEAD file is being
> > left behind and will then be grabbed by the next `pick` (that did
> > not want to create a *merge* commit).
> >
> > Demonstrate this.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > t/t3430-rebase-merges.sh | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
>
> For a trivially small change/fix like this, it is OK and even
> preferrable to make 1+2 a single step, as applying t/ part only to
> try to see the breakage (or "am"ing everything and then "diff |
> apply -R" the part outside t/ for the same purpose) is easy enough.
I disagree. It helps both development and porting to different branches to
be able to cherry-pick the regression test individually. Please do not ask
me to violate this hard-learned principle.
> Because the patch 2 with your method ends up showing only the test
> set-up part in the context by changing _failure to _success, without
> showing what end-user visible breakage the step fixed, which usually
> comes near the end of the added test piece. A single patch that
> gives tests that ought to succeed would not force the readers to
> switch between patches 1 and 2 while reading the fix.
That is why I put in a verbose commit message, so that you do not have to
guess. And even the test title talks about this.
Seriously, I am very much opposed to changing the patches in the direction
you suggested. In my mind, they would make the story substantially worse.
Thank you for your review,
Dscho
>
> Of course, the above would not apply for a more involved case where
> the actual fix to the code needs to span multiple patches.
>
> Thanks.
>
> > diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh
> > index aa7bfc88ec..1f08a33687 100755
> > --- a/t/t3430-rebase-merges.sh
> > +++ b/t/t3430-rebase-merges.sh
> > @@ -396,4 +396,20 @@ test_expect_success 'with --autosquash and --exec' '
> > grep "G: +G" actual
> > '
> >
> > +test_expect_failure '--continue after resolving conflicts after a merge' '
> > + git checkout -b already-has-g E &&
> > + git cherry-pick E..G &&
> > + test_commit H2 &&
> > +
> > + git checkout -b conflicts-in-merge H &&
> > + test_commit H2 H2.t conflicts H2-conflict &&
> > + test_must_fail git rebase -r already-has-g &&
> > + grep conflicts H2.t &&
>
> Is this making sure that the above test_must_fail succeeded because
> of a conflict and not due to any other failure? I would have used
> "ls-files -u H2.t" to see if the index is unmerged, which probably
> is a more direct way to test what this is trying to test, but if we
> are in the conflicted state, the one side of << == >> has this
> string (the other has "H2" in it, presumably?), so in practice this
> should be good enough.
>
> > + echo resolved >H2.t &&
> > + git add -u &&
>
> and we resolve to continue.
>
> > + git rebase --continue &&
> > + test_must_fail git rev-parse --verify HEAD^2 &&
>
> Even if we made an octopus by mistake, the above will catch it,
> which is good.
>
> > + test_path_is_missing .git/MERGE_HEAD
> > +'
> > +
> > test_done
>
> And from the proposed log message, I am reading that the last two
> things (i.e. resulting tip is a child with a single parent and there
> is no leftover MERGE_HEAD file) fail without the fix.
>
> This is enough material to convince me or anybody that the bug is
> worth fixing. Thanks for being careful noticing a glitch during
> your real (and otherwise unrelated to the bug) work and following
> through.
>
next prev parent reply other threads:[~2018-11-13 10:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-12 23:25 [PATCH 0/5] Assorted fixes revolving around rebase and merges Johannes Schindelin via GitGitGadget
2018-11-12 23:25 ` [PATCH 1/5] rebase -r: demonstrate bug with conflicting merges Johannes Schindelin via GitGitGadget
2018-11-13 2:29 ` Junio C Hamano
2018-11-13 10:12 ` Johannes Schindelin [this message]
2018-11-13 12:06 ` Junio C Hamano
2018-11-13 12:47 ` Johannes Schindelin
2018-11-13 12:56 ` Junio C Hamano
2018-11-12 23:25 ` [PATCH 2/5] rebase -r: do not write MERGE_HEAD unless needed Johannes Schindelin via GitGitGadget
2018-11-12 23:25 ` [PATCH 3/5] rebase -i: include MERGE_HEAD into files to clean up Johannes Schindelin via GitGitGadget
2018-11-13 2:07 ` Junio C Hamano
2018-11-12 23:26 ` [PATCH 4/5] built-in rebase --skip/--abort: clean up stale .git/<name> files Johannes Schindelin via GitGitGadget
2018-11-13 2:11 ` Junio C Hamano
2018-11-13 10:14 ` Johannes Schindelin
2018-11-12 23:26 ` [PATCH 5/5] status: rebase and merge can be in progress at the same time Johannes Schindelin via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1811131109360.39@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).