From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
"Randal L. Schwartz" <merlyn@stonehenge.com>,
"Ralf Nyren" <ralf.nyren@ericsson.com>,
git@vger.kernel.org
Subject: Re: Strange effect merging empty file
Date: Thu, 22 Mar 2012 14:25:33 -0400 [thread overview]
Message-ID: <20120322182533.GA20360@sigill.intra.peff.net> (raw)
In-Reply-To: <20120322175952.GA13069@sigill.intra.peff.net>
On Thu, Mar 22, 2012 at 01:59:53PM -0400, Jeff King wrote:
> > Yeah, thanks for digging up the old thread. I was looking at the patch to
> > merge-recursive from Dscho on that thread and I think it identified the
> > place that needs patching correctly. I was on a tablet, without the access
> > to the surrounding code outside the patch context, so I do not know if the
> > logic to detect the pure-rename of an empty file in the patch was correct,
> > or the patch still applies to the current codebase, though.
>
> It's easy to apply the patch manually, and I have written a test.
> However, it seems to cause lots of other parts of t6022 to fail. I'll
> try to dig up the cause.
Found it. The diff code is very smart about doing as little work as
possible. For a raw diff (i.e., not patch), we can often get away with
not loading the blob at all, and therefore have no idea what the size
is. The inexact rename code may load it, of course, but any file which
is an exact rename will have a "0" size, also.
We can get around it by just checking for the empty-blob sha1. The patch
below should do the right thing, and passes the whole test suite.
---
diff --git a/cache.h b/cache.h
index e5e1aa4..61671b6 100644
--- a/cache.h
+++ b/cache.h
@@ -708,6 +708,8 @@ static inline void hashclr(unsigned char *hash)
#define EMPTY_TREE_SHA1_BIN \
((const unsigned char *) EMPTY_TREE_SHA1_BIN_LITERAL)
+int is_empty_blob_sha1(const unsigned char *sha1);
+
int git_mkstemp(char *path, size_t n, const char *template);
int git_mkstemps(char *path, size_t n, const char *template, int suffix_len);
diff --git a/merge-recursive.c b/merge-recursive.c
index 6479a60..ed4ff16 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -502,7 +502,7 @@ static struct string_list *get_renames(struct merge_options *o,
struct string_list_item *item;
struct rename *re;
struct diff_filepair *pair = diff_queued_diff.queue[i];
- if (pair->status != 'R') {
+ if (pair->status != 'R' || is_empty_blob_sha1(pair->one->sha1)) {
diff_free_filepair(pair);
continue;
}
diff --git a/read-cache.c b/read-cache.c
index 274e54b..dfabad0 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -157,7 +157,7 @@ static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
return 0;
}
-static int is_empty_blob_sha1(const unsigned char *sha1)
+int is_empty_blob_sha1(const unsigned char *sha1)
{
static const unsigned char empty_blob_sha1[20] = {
0xe6,0x9d,0xe2,0x9b,0xb2,0xd1,0xd6,0x43,0x4b,0x8b,
diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 9d8584e..1104249 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
@@ -884,4 +884,20 @@ test_expect_success 'no spurious "refusing to lose untracked" message' '
! grep "refusing to lose untracked file" errors.txt
'
+test_expect_success 'do not follow renames for empty files' '
+ git checkout -f -b empty-base &&
+ >empty1 &&
+ git add empty1 &&
+ git commit -m base &&
+ echo content >empty1 &&
+ git add empty1 &&
+ git commit -m fill &&
+ git checkout -b empty-topic HEAD^ &&
+ git mv empty1 empty2 &&
+ git commit -m rename &&
+ test_must_fail git merge empty-base &&
+ >expect &&
+ test_cmp expect empty2
+'
+
test_done
next prev parent reply other threads:[~2012-03-22 18:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 10:28 Strange effect merging empty file Ralf Nyren
2012-03-21 10:54 ` Zbigniew Jędrzejewski-Szmek
2012-03-21 17:14 ` Junio C Hamano
2012-03-22 12:17 ` Randal L. Schwartz
2012-03-22 12:39 ` Ralf Nyren
2012-03-22 12:47 ` Zbigniew Jędrzejewski-Szmek
2012-03-22 14:01 ` Jeff King
2012-03-22 17:03 ` Junio C Hamano
2012-03-22 17:59 ` Jeff King
2012-03-22 18:25 ` Jeff King [this message]
2012-03-22 18:52 ` Jeff King
2012-03-22 18:53 ` [PATCH 1/3] drop casts from users EMPTY_TREE_SHA1_BIN Jeff King
2012-03-22 18:53 ` [PATCH 2/3] make is_empty_blob_sha1 available everywhere Jeff King
2012-03-22 18:53 ` [PATCH 3/3] merge-recursive: don't detect renames from empty files Jeff King
2012-03-22 19:18 ` Jonathan Nieder
2012-03-22 21:53 ` Jeff King
2012-03-22 18:52 ` Strange effect merging empty file Junio C Hamano
2012-03-22 19:03 ` Jeff King
2012-03-22 19:12 ` Junio C Hamano
2012-03-22 22:46 ` [PATCH 0/2] merging renames of empty files Jeff King
2012-03-22 22:52 ` [PATCH 1/2] teach diffcore-rename to optionally ignore empty content Jeff King
2012-03-22 22:52 ` [PATCH 2/2] merge-recursive: don't detect renames of empty files Jeff King
2012-03-22 23:37 ` [PATCH 0/2] merging " Junio C Hamano
2012-03-23 0:23 ` Jeff King
2012-03-23 4:56 ` Junio C Hamano
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=20120322182533.GA20360@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=merlyn@stonehenge.com \
--cc=ralf.nyren@ericsson.com \
--cc=zbyszek@in.waw.pl \
/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).