From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Cc: Daniel Barkalow <barkalow@iabervon.org>,
Alex Riesen <raa.lkml@gmail.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: [PATCH 0/5] merge-recursive D/F conflict improvements
Date: Sat, 07 Apr 2007 07:39:21 -0700 [thread overview]
Message-ID: <7vd52gckpy.fsf@assigned-by-dhcp.cox.net> (raw)
This series is on top of my "read-tree-df" topic, which is in
'next'.
The part that are already in 'next' deal with switching branches
when the current branch has a file (or symlink) where the
switched-to branch has a directory (or vice versa), and is about
fixing "git-read-tree -m -u A B" 2-way merges.
This series deals with both "git-read-tree -m u O A B" 3-way
merges, and "git-merge-recursive". It comes with tests, but
because these two programs are really central part of everyday
branch growing (the other important part is the revision walking
machinery which is obviously the central part of archaeology), I
would really need help from people who have worked in this area
for extra sets of eyeballs.
[PATCH 1/5]
t1000: fix case table.
This one is immaterial; while working on 2/5, I wondered
why threeway_merge() did not handle case #10, and tried
to fix it by adding a case. Obviously it broke existing
tests and I recalled that contrary to the case table
presented there, we decided that "stays in one side
while the other side removes" case could be a sign of
the path being renamed away and let the caller deal with
it. So this patch fixes the case table to match the
design and the code.
[PATCH 2/5]
Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()
[PATCH 3/5]
merge-recursive: do not barf on "to be removed" entries.
[PATCH 4/5]
merge-recursive: handle D/F conflict case more carefully.
[PATCH 5/5]
t3030: merge-recursive backend test.
reply other threads:[~2007-04-07 14:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=7vd52gckpy.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=raa.lkml@gmail.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.
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 NNTP newsgroup(s).