Edward Thomson [ethom...@microsoft.com] wrote:
Junio C Hamano [mailto:gis...@pobox.com] wrote:
* Path A may have only stage #1, while path B and C has only stage
#2 and stage #3 (the user would have to notice these three
correspond to each other, and resolve manually).
You
Edward Thomson ethom...@microsoft.com writes:
Edward Thomson [ethom...@microsoft.com] wrote:
Junio C Hamano [mailto:gis...@pobox.com] wrote:
* Path A may have only stage #1, while path B and C has only stage
#2 and stage #3 (the user would have to notice these three
correspond to
Junio C Hamano [mailto:gits...@pobox.com] wrote:
Edward Thomson ethom...@microsoft.com writes:
Junio, did you have additional thoughts on this?
Not at this moment.
I think we have covered the principles (do not unnecessarily duplicate
information, do not break existing implementations
Edward Thomson ethom...@microsoft.com writes:
Junio C Hamano [mailto:gits...@pobox.com] wrote:
Edward Thomson ethom...@microsoft.com writes:
Junio, did you have additional thoughts on this?
Not at this moment.
I think we have covered the principles (do not unnecessarily duplicate
Junio C Hamano gits...@pobox.com writes:
If I were solving the issue, I would probably proceed like this:
* Start from a rough sketch of what extra information I would want
to store in the new index extension section.
* Teach read-cache.c to read from the new extension and keep it in
Junio C Hamano [mailto:gis...@pobox.com] wrote:
As long as
the format will be backward compatible to allow existing users use existing
tools
to deal with cases the existing tools can handle, then that is OK. I didn't
get that
impression which is where my non starter came from.
I see now.
Junio C Hamano [mailto:gits...@pobox.com] wrote:
Edward Thomson ethom...@microsoft.com writes:
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
Edward Thomson ethom...@microsoft.com writes:
Junio C Hamano [mailto:gits...@pobox.com] wrote:
Edward Thomson ethom...@microsoft.com writes:
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
Junio C Hamano [mailto:gits...@pobox.com] wrote:
We do not gratuitously break existing implementations. If no conflict is
stored
as higher-stage index entries in an index that has your index extension, no
existing implementation can read a conflicted index written by your
implementation and
Edward Thomson ethom...@microsoft.com writes:
Junio C Hamano [mailto:gits...@pobox.com] wrote:
We do not gratuitously break existing implementations. If no conflict is
stored
as higher-stage index entries in an index that has your index extension, no
existing implementation can read a
Junio C Hamano [mailto:gits...@pobox.com] wrote:
Edward Thomson ethom...@microsoft.com writes:
I would propose that we store the data about the file in conflict as
it occurred through the renames. For example, in a rename 1-2
conflict where A was renamed to both B and C, you would have a
Edward Thomson ethom...@microsoft.com 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
Junio C Hamano [mailto:gits...@pobox.com] wrote:
Edward Thomson ethom...@microsoft.com 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
Edward Thomson ethom...@microsoft.com writes:
I would propose that we store the data about the file in conflict as it
occurred through the renames. For example, in a rename 1-2 conflict where
A was renamed to both B and C, you would have a single conflict entry
containing the data for A, B
Junio C Hamano [mailto:gits...@pobox.com] wrote:
I do not offhand see anything particularly stupid; a new optional index
extension
section CACHE_EXT_RENAME_CONFLICT might be a good addition.
Is one side moves A to B while the other side moves it to C the only case,
or is
it just an
15 matches
Mail list logo
