Re: [git-users] Error when merging iscsi/nodes directory from linux to windows because of colon in filename
On Sat, 20 Jun 2015 10:07:17 +0200 Konrád Lőrinczi klorin...@gmail.com wrote: [...] 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. [...] If there would be no iscsi drive used on production server and no Windows machine used as work machine, then the whole solution would be working fine. [...] The way you check out files on your Windows box has nothing to do with the contents of the repository you check these files out from (well, you will be unable to edit those files but then again they are just device nodes and hence have no content). So I'd say using sparse checkout on Windows is a way to go in this situation. On a side note, it's interesting how device nodes ended up being tracked by etckeeper. I'm not familiar with this tool, so my question is: does it store ownership and access information of files it track? Do the same apply to major/minor numbers of device node files? -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Error when merging iscsi/nodes directory from linux to windows because of colon in filename
My use case: I want to store /etc directory content in git to: - keep backup of server settings - keep change history - easily restore previous state in case of wrong changes - edit the /etc settings locally on Windows, then push to Linux/Debian server I missed change history especially when modified Apache, mysql, cron settings, doing fine tuning of them. Also when upgrading Debian, it may do config changes, what I would like to follow or even restore. Furthermore, I have 2 servers: 1) local Vmware virtual Debian server, where I commit developments tests 2) production Debian server So I in Git i would have two remote repos, between them I can merge some changes, which have been approved to work on test server. 3) A Windows 7 work machine, where the real development, editing is done. I have one repo here, which have two remotes, local/master and live/master. Using Git Extensions for Windows git client git command line. Also using Git v2.4.0. This is the complex situation. If there would be no iscsi drive used on production server and no Windows machine used as work machine, then the whole solution would be working fine. Regards, Konrad 2015.06.19. 22:10 ezt írta (Konstantin Khomoutov flatw...@users.sourceforge.net): On Fri, 19 Jun 2015 21:08:00 +0200 Konrád Lőrinczi klorin...@gmail.com wrote: Thanks very much for your answer! It is really a deeply technical answer. Maybe are you one of developers of GIT? Thanks! No, I'm a mere enthusiast. [...] 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. I don't really understand. One only ever need to check files out if one intends to read them or modify them (typicall to record another commit). Well, if you only need to read files you don't actually have to check them out -- it's just convenient. In other words, the work tree in a regular (non-bare) repository files whose contents are *copies* of objects actually stored in the Git repository. To say it differently, the work tree is completely redundant with regard to the repository. That's why bare repos (those used for collaboration) do not have any work tree attached to them (so nothing is ever checked out of them) and yet they perfectly store all the history pushed into them. Both are partially good solutions, but not fully perfect. I'm afraid your problem is a red herring. You only need to check those file out if you intend to *edit* them and then create a new commit. While I might fathom a reason for this, it still appears that the repo produced by etckeeper is to be backed up, not modified. To do this, all you need is to just clone your etckeeper repo to a *bare* repository once and then periodically fetch new stuff there. Should I send the use case to the git developer list? I dunno. Let's figure out what's your actual use case first. -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Error when merging iscsi/nodes directory from linux to windows because of colon in filename
On Fri, 19 Jun 2015 21:08:00 +0200 Konrád Lőrinczi klorin...@gmail.com wrote: Thanks very much for your answer! It is really a deeply technical answer. Maybe are you one of developers of GIT? Thanks! No, I'm a mere enthusiast. [...] 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. I don't really understand. One only ever need to check files out if one intends to read them or modify them (typicall to record another commit). Well, if you only need to read files you don't actually have to check them out -- it's just convenient. In other words, the work tree in a regular (non-bare) repository files whose contents are *copies* of objects actually stored in the Git repository. To say it differently, the work tree is completely redundant with regard to the repository. That's why bare repos (those used for collaboration) do not have any work tree attached to them (so nothing is ever checked out of them) and yet they perfectly store all the history pushed into them. Both are partially good solutions, but not fully perfect. I'm afraid your problem is a red herring. You only need to check those file out if you intend to *edit* them and then create a new commit. While I might fathom a reason for this, it still appears that the repo produced by etckeeper is to be backed up, not modified. To do this, all you need is to just clone your etckeeper repo to a *bare* repository once and then periodically fetch new stuff there. Should I send the use case to the git developer list? I dunno. Let's figure out what's your actual use case first. -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Error when merging iscsi/nodes directory from linux to windows because of colon in filename
I added etckeeper (which uses GIT) to my Debian server, so I can have versioning over the /etc directory. But when I clone to a Windows machine I get the following error: git clone ssh://user@mysite/etc test-etckeeper Cloning into 'test-etckeeper'... remote: Counting objects: 2124, done. remote: Compressing objects: 100% (1298/1298), done. remote: Total 2124 (delta 148), reused 2121 (delta 147) Receiving objects: 100% (2124/2124), 1.08 MiB | 0 bytes/s, done. Resolving deltas: 100% (148/148), done. Checking connectivity... done. fatal: cannot create directory at 'iscsi/nodes/iqn.1.com.microsoft:iscsiproxy-target': Invalid argument warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD' I understand, that Windows doesn't handle colons on NTFS filesystem, but I thought GIT should offer some way to solve such problem. Any idea how to fix this? Maybe using clean/smudge feature? Thanks, Konrad Lorinczi -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Error when merging iscsi/nodes directory from linux to windows because of colon in filename
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 [1] 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Error when merging iscsi/nodes directory from linux to windows because of colon in filename
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? Thanks, Konrad 2015.06.19. 18:28 ezt írta (Konstantin Khomoutov flatw...@users.sourceforge.net): 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 [1] 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
