From: Nikolay Shustov <nikolay.shustov@gmail•com>
To: Eric Sunshine <sunshine@sunshineco•com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx•de>, git@vger•kernel.org
Subject: Re: git merge --no-ff failure
Date: Sat, 27 Sep 2025 22:34:34 -0400 [thread overview]
Message-ID: <e6ad07ab-2c0b-43eb-8c1e-b69d97458e74@gmail.com> (raw)
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:
> 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
>
prev parent reply other threads:[~2025-09-28 2:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 13:31 git merge --no-ff failure Nikolay Shustov
2025-09-25 14:30 ` Nikolay Shustov
2025-09-26 9:55 ` Johannes Schindelin
2025-09-26 14:03 ` Nikolay Shustov
2025-09-26 17:41 ` Eric Sunshine
[not found] ` <CAEcERAxiuSAvpPCzsWSpoNQRmbgF0B92augTVgSqNN1jb7mJYA@mail.gmail.com>
2025-09-28 2:34 ` Nikolay Shustov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6ad07ab-2c0b-43eb-8c1e-b69d97458e74@gmail.com \
--to=nikolay.shustov@gmail$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox