[MERGE] Status should not special case conflicts
robertc at robertcollins.net
Mon Jul 17 08:20:36 BST 2006
On Fri, 2006-07-14 at 11:05 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Robert Collins wrote:
> > On Fri, 2006-07-14 at 01:49 -0400, Aaron Bentley wrote:
> > Uhm, I'm not sure that the presence of conflicts indications
> > unversionability at all.
> They can. Conflicts refer to unversioned files:
> 1. name conflicts can refer to an unverioned file that previously had
> the name. This file may be of a type that we cannot reproduce, e.g. a
> devce file, fifo, etc.
> 2. contents conflicts imply the existence of foo.THIS, and foo.OTHER
> files, and these files (particularly foo.THIS) are unversioned files
> that may have unique contents.
I buy that these two forms of conflicts imply unversionable files. For
2. though, the contents of these files is no more or less unique than
any other file - if there are two trees, their state, including content
of files, can be compared, for all files with definable content.
> >>>Eventually I plan to make conflicts be exposed as part of the tree
> >>>delta, which then lets status be purely a display of a tree delta, which
> >>>is what we need for dirstate.
> >>But conflicts aren't part of a delta. You can't compare two
> >>RevisionTrees and get conflicts as a result. Conflicts are a state of a
> >>tree, without reference to any other tree.
> > A Delta is by definition a description of the changes to tree state
> > required to transform tree A to tree B. If tree A has conflicts, and
> > tree B does not, then those conflicts are part of the changes required
> > to turn A into B - they have to be removed.
> That would imply that if you committed with conflicts, running status
> afterward would produce no output, because both the basis tree and the
> working tree have conflicts. This does not seem useful.
This depends on what we desire to achieve with conflicts. One definition
- the one this patch introduces - is that we just show the conflicts
from the 'new' tree pair. We already have options to the delta generator
to include all files, having one to include all conflicts - and have
them marked as old|new|old&new seems easy to me.
> The reason it's not useful is that we don't want to compare our conflict
> state to another tree, we want to compare it to the ideal state (i.e. no
When we compare to a RevisionTree, sure - because RevisionTree is the
ideal state. I dont buy that when we do status against a different
WorkingTree that we would want to compare conflicts, and pending merges,
against the 'ideal' state.
> If conflicts are treated as part of the delta, then our current display
> is a display of "new conflicts". This means that we need to also
> provide display of "modified conflicts" and "removed conflicts". Which
> means we also need to decide what conflict identity is: in what cases
> should we emit a "modified conflict" versus a "new/removed" pair?
See above for why I dont think we need this complexity, and how we can
easily avoid it.
> None of this display is particularly useful to users, because it's not
> what conflicts are for. And I don't think we want to go down this road.
> Yes, it's conceivable to represent conflicts as a delta, but it ignores
> the purpose of conflicts to do so.
> >>Possibly the convenience of regular interfaces outweighs the weirdness
> >>of representing conflicts in the RevisionTree interface, but I'm not at
> >>all sure. I'm pretty happy with WorkingTrees being different in kind.
> > RevisionTree already represents conflicts :).
> That can be fixed, and since you added it post 0.8, it can be fixed
> without deprecating the methods.
> > This patch just makes use
> > of it to make the status code simpler.
> Yes, but it entrenches a questionable interface, and that interface
> implies that the status code is incomplete, because it's not displaying
> removed conflicts or modified conflicts.
I think it is the cleanest way of getting all the status data we want,
with the round trips or double handling, and no special casing.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060717/337324f7/attachment.pgp
More information about the bazaar