Thanks very much for your answer!
It is really a deeply technical answer.
Maybe are you one of developers of GIT?
I'm thinking, to send this problem to GIT developer list.
As for bare repo it doesn't make possible to edit under Windows, then
checkout under Debian.
As for the git sparse checkout it is a good idea, but I'm afraid, that if I
ignore iscsi/nodes path, then this will be OK for Windows, but on Debian,
in case of a data loss & need of restore, these files will be not checked
out and restored.
Both are partially good solutions, but not fully perfect.
Should I send the use case to the git developer list?
2015.06.19. 18:28 ezt írta ("Konstantin Khomoutov" <
> On Fri, 19 Jun 2015 08:41:08 -0700 (PDT)
> Konrád Lőrinczi <klorin...@gmail.com> wrote:
> > But when I clone to a Windows machine I get the following error:
> > 'iscsi/nodes/iqn.1.com.microsoft:iscsiproxy-target': Invalid argument
> > warning: Clone succeeded, but checkout failed.
> > I understand, that Windows doesn't handle colons on NTFS filesystem,
> It does, but the colon can only appear once in a pathname, and if it
> does, it must be at position 2, and then the first character must be in
> range [a-zA-Z]. That is, the colon can only be used to delimit drive
> letters from the rest of the pathname.
> > but I thought GIT should offer some way to solve such problem.
> IIUC, no one was able to come up with a proper way to deal with an
> issue like this. Basically, the only doable thing which comes to mind
> is a special flag for the index entries which, if set, would instruct
> Git to take the on-filesystem pathname from some other place
> (supposedly a special area in the index). The next thing is to come up
> with a way to mangle such filenames (something like that code in
> NTFS which produces those "8dot3 tilde+number" filenames). And then
> all the code which works with the index on both sides of it should be
> taught to use such indirection.
> Now the problem is that such a change does nothing to the common case --
> managing a source code project -- while requiring quite high development
> cost, new index format etc. So I'm afraid this change is not going to
> be added until someone sends a patch series implementing it.
> > Any idea how to fix this?
> > Maybe using clean/smudge feature?
> No, the clean/smudge filters only deal with contents, not with names.
> There are two workarounds though both of which revolve around not
> checking out stuff.
> First, you simply can simply avoid checkout if you'll clone into a bare
> repo. If all you need is to have a backup copy on your Windows
> machine, this is the way to go.
> Second, you can employ the so-called "sparse checkouts" which allow
> to ignore directory hierarchies when checking out stuff.
> That is, you set up your repo to ignore the "iscsi/nodes" hierarchy and
> then check out. See  for an intro.
> 1. http://briancoyner.github.io/blog/2013/06/05/git-sparse-checkout/
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.