On 8/3/2018 2:53 PM, Jeff King wrote:
On Fri, Aug 03, 2018 at 02:23:17PM -0400, Jeff Hostetler wrote:
Maybe. It might not work as ino_t. Or it might be expensive to get. Or
maybe it's simply impossible. I don't know much about Windows. Some
searching implies that NTFS does have a "file
On Fri, Aug 03, 2018 at 02:23:17PM -0400, Jeff Hostetler wrote:
> > Maybe. It might not work as ino_t. Or it might be expensive to get. Or
> > maybe it's simply impossible. I don't know much about Windows. Some
> > searching implies that NTFS does have a "file index" concept which is
> >
Jeff Hostetler writes:
> Another thing to keep in mind is that the collision could be because
> of case folding (or other such nonsense) on a directory in the path.
> I mean, if someone on Linux builds a commit containing:
>
> a/b/c/D/e/foo.txt
> a/b/c/d/e/foo.txt
>
> we'll get a similar
On 8/2/2018 5:28 PM, Jeff King wrote:
On Thu, Aug 02, 2018 at 02:14:30PM -0700, Junio C Hamano wrote:
Jeff King writes:
I also wonder if Windows could return some other file-unique identifier
that would work in place of an inode here. That would be pretty easy to
swap in via an #ifdef's
On 2018-08-02 15:43, Duy Nguyen wrote:
> On Wed, Aug 1, 2018 at 11:20 PM Junio C Hamano wrote:
>>
>> Junio C Hamano writes:
>>
>>> Jeff King writes:
>>>
> Presumably we are already in an error codepath, so if it is
> absolutely necessary, then we can issue a lstat() to grab the inum
On Thu, Aug 02, 2018 at 02:14:30PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I also wonder if Windows could return some other file-unique identifier
> > that would work in place of an inode here. That would be pretty easy to
> > swap in via an #ifdef's helper function. I'd be OK
Jeff King writes:
> I also wonder if Windows could return some other file-unique identifier
> that would work in place of an inode here. That would be pretty easy to
> swap in via an #ifdef's helper function. I'd be OK shipping without that
> and letting Windows folks fill it in later (as long
On Thu, Aug 02, 2018 at 09:27:31AM -0700, Junio C Hamano wrote:
> > OK so we're going back to the original way of checking that we check
> > out the different files on the same place (because fs is icase) and
> > try to collect all paths for reporting, yes? I can give it another go
> > (but of
Duy Nguyen writes:
>> But even if inum is unreliable, we should be able to use other
>> clues, perhaps the same set of fields we use for cached stat
>> matching optimization we use for "diff" plumbing commands, to
>> implement the error report. The more important part of the idea is
>> that we
On Wed, Aug 1, 2018 at 11:20 PM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >>> Presumably we are already in an error codepath, so if it is
> >>> absolutely necessary, then we can issue a lstat() to grab the inum
> >>> for the path we are about to create,
Junio C Hamano writes:
> Jeff King writes:
>
>>> Presumably we are already in an error codepath, so if it is
>>> absolutely necessary, then we can issue a lstat() to grab the inum
>>> for the path we are about to create, iterate over the previously
>>> checked out paths issuing lstat() and see
On Tue, Jul 31, 2018 at 8:23 PM Torsten Bögershausen wrote:
> I wonder if we can tell the users more about the "problems"
> and how to avoid them, or to live with them.
>
> This is more loud thinking:
>
> "The following paths only differ in case\n"
> "One a case-insensitive file system only one
On Tue, Jul 31, 2018 at 8:44 PM Elijah Newren wrote:
> Is it worth attempting to also warn about paths that only differ in
> UTF-normalization on relevant MacOS systems?
Down this thread, Jeff Hostetler drew a scarier picture of "case"
handling on MacOS and Windows. I think we should start with
On Tue, Jul 31, 2018 at 9:13 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > Another thing we probably should do is catch in "git checkout" too,
> > not just "git clone" since your linux/unix colleage colleague may
> > accidentally add some files that your mac/windows machine is
Jeff King writes:
>> Presumably we are already in an error codepath, so if it is
>> absolutely necessary, then we can issue a lstat() to grab the inum
>> for the path we are about to create, iterate over the previously
>> checked out paths issuing lstat() and see which one yields the same
>>
On Tue, Jul 31, 2018 at 01:12:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> > ...
> >> collapses two (or more) paths if we go that way. We only need to
> >> report "we tried to check out X but it seems your
Jeff King writes:
> On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> ...
>> collapses two (or more) paths if we go that way. We only need to
>> report "we tried to check out X but it seems your filesystem equates
>> something else that is also in the project to X".
>
> Heh. See
On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > Is it worth attempting to also warn about paths that only differ in
> > UTF-normalization on relevant MacOS systems?
>
> I hate to bring up a totally different approach this late in the
> party, but I
Elijah Newren writes:
> Is it worth attempting to also warn about paths that only differ in
> UTF-normalization on relevant MacOS systems?
I hate to bring up a totally different approach this late in the
party, but I wonder if it makes more sense to take advantage of
"clone" being a command
Nguyễn Thái Ngọc Duy writes:
> Another thing we probably should do is catch in "git checkout" too,
> not just "git clone" since your linux/unix colleage colleague may
> accidentally add some files that your mac/windows machine is not very
> happy with.
Then you would catch it not in checkout
On Mon, Jul 30, 2018 at 8:27 AM, Nguyễn Thái Ngọc Duy wrote:
> Paths that only differ in case work fine in a case-sensitive
> filesystems, but if those repos are cloned in a case-insensitive one,
> you'll get problems. The first thing to notice is "git status" will
> never be clean with no
On Mon, Jul 30, 2018 at 05:27:55PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Paths that only differ in case work fine in a case-sensitive
> filesystems, but if those repos are cloned in a case-insensitive one,
> you'll get problems. The first thing to notice is "git status" will
> never be clean with
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what's exactly is "dirty".
This patch helps the situation a bit
23 matches
Mail list logo
