Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [not even design notes yet] teaching rerere to remember removal?
Date: Thu, 18 May 2023 15:18:02 -0700	[thread overview]
Message-ID: <xmqq353ts2qt.fsf@gitster.g> (raw)

This is more like just an early scratches on paper that might some
day turn into a design.

A side branch can remove path P, while the mainline, since the side
branch forked from it, can modify P.  When such a side branch is
merged to the mainilne, we would see a 'one side modified, the other
side removed' merge conflict.  The change made on the mainline may
be of small significance (e.g. code restructuring), while the
removal done on the side branch may be of bigger significance
(e.g. the command implemented by the file P is no longer necessary).

For safety, the rerere mechanism does not unconditionally remember
such a removal and replay.  When you resolve such a conflict in
favor of removal of P after looking at it, the decision to remove it
may be reasonable, but if you let the mainline further tweak P
without knowing other party working on the side branch is planning
to remove it, at some point you may want to reconsider the decision
to discard the changes made to P on the mainline.  The discarded
changes may not be important enough to make you want to resurrect
the change and side-port to another path, but at least you would
want to have a chance to double check and decide that the new
work the mainline did to P is still discardable.

So I am wondering what should be used as the record of "if the other
branch made this change, we have seen this conflict already, and we
know it is safe to resolve it to remove the path".  As such a
conflict will leave either stages 1 & 2 (we modified, while they
removed), or 1 & 3 (we removed, while they kept working on it), e.g.

    $ git ls-files -u
    100644 d1d63feaa9e299ace44d228176cd2b4335193569 1	t/helper/test-fast-rebase.c
    100644 cac20a72b3fcb52c5ccb66cbbb1679ecb8f39f97 2	t/helper/test-fast-rebase.c

one idea is to take a textual diff of these two stages:

    $ git diff :{1,2}:t/helper/test-fast-rebase.c
    diff --git a/t/helper/test-fast-rebase.c b/t/helper/test-fast-rebase.c
    index d1d63feaa9..cac20a72b3 100644
    --- a/t/helper/test-fast-rebase.c
    +++ b/t/helper/test-fast-rebase.c
    @@ -12,15 +12,16 @@

     #define USE_THE_INDEX_VARIABLE
     #include "test-tool.h"
    -#include "cache.h"
     #include "cache-tree.h"
     #include "commit.h"
     #include "environment.h"
     #include "gettext.h"
    +#include "hash.h"
     #include "hex.h"
     #include "lockfile.h"
     #include "merge-ort.h"
     #include "object-name.h"
    +#include "read-cache-ll.h"
     #include "refs.h"
     #include "revision.h"
     #include "sequencer.h"

and record that when we that one side made this change to a path
while the other side removed the path, we know it is safe to resolve
such a conflict to remove the path.

The "rerere conflict ID" (the directory name under .git/rerere/ that
each rerere database entry uses) is most likely the SHA-1 hash of the
above patch text, with pathname and line numbers redacted.


             reply	other threads:[~2023-05-18 22:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 22:18 Junio C Hamano [this message]
2023-05-19  7:51 ` [not even design notes yet] teaching rerere to remember removal? Oswald Buddenhagen

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=xmqq353ts2qt.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /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.
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).