Re: [PATCH] merge-recursive: configurable 'merge' program

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

 



Hi!

On Tue 5 Dec 2006 Johannes Schindelin wrote:
> 
> On Tue 5 Dec 2006 Jakub Narebski wrote:
> 
>> By the way is it [ed: xdl_merge()] replacement for RCS merge i.e. is 
>> it file-level merge tool merge.onefile rather than merge.tool?

Actually by "it" I meant here the value of merge.tool configuration
variable. I think the name of configuration variable should be
merge.onefile and not merge.tool, but this are just details.
 
> It is a C function but yes it does what RCS merge does.

And more if I remember correctly.

>> What happens if there are multiple merge [contents] conflicts: is 
>> merge.tool invoked in parallel for each conflict or is it waiting for 
>> earlier merge.tool to finish (well in which case we can always do set 
>> merge.tool to "<program> &")?
> 
> Recursively. It is merge-recursive so the merges are done sequentially. 
> (Have to be since the result of one merge is reused as one input for the 
> next merge.)

Hmmm... is there a way to pass merge.tool / merge.onefile program the
info if it is invoked in final stage (here it is nice to invoke graphical
merge tool to resolve conflicts in working area before commiting merge
result) and in recursive stage (here it would be better to leave conflict
markers to be resolved later)?

>> And is merge.tool invoked for recursive part of recursive merge 
>> strategy?
> 
> Yes.

Hmmm... would it be possible to use xdl_merge() for recursion, and
graphical merge tool for result? <Checks out earlier discussion>.
I think yes, because of exposing xdl_merge() in git-merge-onefile...

>> This merge startegy depended on resolving conflict markers i.e. had 
>> built-in knowledge of 'merge'/'diff3 -E' output.
> 
> No. git-merge-recursive never resolved conflict markers but treated them 
> as text.

Hmmm... I wonder if anyone get in real life example conflict markers
to be resolved (in final file)...

>> Besides it would be useful not only to spawn interactive merge tools 
>> but also to use mergers specific for file-type for example 3DM or 
>> xmlcmp tools for merging XML files.
> 
> If you need that write a wrapper script which detects the file type and 
> execs the corresponding merge program.

That was meant as an example why one might want to use 
merge.tool / merge.onefile feature.

-- 
Jakub Narebski
Poland
-
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]