On Tue, Mar 13, 2018 at 4:14 PM, Elijah Newren wrote:
>
> Someone in the future might hate us if they use conflictstyle=diff3,
> and have a recursive merge,
FWIW I already always use diff3 style and see the nested markers,
and I already hate it, so you are no worse off ;-)
On Tue, Mar 13, 2018 at 3:56 PM, Jonathan Nieder wrote:
> Elijah Newren wrote:
>
>> However, my question here about what to write to the working tree for
>> a rename/rename(2to1) conflict in one particular corner case still
>> remains. Should a two-way merge be performed even if it may result in
On Tue, Mar 13, 2018 at 3:52 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> However, my question here about what to write to the working tree for
>> a rename/rename(2to1) conflict in one particular corner case still
>> remains.
>
> Hmph, is it a bad idea to model this after what recursive
Hi,
Elijah Newren wrote:
> However, my question here about what to write to the working tree for
> a rename/rename(2to1) conflict in one particular corner case still
> remains. Should a two-way merge be performed even if it may result in
> nested sets of conflict markers, or is that a sufficient
Elijah Newren writes:
> However, my question here about what to write to the working tree for
> a rename/rename(2to1) conflict in one particular corner case still
> remains.
Hmph, is it a bad idea to model this after what recursive merge
strategy does? I think what is written out from that code
On Tue, Mar 13, 2018 at 3:26 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> Cool, thanks for the context. I'm happy to go down this path, but
>> there is one question I'd like your opinion on: what if the
>> intermediate content merges have conflicts themselves? If that
>> question isn'
Elijah Newren writes:
> Cool, thanks for the context. I'm happy to go down this path, but
> there is one question I'd like your opinion on: what if the
> intermediate content merges have conflicts themselves? If that
> question isn't clear, let me be more precise...
I think you answered this y
Elijah Newren writes:
> As currently implemented, yes. However, I was more concerned the idea
> of handling files differently based on whether or not they were
> similar, rather than on what the precise definition of "similar" is
> for this context.
>
> As far as the definition of similarity goe
On Mon, Mar 12, 2018 at 10:30 PM, Junio C Hamano wrote:
> While I do not think it is a bad idea to add an optional way to write the
> contents of conflicted stages out to separate files, I do not think it is a
> good idea to change what happens to add/add conflict by default.
> If anything, if
On Mon, Mar 12, 2018 at 5:38 PM, Elijah Newren wrote:
> I feel the analogy to merging binary files breaks down here in more
> than one way:
Actually, after mulling this over, I'm going to retract the "more
than" piece of this sentence. I'm trying to figure out how to retract
more, but have only
On Tue, Mar 13, 2018 at 2:59 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Tue, Mar 13 2018, Elijah Newren jotted:
>> However, I'm far more concerned with the three collision conflict types
>> having consistent behavior than I am with changing add/add conflict
>> handling. And if your two concerns or
On Tue, Mar 13 2018, Elijah Newren jotted:
> Hi,
>
> On Mon, Mar 12, 2018 at 3:19 PM, Ævar Arnfjörð Bjarmason
> wrote:
>
>>
>> Does this mean that e.g. in this case of merging two files, one
>> containing "foo" and one containing "bar":
>>
>> (
>> rm -rf /tmp/test.git &&
>> g
While I do not think it is a bad idea to add an optional way to write the
contents of conflicted stages out to separate files, I do not think it is a
good idea to change what happens to add/add conflict by default.
Two integrators picking up a same patch that adds a file separately
and allowing th
[Re-sending because this computer happened to have plain-text mode
turned off for some weird reason, and thus the email bounced]
Hi,
On Mon, Mar 12, 2018 at 3:19 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> Does this mean that e.g. in this case of merging two files, one
> containing "foo" and one cont
I'm worried that my attempt to extract add/add from the rest of the
discussion with rename/add and rename/rename resulted in a false sense
of simplification. Trying to handle all the edge and corner cases and
remain consistent sometimes gets a little hairy. Anyway...
On Mon, Mar 12, 2018 at 2:35
Hi,
Hilco Wijbenga wrote:
> On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder wrote:
>> Interesting. I would be tempted to resolve this inconsistency the
>> other way: by doing a half-hearted two-way merge (e.g. by picking one
>> of the two versions of the colliding file) and marking the path as
On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder wrote:
> Interesting. I would be tempted to resolve this inconsistency the
> other way: by doing a half-hearted two-way merge (e.g. by picking one
> of the two versions of the colliding file) and marking the path as
> conflicted in the index. That
On Mon, Mar 12 2018, Elijah Newren jotted:
> Hi everyone,
>
> I'd like to change add/add conflict resolution. Currently when such a
> conflict occurs (say at ${path}), git unconditionally does a two-way
> merge of the two files and sticks the result in the working tree at
> ${path}.
>
> I would
Hi again,
Elijah Newren wrote:
> On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder wrote:
>> Would this behavior be configurable or unconditional? I suspect I
>> would want it turned off in my own use.
>>
>> On the other hand, in the case of wild difference between the two
>> files, skipping th
Hi,
Cool, thanks for taking a look!
On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder wrote:
>
> My immediate reaction is that it seems inconsistent with the rest of
> merge behavior. Why would add/add behave this way but edit/edit not
> behave this way?
Fair enough. I have two separate reaso
Hi,
Elijah Newren wrote:
> Hi everyone,
>
> I'd like to change add/add conflict resolution. Currently when such a
> conflict occurs (say at ${path}), git unconditionally does a two-way
> merge of the two files and sticks the result in the working tree at
> ${path}.
>
> I would like to make it in
Hi everyone,
I'd like to change add/add conflict resolution. Currently when such a
conflict occurs (say at ${path}), git unconditionally does a two-way
merge of the two files and sticks the result in the working tree at
${path}.
I would like to make it instead first check whether the two files a
22 matches
Mail list logo
