Conflicts in removed files

[Jason Earl]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Aaron Bentley writes:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  > 
>  > Stephen J. Turnbull wrote:
>  > > The problem here is that to the extent that we know what he wants,
>  > > too, bzr should just do it.  But when we don't, we should ask.
>  > 
>  > The literal interpretation of "ask" would be interactivity,
>
> Yes, it would, but I should have been more careful.  In fact I agree
> with you, maybe for different reasons.  Conflicts are too complex to
> guess what the user wants, and often too complex to formulate good
> yes/no or multiple choice questions about what he wants.
>
>  > The idea was always that *after* the merge (or other
>  > transformation) had taken place, tools could query the conflicts
>  > and let the user decide how to resolve them.  Unfortunately, no one
>  > has stepped up to write such tools.
>
> I think that is just very hard, at least once you get past the
> primitive (but useful!) level of git rerere.  I thought that Bazaar
> either was a little smarter than git about those things, or perhaps
> allowed the user to work smarter, but Stefan's example seems to show
> that it's still easy to construct realistic scenarios where rerere
> could be useful in Bazaar too.  Maybe that's the place to start.

Just out of curiosity I read the documentation for git's rerere feature,
and it seems like a lot of work for something that is actually fairly
easy to achieve in bzr.

Stefan wants to ignore some files, but the upstream hacker is interested
enough in the files that he keeps making changes to them.  We could talk
at length about what the folks using git would need to do to keep from
getting conflicts, but who cares about that?  Unlike git bzr doesn't
blindly track the state of the repository.  It keeps track of the actual
files.  This means that Stefan can create an .ignore directory, bzr mv
the files he does not want to see into this directory and go on about
his business.

Like most of git's advanced features it seems to me that rerere is
mostly about throwing away information.  Bzr already is good at hiding
information that is not immediately pertinent (without actually throwing
it away, I might add).  There is no real reason to recreate git's warts
in bzr.

Then again, I actually *like* bzr's conflict resolution management.  I
hate tools that try and drop me immediately into a merge tool, and I
hate tools that force me to either remember conflicted files or search
for conflict markers even more.  bzr conflicts gives me a nice list of
conflicted files, which I can then deal with however I need to.

Of course, it is quite likely that I have actually missed something.  In
which case I apologize for the noise.

Jason