From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: John Goerzen <jgoerzen@complete.org>, git@vger.kernel.org
Subject: Re: Two bugs with renaming
Date: Wed, 19 Mar 2008 21:45:53 -0700 [thread overview]
Message-ID: <7vbq5aypdq.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LFD.1.00.0803192059120.3020@woody.linux-foundation.org> (Linus Torvalds's message of "Wed, 19 Mar 2008 21:12:02 -0700 (PDT)")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Now, arguably, it should just see them as two independent issues, and then
> the rename detection will notice that the "files/delete.me" file got
> renamed as "files.upstream/delete.me", so *after* rename detection there
> will be no D/F conflict in the end result, but we see the conflict before
> that all even happens.
The common ancestor had files/delete.me.
Our side (test_branch) deleted files/delete.me, created
files.upstream/delete.me and created files.
Their side (master)kept files/delete.me without changing, created foo.
So I would think we should not even trigger D/F conflict at all.
- files/delete.me is deleted by only one side (our side) and it should go.
- files and files.upstream/delete.me are created by only one side (ours)
and it should stay.
- foo is created by only one side (theirs) and it should come.
However, we wanted to allow policy decision to happen after read-tree, and
we traditionally kept "one side removes" case as an internal conflict in
the index, later to be resolved by merge-one-file (and merge-recursive).
So I think the resulting index should look like this:
100644 xxxxxxx 0 files.upstream/delete.me
100644 xxxxxxx 1 files/delete.me
100644 xxxxxxx 3 files/delete.me
120000 xxxxxxx 0 files
100644 xxxxxxx 0 foo
or (if we also want to leave policy decision for "one side adds" case to
merge-one-file and merge-recursive) even:
100644 xxxxxxx 1 files/delete.me
100644 xxxxxxx 3 files/delete.me
120000 xxxxxxx 2 files
100644 xxxxxxx 2 files.upstream/delete.me
100644 xxxxxxx 2 foo
But that is not what is happening here. In fact, if you did not have
"files" in the test branch, here is what you will see:
100644 xxxxxxx 0 files.upstream/delete.me
100644 xxxxxxx 1 files/delete.me
100644 xxxxxxx 3 files/delete.me
100644 xxxxxxx 0 foo
and merge-recursive knows how to match up the first three entries and if
there are changes between stages #1 and #3 of files/delete.me, that is
carried forward to files.upstream/delete.me
Your unpack_trees() is bug-to-bug compatibile with Daniel's that is in
1.5.4. Both "read-tree -m -u" bails out with the same error, without
even leaving higher stage entries in the index.
prev parent reply other threads:[~2008-03-20 4:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 23:21 Two bugs with renaming John Goerzen
2008-03-20 0:51 ` Junio C Hamano
2008-03-20 2:06 ` Jeff King
2008-03-20 2:30 ` John Goerzen
2008-03-20 0:56 ` Jeff King
2008-03-20 1:24 ` Björn Steinbrink
2008-03-20 4:12 ` Linus Torvalds
2008-03-20 4:22 ` Linus Torvalds
2008-03-20 4:45 ` Junio C Hamano [this message]
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=7vbq5aypdq.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jgoerzen@complete.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.