> Lee, could you improve your change in refs.c into a real patch, with a commit
> message?
> (And please have a look at the indentation with TABs)
>
> A test case could be good, if time allows I can make a suggestion.
I will remove the refs.ignorecase flag and work on a test care or two,
it will
On 2014-03-04 14.23, Karsten Blees wrote:
> Am 03.03.2014 18:51, schrieb Junio C Hamano:
>> Lee Hopkins writes:
>>
>>> I went ahead and took a stab at a solution. My solution is more
>>> aggressive than a warning, I actually prevent the creation of
>>> ambiguous refs. My changes are also in refs.c
Am 03.03.2014 18:51, schrieb Junio C Hamano:
> Lee Hopkins writes:
>
>> I went ahead and took a stab at a solution. My solution is more
>> aggressive than a warning, I actually prevent the creation of
>> ambiguous refs. My changes are also in refs.c, which may not be
>> appropriate, but it seemed
Lee Hopkins writes:
> I went ahead and took a stab at a solution. My solution is more
> aggressive than a warning, I actually prevent the creation of
> ambiguous refs. My changes are also in refs.c, which may not be
> appropriate, but it seemed like the natural place.
>
> I have never contributed
> I don't think this distinction is necessary, either you have a
> case-insensitive file system or you don't. The case
> that the .git directory is case-sensitive and the worktree directory isn't
> (or the other way around) is
> probably so exotic that we can ignore it.
I think Torsten's use cas
Am 01.03.2014 07:54, schrieb Torsten Bögershausen:
> On 2014-03-01 03.42, Lee Hopkins wrote:
>> +
>> +if(ignore_case)
> Only looking at ignore_case here closes the door for people
> who have a branch "foo" and "Foo" at the same time.
> (Which means that they are carefully running git pack-refs)
Incorporating Torsten suggestions and some documentation:
---
Documentation/config.txt | 12
builtin/init-db.c|4 +++-
config.c |5 +
environment.c|1 +
refs.c | 26 +++---
5 files changed,
On 2014-03-01 03.42, Lee Hopkins wrote:
> I went ahead and took a stab at a solution. My solution is more
> aggressive than a warning, I actually prevent the creation of
> ambiguous refs. My changes are also in refs.c, which may not be
> appropriate, but it seemed like the natural place.
>
> I hav
I went ahead and took a stab at a solution. My solution is more
aggressive than a warning, I actually prevent the creation of
ambiguous refs. My changes are also in refs.c, which may not be
appropriate, but it seemed like the natural place.
I have never contributed to Git (in fact this is my first
Duy Nguyen writes:
> On Sat, Mar 1, 2014 at 1:58 AM, Junio C Hamano wrote:
>> Karsten Blees writes:
>>
If you are on a case-insensitive filesystem, or work on a cross-platform
project, ensure that you avoid ambiguous refs. Problem solved.
>>>
>>> So its OK to lose data if you acc
On Sat, Mar 1, 2014 at 1:58 AM, Junio C Hamano wrote:
> Karsten Blees writes:
>
>>> If you are on a case-insensitive filesystem, or work on a cross-platform
>>> project, ensure that you avoid ambiguous refs. Problem solved.
>>>
>>
>> So its OK to lose data if you accidentally use an ambiguous ref
Karsten Blees writes:
>> If you are on a case-insensitive filesystem, or work on a cross-platform
>> project, ensure that you avoid ambiguous refs. Problem solved.
>>
>
> So its OK to lose data if you accidentally use an ambiguous ref? I
> cannot believe you actually meant that.
I think he mean
On 02/28/2014 03:31 PM, Duy Nguyen wrote:
> On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty
> wrote:
>> On 02/28/2014 12:38 AM, Lee Hopkins wrote:
>>> [...] Based Michael Haggerty's response, it seems that always
>>> using loose refs would be a better workaround.
>>
>> No, I answered the questi
On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty wrote:
> On 02/28/2014 12:38 AM, Lee Hopkins wrote:
>> [...] Based Michael Haggerty's response, it seems that always
>> using loose refs would be a better workaround.
>
> No, I answered the question "what would be the disadvantages of using
> only
> If you are on a case-insensitive filesystem, or work on a cross-platform
> project, ensure that you avoid ambiguous refs. Problem solved.
I agree this is the best solution, and I personally avoid the use of
ambiguous refs. However, since there is nothing in git stopping the
use of ambiguous refs
Am 28.02.2014 07:41, schrieb Johannes Sixt:
> Am 2/28/2014 0:38, schrieb Lee Hopkins:
>>> If I understand the issue correctly, the problem is that packed-refs
>>> are always case-sensitive, even if core.ignorecase=true. OTOH,
>
> core.ignorecase is intended to affect filenames of the worktree, not
On 02/28/2014 10:11 AM, Stephen Leake wrote:
> Karsten Blees writes:
>
>> If I understand the issue correctly, the problem is that packed-refs
>> are always case-sensitive, even if core.ignorecase=true.
>
> Perhaps that could be changed? if core.ignorecase=true, packed-refs
> should be compared
On 02/28/2014 12:38 AM, Lee Hopkins wrote:
> [...] Based Michael Haggerty's response, it seems that always
> using loose refs would be a better workaround.
No, I answered the question "what would be the disadvantages of using
only packed refs?". Now I will answer the question "what would be the
d
Karsten Blees writes:
> If I understand the issue correctly, the problem is that packed-refs
> are always case-sensitive, even if core.ignorecase=true.
Perhaps that could be changed? if core.ignorecase=true, packed-refs
should be compared with case-insensitive string compares.
--
-- Stephe
--
Am 2/28/2014 0:38, schrieb Lee Hopkins:
>> If I understand the issue correctly, the problem is that packed-refs
>> are always case-sensitive, even if core.ignorecase=true. OTOH,
core.ignorecase is intended to affect filenames of the worktree, not
anything else, BTW.
>> checking / updating _unpack
> If I understand the issue correctly, the problem is that packed-refs are
> always case-sensitive, even if core.ignorecase=true.
> OTOH, checking / updating _unpacked_ refs on a case-insensitive file system
> is naturally case-insensitive.
> So wouldn't it be a better workaround to disallow pack
Am 27.02.2014 21:32, schrieb Torsten Bögershausen:
> On 2014-02-27 20.50, Junio C Hamano wrote:
>> Lee Hopkins writes:
>>
>>> Last week I ran across a potential bug with branch names on case
>>> insensitive file systems, the complete scenario can be found here:
>>>
>>> https://groups.google.com/fo
On 02/27/2014 09:37 PM, Lee Hopkins wrote:
>> Perhaps git-{branch,tag}.txt and possibly gitrepository-layout.txt
>> in Documentation/ may need a new "*Note*" section to warn against
>> this.
>
> A little more documentation never hurt anyone :).
>
>> Or we can possibly trigger this function at the
> Perhaps git-{branch,tag}.txt and possibly gitrepository-layout.txt
> in Documentation/ may need a new "*Note*" section to warn against
> this.
A little more documentation never hurt anyone :).
> Or we can possibly trigger this function at the the of
> "checkout -b" or "fetch" commands ?
> Only
On 2014-02-27 20.50, Junio C Hamano wrote:
> Lee Hopkins writes:
>
>> Last week I ran across a potential bug with branch names on case
>> insensitive file systems, the complete scenario can be found here:
>>
>> https://groups.google.com/forum/#!topic/msysgit/ugKL-sVMiqI
>>
>> The tldr is because
Lee Hopkins writes:
> Last week I ran across a potential bug with branch names on case
> insensitive file systems, the complete scenario can be found here:
>
> https://groups.google.com/forum/#!topic/msysgit/ugKL-sVMiqI
>
> The tldr is because refs are stored as plain text files except when
> pac
Hello,
Last week I ran across a potential bug with branch names on case
insensitive file systems, the complete scenario can be found here:
https://groups.google.com/forum/#!topic/msysgit/ugKL-sVMiqI
The tldr is because refs are stored as plain text files except when
packed into packed-refs, Git
27 matches
Mail list logo
