Re: Unresolved issues #3

From: Junio C Hamano <junkio@cox.net>
Date: Aug 18, 2006, 09:26 UTC
Message-ID: <7vbqqics3g.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <tnx1wre4e6s.fsf@arm.com>

Catalin Marinas <catalin.marinas@arm.com> writes:

Show 17 quoted lines

> Junio C Hamano <junkio@cox.net> wrote:
>> * Martin Langhoff proposed git-xxdiff as a helper after a failed
>>   merge.
>>
>>   Message-ID: <11546492331601-git-send-email-martin@catalyst.net.nz>
>>
>>   I like the general idea of this a lot, but am having a bit of
>>   trouble envisioning how we can integrate this while making
>>   sure mergers other than xxdiff can be added easily without
>>   disrupting the end user experience.
>
> In StGIT I can configure the merge command and I currently use the
> attached script (I need to add it to the StGIT repository). It tries
> diff3 first and, if that fails, invokes emacs' merge (can use xxdiff
> as well). It also checks whether the file was modified in case I want
> to exit and solve the conflict later (maybe after getting conflict
> information for the other files).

Thanks. That is interesting. However, the workflow Martin wants to use this is a bit different from this. He wants regular diff3/merge to leave conflicted result and have "xxdiff -U" to sort out the resulting mess (I do that manually myself but without any wrapper).

Having said that...

Show 9 quoted lines

> # default merger
> if os.system('diff3 -L current -L ancestor -L patched -m -E '
>              '"%s" "%s" "%s" > "%s"'
>              % (branch1, ancestor, branch2, output)):
>     # interactive merge
>     if os.path.exists(output):
>         mtime = os.path.getmtime(output)
>     else:
>         mtime = 0

This reminds me that I should make the git barebone porcelain-ish to use diff3 directly without using merge wrapper.

I wonder why you do not error out when "if os.path.exists(output)" does not hold true; you are redirecting into it, so the possibilities are:

 - the filesystem is full;
 - your quota ran out;
 - you do not have write permission to the directory "output"
   wants to be in;
 - the user gave 'fooled you"; rm -fr . "bye' as the value of
   sys.argv[4];

etc. No matter what the reason, the fall-back interactive merge would not be able to write into output either anyway, no?

Also I wonder what would happen upon a user error where an existing file that is unwritable by the user is specified as output.