Re: [PATCH] modify/delete conflict resolution overwrites untracked file

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

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

>> merge-recursive: do not clobber untracked working tree garbage
>> ...
>> +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);
>
> I wonder if it is cheaper to test file_exists() when the index contains a 
> lot of files...

"cheaper" than what?

The test with the index is not about efficiency, but is all about
correctness.

If the file in the work tree came from the index that represents "our"
branch, we do not want to say "yes" from this function, even when
(actually, "especially when") the path exists in the work tree.
unpack-trees decided that the path matches the index (otherwise you are
already guaranteeing that we wouldn't have come this far, right?)  and we
are about to write out the (potentially partial) merge result to the
working tree file.
--
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

[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]

  Powered by Linux