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 have
Am 03.03.2014 18:51, schrieb Junio C Hamano:
Lee Hopkins leer...@gmail.com 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
On 2014-03-04 14.23, Karsten Blees wrote:
Am 03.03.2014 18:51, schrieb Junio C Hamano:
Lee Hopkins leer...@gmail.com 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
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)
How about
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 case
Lee Hopkins leer...@gmail.com 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
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,
Karsten Blees karsten.bl...@gmail.com 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
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
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
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,
On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty mhag...@alum.mit.edu 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
On 02/28/2014 03:31 PM, Duy Nguyen wrote:
On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty mhag...@alum.mit.edu
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
Karsten Blees karsten.bl...@gmail.com 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.
On Sat, Mar 1, 2014 at 1:58 AM, Junio C Hamano gits...@pobox.com wrote:
Karsten Blees karsten.bl...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Sat, Mar 1, 2014 at 1:58 AM, Junio C Hamano gits...@pobox.com wrote:
Karsten Blees karsten.bl...@gmail.com writes:
If you are on a case-insensitive filesystem, or work on a cross-platform
project, ensure that you avoid ambiguous refs. Problem solved.
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
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 have
Lee Hopkins leer...@gmail.com 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
On 2014-02-27 20.50, Junio C Hamano wrote:
Lee Hopkins leer...@gmail.com 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
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 when
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 the of
Am 27.02.2014 21:32, schrieb Torsten Bögershausen:
On 2014-02-27 20.50, Junio C Hamano wrote:
Lee Hopkins leer...@gmail.com writes:
Last week I ran across a potential bug with branch names on case
insensitive file systems, the complete scenario can be found here:
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 packed
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 _unpacked_
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
26 matches
Mail list logo
