From: Eric Sunshine Date: Fri, 26 Sep 2025 17:41:05 GMT Subject: Re: git merge --no-ff failure Message-ID: In-Reply-To: On Fri, Sep 26, 2025 at 10:03 AM Nikolay Shustov wrote: > Now thinking about it, the only quirk I that I did not mention was: > Our p4 depot, unfortunately, has some files which names end with dot > (.). E.g. "/somehing/blah." > Naturally, (a known thing) git p4 on Windows created "/somehing/blah" > for it and then showed "/something/blah." removed and "/somehing/blah" > as untracked. I renamed "/somehing/blah" to "/somehing/blah." manually > to calm down its double personality :-) > (BTW, I think git on Windows could be doing a better job about such files) > > But the other git p4 repo I created from another p4 depot, where merge > --no-ff works fine, does not have such files. > This is the only thing I could think about may be a bit... unusual. > > I can try to experiment with that if you think this could be relevant. That's almost certainly the issue. Microsoft documentation[*] does state: Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. And, indeed, functions such as open(), fopen(), etc. which Git calls return an error on Windows when presented with a filename which ends in a period. [*]: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file