Conflicts in removed files

[Stefan Monnier]

> Stefan wants to ignore some files, but the upstream hacker is interested
> enough in the files that he keeps making changes to them.

I have mostly 2 use cases: one is where a few files are in a situation
like the one you describe, indeed, whereas in the other it's more like
I only care about *some* of the files of the upstream repository, so it
may very well be that half of the files or more are locally removed.

> 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?

I don't.

> 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.

Indeed, that's a possible solution.  For the first case, it would
probably be acceptable, indeed, thanks: I'll try that.
For the second, it would be somewhat helpful, but would still suffer
from several downsides:
- all those files still take up a large amount of resources (and may
  get spurious merge conflicts when merging different branches).
- when the upstream moves one of those locally "removed" files, I'll
  still get annoying conflicts.

> Then again, I actually *like* bzr's conflict resolution management.

So do I, mostly.  But for those few files it's far from optimal.


        Stefan