From: Junio C Hamano <junkio@cox•net>
To: Catalin Marinas <catalin.marinas@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Unresolved issues #3
Date: Fri, 18 Aug 2006 02:26:27 -0700 [thread overview]
Message-ID: <7vbqqics3g.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <tnx1wre4e6s.fsf@arm.com> (Catalin Marinas's message of "Fri, 18 Aug 2006 09:54:03 +0100")
Catalin Marinas <catalin.marinas@arm•com> writes:
> 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...
> # 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.
next prev parent reply other threads:[~2006-08-18 9:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-18 4:09 Unresolved issues #3 Junio C Hamano
2006-08-18 4:49 ` A Large Angry SCM
2006-08-18 14:49 ` Nicolas Pitre
2006-08-18 14:56 ` A Large Angry SCM
2006-08-18 15:30 ` Nicolas Pitre
2006-08-19 4:04 ` A Large Angry SCM
2006-08-20 23:10 ` Nicolas Pitre
2006-08-20 23:26 ` Junio C Hamano
2006-08-21 4:05 ` A Large Angry SCM
2006-08-18 5:10 ` Jeff King
2006-08-18 8:54 ` Catalin Marinas
2006-08-18 9:26 ` Junio C Hamano [this message]
2006-08-18 9:56 ` Catalin Marinas
2006-08-18 8:56 ` Jakub Narebski
2006-08-18 16:40 ` Aneesh Kumar K.V
2006-08-18 16:48 ` Jakub Narebski
2006-08-18 17:03 ` Aneesh Kumar K.V
2006-08-18 17:09 ` Jakub Narebski
2006-08-18 17:57 ` Jon Loeliger
2006-08-20 22:17 ` Junio C Hamano
2006-08-21 2:09 ` [PATCH] daemon: prepare for multiple services Junio C Hamano
2006-08-21 2:09 ` [PATCH] daemon: add upload-tar service Junio C Hamano
2006-08-23 23:19 ` Unresolved issues #3 Martin Langhoff
2006-08-25 21:22 ` Jakub Narebski
2006-10-06 6:26 ` Unresolved issues #4 Junio C Hamano
2006-10-06 10:56 ` Jakub Narebski
2006-10-06 16:11 ` Shawn Pearce
2006-10-06 16:04 ` Jon Loeliger
2006-10-06 16:12 ` Shawn Pearce
2006-10-06 16:53 ` A Large Angry SCM
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vbqqics3g.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=catalin.marinas@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox