Conflict handling

[Wouter van Heyst]

On Mon, Feb 13, 2006 at 09:18:27AM -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Vincent LADEUIL wrote:
> >>>>>>"Aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:
> > On a second thought... I'm  quite surprised that bzr can't detect
> > that... He put them here in the first place no ? Conflicts should
> > be first citizens and handled as such.
> 
> Yes, this code was originally a hack in bzrtools.
> 
> So what I'm planning is:
> 1. When conflicts are encountered, .bzr/conflicts is created, and each
> kind of conflict is marked as a line in it.
> 
> 2. Running resolve will alter .bzr/conflicts, as well as deleting .THIS,
> .BASE and .OTHER files
> 
> 3. bzr conflicts will produce the same conflict output as bzr merge,
> except that it will omit conflicts that have been resolved
> 
> Does this seem more first-class-citizenish?
> 
> >     Aaron> So it detects whether there are conflicts based on the
> >     Aaron> presence of .THIS .BASE and .OTHER files
> > 
> > I understand  the need  of these files...  I understand  less why
> > they should pollute my work dir...
> 
> We produce these files for you to use.  Most conflicts are easily
> resolved, but some make absolutely no sense when you look at the output.
>  The .BASE, .OTHER, and .THIS files can be used to see which changes
> were introduced by each tree, so you can resolve them yourself.
> Alternatively, you can invoke an external tool like meld on these files
> to do the merge.

What about providing a hook for an external tool to get called
during/after merge? People who do not want any pollution ever can
resolve conflicts as they arise.

Wouter van Heyst