public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Johannes Sixt <j6t@kdbg•org>
Cc: git@vger•kernel.org
Subject: Re: jc/rerere-multi
Date: Thu, 21 Jan 2016 14:07:31 -0800	[thread overview]
Message-ID: <xmqq7fj2y4bg.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <56A0CA5D.8080407@kdbg.org> (Johannes Sixt's message of "Thu, 21 Jan 2016 13:09:01 +0100")

Johannes Sixt <j6t@kdbg•org> writes:

> I finally found some time to test and review this series. I have one
> case where there are many identical conflicts (up to 15!) that rerere
> was unable to resolve. But with this series applied, all of them are
> now resolved automatically and correctly. That's a nice achievement!
>
> Tested-by: Johannes Sixt <j6t@kdbg•org>
>
> I don't have the original submission anymore. So, I'm responding here.
>
> Generally, the patches make sense.

Thanks.  As the tip commit says, this is still incomplete in that
"record and replay" part should work reasonably well, but things
like "forget" and "gc" are areas that needs further looking into.

> Except for 510936082eb4 "handle leftover rr-cache/$ID directory and
> postimage files": After the subsequent e2a6344cca47 "delay the
> recording of preimage" is in place, nothing of what the former patch
> changed (except test cases) remains, and the problem that the former
> solved is still solved, and in addition the NEEDSWORK that the former
> introduced is resolved by the latter. I think the two should be
> squashed together.

Yeah, they were originally done as separate patches as I felt 'delay
the recording' step was much riskier and I was shooting for a series
whose earlier parts can be moved forward independently if necessary
in order to keep the size of the really hard part that has to be in
flight longer time manageably small.

But re-reading these two with fresh eyes, I think it is OK to squash
them into one.

> e2a6344cca47 (rerere: delay the recording of preimage) needs this
> fixup, I think:

Thanks for catching this (and this needs to be carried forward to
7/7 as well, I think).  This shows how little testing the new code
has gone through--a test certainly would have prepared an entry in
the rerere database with a stale postimage without the matching
preimage and noticed that things going wrong.

  reply	other threads:[~2016-01-21 22:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 23:33 What's cooking in git.git (Jan 2016, #04; Wed, 20) Junio C Hamano
2016-01-21 12:09 ` jc/rerere-multi (was: What's cooking in git.git (Jan 2016, #04; Wed, 20)) Johannes Sixt
2016-01-21 22:07   ` Junio C Hamano [this message]
2016-03-08 22:15     ` jc/rerere-multi Junio C Hamano
2016-01-22 16:58 ` What's cooking in git.git (Jan 2016, #04; Wed, 20) Johannes Schindelin
2016-01-22 17:57   ` Junio C Hamano
2016-01-26  9:47 ` Lars Schneider
2016-01-26 22:58   ` Junio C Hamano
2016-01-27  8:46     ` Lars Schneider
2016-01-27 18:03       ` Stefan Beller

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7fj2y4bg.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=j6t@kdbg$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox