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.
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.
So your tool needs code to see higher stage entries in the main
index to find <mode,sha1> for the conflicted paths even without the
index extension anyway, and if your tool does also perform merges,
you would need to strive for writing the main index with conflicted
entries and implementations that do not yet understand your
extension can keep operating. For some types of extensions, the
latter may be hard (and that is why I stopped at "you would need to
strive for", and not "you must"), but for the one under discussion,
I do not think it is the case (by the way "CONF" sounds as if it is
some sort of configuration data).
If you are starting a brand new system from scratch, keeping only
the resolved entries in the main index and having a separate section
for conflicts might be also a valid design choice, but you do not
live in that world if you are discussing the design on this mailing
list.
> I would propose that this not simply track rename conflicts, but all
> conflicts.
That is a no starter.
--
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