Hi Woody,
On Mon, 4 Mar 2019, Woody Woodman wrote:
>
>
Details, please.
> Sent from my iPhone
Not sent from my iPhone, as it would really be cumbersome to type an
informative, useful bug report on a phone, even the best of them.
Ciao,
Johannes
Sent from my iPhone
On Mon, Nov 27, 2017 at 3:39 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>>> As a fix, this sorely wants something new in t/ directory.
>>
>> Well, then perhaps I was wrong to submit it independent of my
>> directory rename series. As noted in the (very lengthy) extended
>> commit messag
Elijah Newren writes:
>> As a fix, this sorely wants something new in t/ directory.
>
> Well, then perhaps I was wrong to submit it independent of my
> directory rename series. As noted in the (very lengthy) extended
> commit message explanation, the assumption the previous code made just
> happ
[Removed cc's that just bounce]
On Sun, Nov 26, 2017 at 7:40 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
>> 2014-05-01), it was observed that removing files could be problematic on
>>
>> If that description leaves m
Elijah Newren writes:
> In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
> 2014-05-01), it was observed that removing files could be problematic on
> case insensitive file systems, because we could end up removing files
> that differed in case only rather than deleting the int
Elijah Newren writes:
> I had another email I had been composing to try to argue for changing
> merge-recursive.c's design to the above, assuming I could get the time
> to work on it. Nice to see that I'm not crazy, and that I apparently
> don't need to do much convincing. :-)
You might even b
On Fri, Nov 24, 2017 at 7:29 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> But what it really is forced to do is more of a 4-way merge; a good
>> chunk of its annoying complexity is based around this (undocumented
>> and unfortunate) reality. It derives from what I consider
Elijah Newren writes:
> But what it really is forced to do is more of a 4-way merge; a good
> chunk of its annoying complexity is based around this (undocumented
> and unfortunate) reality. It derives from what I consider a simple
> design flaw.
Yes, and it does not help that it
On Fri, Nov 24, 2017 at 12:04 PM, Eric Sunshine wrote:
> On Fri, Nov 24, 2017 at 2:59 PM, Elijah Newren wrote:
>> In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
>> 2014-05-01), it was observed that removing files could be problematic on
>> case insensitive file systems, beca
On Fri, Nov 24, 2017 at 2:59 PM, Elijah Newren wrote:
> In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
> 2014-05-01), it was observed that removing files could be problematic on
> case insensitive file systems, because we could end up removing files
> that differed in case on
In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
2014-05-01), it was observed that removing files could be problematic on
case insensitive file systems, because we could end up removing files
that differed in case only rather than deleting the intended file --
something that hap
12 matches
Mail list logo
