Re: git merge --no-ff failure

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Sep 26, 2025, 17:41 UTC
Message-ID: <CAPig+cTOeCWGeNHvnBK8v2UyAV2DRs8QW7DMHGkfRHW3vSTgQA@mail.gmail.com>
In-Reply-To: <f3a051ef-328c-4778-9c78-33d52d273479@gmail.com>

On Fri, Sep 26, 2025 at 10:03 AM Nikolay Shustov <nikolay.shustov@gmail.com> wrote:

Show 14 quoted lines

> 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