Junio C Hamano 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
>an in-co
Edward Thomson writes:
> Junio C Hamano [mailto:gits...@pobox.com] wrote:
>> Edward Thomson 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
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson 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 unnecessarily, et
Edward Thomson 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 each other,
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).
> >
> >
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 s
Edward Thomson 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 conflicted index w
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
Edward Thomson writes:
> Junio C Hamano [mailto:gits...@pobox.com] wrote:
>> Edward Thomson 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?
At least two
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson 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 strategy here?
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson 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 engi
Edward Thomson 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 t
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson 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
> > co
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
Edward Thomson 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 and C. This would
15 matches
Mail list logo
