Junio C Hamano [mailto:gitster@xxxxxxxxx] wrote: > Edward Thomson <ethomson@xxxxxxxxxxxxx> writes: > > I would propose a new extension, 'CONF', to handle conflict data, > > differing from the stage >0 entries in the index in that this > > extension tracks the conflicting file across names if the underlying > > merge engine has support for renames. > > > > I made an attempt to keep the entry data similar to other entries in > > the index. I would propose that entries in the conflict are as follows: > > > > Flags > > Four octets that describe the conflict. Data includes: > > > > 0x01 HAS_ANCESTOR > > There is a file in the common ancestor branch that contributes > > to this conflict. Its data will follow. > > 0x02 HAS_OURS > > There is a file in "our" branch that contributes to this conflict. > > Its data will follow. > > 0x04 HAS_THEIRS > > There is a file in "their" branch that contributes to this conflict. > > Its data will follow. > > > > 0x08 NAME_CONFLICT_OURS > > This item has a path in "our" branch that overlaps a different > > item in "their" branch. (Eg, this conflict represents the "our" > > side of a rename/add conflict.) > > 0x10 NAME_CONFLICT_THEIRS > > This item has a path in "their" branch that overlaps a different > > item in "our" branch. (Eg, this conflict represents the "theirs" > > side of a rename/add conflict.) > > > > 0x20 DF_CONFLICT_FILE > > This is the file involved in a directory/file conflict. > > 0x40 DF_CONFLICT_CHILD > > This is a child of a directory involved in a directory/file conflict. > > > > Other bits are reserved. > > > > Conflict Sides > > The data about one side of a conflict will contain: > > mode (ASCII string representation of octal, null-terminated) > > path (null terminated) > > sha1 (raw bytes) > > > > The conflict sides will be written in this order: > > Ancestor (if HAS_ANCESTOR is set) > > Ours (if HAS_OURS is set) > > Theirs (if HAS_THEIRS is set) > > Puzzled. Most of the above, except NAME_CONFLICT_{OURS,THEIRS} bits, look > totally pointless duplication. Obviously HAS_ANCESTOR / HAS_OURS / HAS_THEIRS is to indicate to a reader whether there is data to be read or not. Similar to how a mode of 0 in the REUC indicates that the rest of the record should not be read.) > When you are working with Git, you have to be prepared to read from the > datafile like the index that other people (and your previous > version) created, and you also have to make sure you do not make what you > write out unusable by other people without a good reason. I'm acutely aware that you need to be able to read an index that other people created - that's the problem at hand. git does not produce an index that allows anyone (including itself) to reason about rename conflicts. It doesn't even bother to write high-stage conflict entries in many instances, so you can have an instance where git tells you that a conflict occurred but one of those files is staged anyway, the other is just dirty in the workdir and you can commit immediately thereafter. While obviously it's possible to handle this situation (is file A in conflict? Look in the rename conflict extension. Not there? Okay, look in the index.) That's not exactly elegant. My goal here was to have a single source for conflicts. > (by the way "CONF" sounds as if it is some sort of configuration data). There's only four letters, and not everything's as easy as "TREE". REUC, for example, sounds like a donkey, though I suppose it depends on the language in question. -ed -- 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