Hi,
On Sun, 14 Dec 2008, Junio C Hamano wrote:
> 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@xxxxxxxxx>
> ---
Thanks, I had no time at all to look into this issue.
> 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);
I wonder if it is cheaper to test file_exists() when the index contains a
lot of files...
Thanks,
Dscho
--
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
