In commit 34110cd4e394e3f92c01a4709689b384c34645d8 ("Make 'unpack_trees()'
have a separate source and destination index") I introduced a really
stupid bug in that it would always add merged entries with the CE_UPDATE
flag set. That caused us to always re-write the file, even when it was
already up-to-date in the source index.
Not only is that really stupid from a performance angle, but more
importantly it's actively wrong: if we have dirty state in the tree when
we merge, overwriting it with the result of the merge will incorrectly
overwrite that dirty state.
This trivially fixes the problem - simply don't set the CE_UPDATE flag
when the merge result matches the old state.
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
---
Ok, that was a really stupid one.
On Sun, 16 Mar 2008, Linus Torvalds wrote:
>
> Nope, I bisected it down to
>
> 34110cd4e394e3f92c01a4709689b384c34645d8 is first bad commit
>
> Make 'unpack_trees()' have a separate source and destination index
>
> and I'm trying to figure out what part of that triggered this bug.
unpack-trees.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 0cdf198..46d4f6c 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -593,6 +593,8 @@ static int verify_absent(struct cache_entry *ce, const char *action,
static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
struct unpack_trees_options *o)
{
+ int update = CE_UPDATE;
+
if (old) {
/*
* See if we can re-use the old CE directly?
@@ -603,6 +605,7 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
*/
if (same(old, merge)) {
copy_cache_entry(merge, old);
+ update = 0;
} else {
if (verify_uptodate(old, o))
return -1;
@@ -615,7 +618,7 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
invalidate_ce_path(merge, o);
}
- add_entry(o, merge, CE_UPDATE, CE_STAGEMASK);
+ add_entry(o, merge, update, CE_STAGEMASK);
return 1;
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
