From: Junio C Hamano <gitster@pobox.com>
To: Clemens Buchacher <drizzd@aon.at>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] modify/delete conflict resolution overwrites untracked file
Date: Sun, 14 Dec 2008 19:34:46 -0800 [thread overview]
Message-ID: <7vmyeyyuuh.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7v63lm1c76.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 14 Dec 2008 17:03:57 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
>> On Wed, Dec 10, 2008 at 09:12:59PM +0100, Clemens Buchacher wrote:
>>> If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
>>> will result in a "CONFLICT (delete/modify)". If the (now untracked) file
>>> already exists and was not added to the index, it is overwritten with the
>>> conflict resolution contents.
>>
>> The following patch fixes the problem described above, but it also breaks
>> t6023-merge-rename-nocruft.sh, which tries to merge "A" renamed to "B" in
>> HEAD and "A" modified in MERGE_HEAD, while ignoring an untracked file "A" in
>> the working tree. If we want to be able to do this, we have to handle the
>> other case after rename detection.
>
> If the breakage is in merge-recursive but not in merge-resolve, my gut
> feeling is that we should not be touching unpack-trees at all. With luck
> I may be able to find some time to take a look at this myself but right
> now we are entertaining a guest, so....
-- >8 --
merge-recursive: do not clobber untracked working tree garbage
When merge-recursive wanted to create a new file in the work tree (either
as the final result, or a hint for reference purposes while delete/modify
conflicts), it unconditionally overwrote an untracked file in the working
tree. Be careful not to lose whatever the user has that is not tracked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
merge-recursive.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git c/merge-recursive.c w/merge-recursive.c
index a0c804c..2da4333 100644
--- c/merge-recursive.c
+++ w/merge-recursive.c
@@ -447,6 +447,30 @@ static void flush_buffer(int fd, const char *buf, unsigned long size)
}
}
+static int would_lose_untracked(const char *path)
+{
+ int pos = cache_name_pos(path, strlen(path));
+
+ if (pos < 0)
+ pos = -1 - pos;
+ while (pos < active_nr &&
+ !strcmp(path, active_cache[pos]->name)) {
+ /*
+ * If stage #0, it is definitely tracked.
+ * If it has stage #2 then it was tracked
+ * before this merge started. All other
+ * cases the path was not tracked.
+ */
+ switch (ce_stage(active_cache[pos])) {
+ case 0:
+ case 2:
+ return 0;
+ }
+ pos++;
+ }
+ return file_exists(path);
+}
+
static int make_room_for_path(const char *path)
{
int status;
@@ -462,6 +486,14 @@ static int make_room_for_path(const char *path)
die(msg, path, "");
}
+ /*
+ * Do not unlink a file in the work tree if we are not
+ * tracking it.
+ */
+ if (would_lose_untracked(path))
+ return error("refusing to lose untracked file at '%s'",
+ path);
+
/* Successful unlink is good.. */
if (!unlink(path))
return 0;
next prev parent reply other threads:[~2008-12-15 3:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-10 20:12 [PATCH] modify/delete conflict resolution overwrites untracked file Clemens Buchacher
2008-12-10 20:51 ` Junio C Hamano
2008-12-10 21:11 ` Clemens Buchacher
2008-12-10 23:36 ` Junio C Hamano
2008-12-11 8:07 ` Clemens Buchacher
2008-12-11 8:13 ` Junio C Hamano
2008-12-15 0:46 ` Clemens Buchacher
2008-12-15 1:03 ` Junio C Hamano
2008-12-15 3:34 ` Junio C Hamano [this message]
2008-12-15 9:34 ` Johannes Schindelin
2008-12-15 10:35 ` Junio C Hamano
2008-12-15 11:03 ` Johannes Schindelin
2008-12-15 9:59 ` Clemens Buchacher
2008-12-15 10:22 ` Junio C Hamano
2008-12-15 10:50 ` Mike Ralphson
2008-12-15 11:09 ` Johannes Schindelin
2008-12-15 11:45 ` Mike Ralphson
2008-12-15 22:13 ` Junio C Hamano
2008-12-15 23:02 ` Clemens Buchacher
2008-12-16 0:16 ` Junio C Hamano
2008-12-16 1:09 ` Jakub Narebski
2008-12-28 11:44 ` Clemens Buchacher
2008-12-28 22:21 ` Junio C Hamano
2008-12-28 23:53 ` Clemens Buchacher
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=7vmyeyyuuh.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=drizzd@aon.at \
--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 NNTP newsgroup(s).