Re: Merge with local conflicts in new files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Santi <sbejar@xxxxxxxxx> writes:

>       In the case of:
>
> - You merge from a branch with new files
> - You have these files in the working directory
> - You do not have these files in the HEAD.

and

 - You have not told git that these files matter.

>...
> test_expect_success 'prepare repository' \
> 'echo "Hello" > init &&
> git add init &&
> git commit -m "Initial commit" &&
> git branch B &&
> echo "foo" > foo &&
> git add foo &&
> git commit -m "File: foo" &&
> git checkout B &&
> echo "bar" > foo '

At this point, you have not told git that foo is a file that is
relevant on branch B, so git considers it a fair game to
overwrite.

At least, that was the original reasoning.

It happens not just during the ordinary "git-merge", by the way.
If you are on branch B that did not have 'foo', created 'foo'
and switched to branch A (which has 'foo') before telling the
index that you care about your version of 'foo' on branch B,
'foo' from branch A will overwrite your throwaway copy in the
working tree:

	$ git branch
	* master
        $ git branch another
	$ echo 'New file' >afile
        $ git add afile
        $ git commit -m 'Add afile'
        $ git checkout another
        $ ls afile
	ls: afile: No such file or directory
        $ echo 'Lost file' >afile
        $ git checkout master
        $ cat afile
        New file

We acquired "git apply" which does take notice when you have
such an untracked file in the working tree that conflicts with
what it does to the index, and I think its behaviour sometimes
is more user friendly and safer than what the merge does
currently (but it irritates people some other times).

This is totally untested, but on top of "next" you could do
something like this, perhaps.

We _might_ want to do this conditionally, only when the user
asks, though.  I dunno.  Being able to blow away irrelevant
files is sometimes a good thing, so we _might_ want to have a
reverse logic to "git apply" that makes it blow away untracked
working tree files under "--index" option.

-- >8 --

diff --git a/read-tree.c b/read-tree.c
index aa6172b..185a73f 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -453,8 +453,18 @@ static int merged_entry(struct cache_ent
 			invalidate_ce_path(old);
 		}
 	}
-	else
+	else {
+		/*
+		 * Originally we did not have a cache entry here but
+		 * are creating a new file as a result of the merge.
+		 * Do we want to lose the untracked working tree files?
+		 */
+		struct stat st;
+
+		if (!lstat(merge->name, &st))
+			die("Untracked working tree file '%s' would be overwritten by merge.", merge->name);
 		invalidate_ce_path(merge);
+	}
 	merge->ce_flags &= ~htons(CE_STAGEMASK);
 	add_cache_entry(merge, ADD_CACHE_OK_TO_ADD);
 	return 1;
@@ -701,7 +711,7 @@ static int bind_merge(struct cache_entry
 		return error("Cannot do a bind merge of %d trees\n",
 			     merge_size);
 	if (!a)
-		return merged_entry(old, NULL);
+		return merged_entry(old, old);
 	if (old)
 		die("Entry '%s' overlaps.  Cannot bind.", a->name);
 
@@ -736,7 +746,7 @@ static int oneway_merge(struct cache_ent
 		}
 		return keep_entry(old);
 	}
-	return merged_entry(a, NULL);
+	return merged_entry(a, old);
 }
 
 static int read_cache_unmerged(void)

-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]