Edward Thomson [off-list ref] 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.
Junio C Hamano [mailto:gitster@pobox.com] wrote:
Edward Thomson [off-list ref] writes:
quoted
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
Junio C Hamano [mailto:gitster@pobox.com] wrote:
Edward Thomson [off-list ref] writes:
quoted
I would propose that this not simply track rename conflicts, but all
conflicts.
That is a no starter.
So. Can you explain to me why this would be a non starter? Can you suggest
some alternate strategy here?
Maybe there's something I'm fundamentally misunderstanding. It seems that
at present, git will:
1. Detect rename conflicts when performing a merge (at least,
git-merge-recursive will, which is the default.)
2. If the rename itself caused a conflict (eg, renamed in one side, added in
the other) then the merge cannot succeed.
3. The resultant index is written as if renames were not detected, which
means - at best - records the files that went in to the name conflict
and git status reports an "added in ours" conflict, which is a pretty
disappointing conflict. Often, though, many of the files will not
exist at higher stage entries, since without rename detection, they
would have not been conflicts. At worst, one side is staged, there are
no conflicts in the index and the user can commit (and thus lose the
other side.)
Thus it's not like we could add some extension that merely records the names
that produced the rename conflicts and point them at the higher stage entries
in the index. That would require that they actually be in the index.
Thanks-
-ed