Re: git merge --no-ff failure

From: Nikolay Shustov <nikolay.shustov@gmail.com>
Date: Sep 28, 2025, 02:34 UTC
Message-ID: <e6ad07ab-2c0b-43eb-8c1e-b69d97458e74@gmail.com>
In-Reply-To: <CAEcERAxiuSAvpPCzsWSpoNQRmbgF0B92augTVgSqNN1jb7mJYA@mail.gmail.com>

Sigh. I added file with dot in the end to the p4 repository that on which git behaving well before, and now, with the same scenario, git fails the same way. So, I have to agree that you are right and it is, indeed, the root of problem.

BTW, Windows does have API for working with the such files. Cygwin, for example, uses it, and has no problems with filenames like that.

Thanks and Cheers,
- Nikolay

On 9/27/25 07:55, Nikolay Shustov wrote:

Show 46 quoted lines

> Thank you, I will experiment with that. But why would these files be 
> involved into merge operation? They are not the ones that changed, git 
> does not see them as something that would be merged. For all that, it 
> does not appear that git would have to be concerned with them in this 
> case?
>
> On Fri, Sep 26, 2025 at 1:41 PM Eric Sunshine 
> <sunshine@sunshineco.com> wrote:
>
>     On Fri, Sep 26, 2025 at 10:03 AM Nikolay Shustov
>     <nikolay.shustov@gmail.com> 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
>