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.
Re: [git-users] Git Replacing Directory Delimiter (Forward Slash) With Colon
Thanks for taking the time to reply, Konstantin ;) When exploring the repository, the colons are present in the filenames. I'd guess SourceTree is the GIT client on iOS that initially created the repository. I assume removing and replacing the files perhaps from a different client will solve the issue. In the meantime, I'm currently accessing the repository using Cygwin without any issues. On Friday, June 19, 2015 at 1:58:17 PM UTC-4, Konstantin Khomoutov wrote: On Mon, 15 Jun 2015 07:05:38 -0700 (PDT) Steve Penza slp...@gmail.com javascript: wrote: When using Windows to clone a GIT repository, several files in one directory are listed with a colon in the file name instead of the directory delimiter: a forward slash. The files cannot be created in Windows and they are automatically staged to be deleted. http://content.screencast.com/users/slpenza/folders/Jing/media/47bd6422-ae7b-4b70-b9a9-4bc46c384b93/2015-06-15_0955.png Attempting to unstage the files results in the following error. Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui. http://content.screencast.com/users/slpenza/folders/Jing/media/48845a78-251a-47da-b51a-074011d786dc/2015-06-15_1002.png When viewing the repository from iOS, the files appear without colons as expected. I'm sceptical about this approach: viewing the repository from iOS might mean too much things to reason about. Have you managed to clone the repository somehow to iOS? If yes, what tool did that (AFAIK, Git does not run natively on iOS)? Hence I'd start with exploring the repository innards to really see what pathnames those files have. You do this by starting with a particular commit and exploring it with `git ls-tree` and `git cat-file` -- going through three objects until you find that one which contains the file of interest and actually records its name. -- 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] Best way to handle dev branch merging on testing server?
We're working with an old system where we have to test changes on the dev server before committing, and we code new features on local branches, but a co-worker wants to merge in local branches to the local dev branch then push to origin/dev, but I'd rather have the developers push their local branches to origin and then make a pull request for the build master to review the branch changes and then merge into dev if there's no problem. We got our model from git-flow but it says to do it either way, and we switch off build mastering, and while it might be more convenient for developers to just merge their local branches into local dev, if all of the developer's commits are pushed up to origin/dev, then the build master has to filter through by commit rather than by branch, and corrections would have to be made either with new commits or cherry-picking out the bad commits, which seems more painful than just reviewing a branch and requesting corrections. Which is better? I want to know from more experienced people (this is the first time we've build-mastered) what they think. -- 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] Proper branch merging on dev server
We're working with an old system where we have to test changes on the dev server before committing, and we code new features on local branches, but a co-worker wants to merge in local branches to the local dev branch then push to origin/dev, but I'd rather have the developers push their local branches to origin and then make a pull request for the build master to review the branch changes and then merge into dev if there's no problem. We got our model from git-flow but it says to do it either way, and we switch off build mastering (though I ultimately have seniority), and while it might be more convenient for developers to just merge their local branches into local dev, if all of the developer's commits are pushed up to origin/dev, then the build master has to filter through by commit rather than by branch, and corrections would have to be made either with new commits or cherry-picking out the bad commits, which seems more painful than just reviewing a branch and requesting corrections. Which is better? He seemed a little upset but I want to know from more experienced people (this is the first time we've build-mastered) what they think. -- 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] Remote differs from local. Wrong push?
Hi all, after a commit and push from my local branch to the remote one, I can see in the server (through the web page) that one of the committed files is broken. Differences shown in the commit are incompleted and the whole file is truncated. But if I look into my local file, everything is ok. I tried with git diff BRANCH origin/BRANCH and no errors appear. So, how can I get the differences between the remote and the local file?? And more important, how can I upload my current local file and fix the remote one? Thanks and regards -- 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] Remote differs from local. Wrong push?
On Fri, 19 Jun 2015 03:51:46 -0700 (PDT) fs...@entornosdeformacion.com wrote: after a commit and push from my local branch to the remote one, I can see in the server (through the web page) that one of the committed files is broken. Differences shown in the commit are incompleted and the whole file is truncated. But if I look into my local file, everything is ok. I tried with git diff BRANCH origin/BRANCH and no errors appear. So, how can I get the differences between the remote and the local file?? And more important, how can I upload my current local file and fix the remote one? Before rushing to fix the sutiation I'd first verify the file is truly broken. The thing is, all the stuff in Git repositories is linked using the SHA-1 hashes calculated over the contents of that stuff. In other words, commits link to their tree objects using the SHA-1 hash calculated over the contents of that tree object; tree objects refer to the blobs representing their files using, again, SHA-1 hashes calculated over the contents of those files. This means, if something is *that* broken *and* Git does not notice this, it's way more likely that the underlying filesystem (or disk drive) is hosed rather than the file is corrupted. A misbehaving web front-end is also more likely to happen that the corruption of a file in the Git database. To verify, you have several options. The simplest is to first fetch from the remote and then see at the file. Something like git fetch origin and then git show origin/BRANCH:path/to/that/file or git diff BRANCH origin/BRANCH path/to/that/file If that's OK but you'd like to dig deeper, log into the server, where the remote repository is located, `cd` to that repository's directory and look at that file: git show BRANCH:path/to/that/file If you'll notice that the file is indeed botched, return to us for further assistance. -- 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] Working Copy on remote not updating
On Tue, 16 Jun 2015 04:08:39 -0700 (PDT) Chad Baloga cbal...@gmail.com wrote: I am fairly new to GIT. Just Git or git. It's not an acronym ;-) When we do a push to the remote repo, the Working Copy on the remote does not get updated automatically. Do you mean the work tree? In other words, do you mean the copy of files which are checked out -- the same as in your local repository, where you actually change the files and then commit the changes? If yes, as they say, you're doing it wrong. Forget about your server for a moment and imagine what should actually happen when you're sitting here hacking on another feature and then somebody pushes something to your local repository -- what should happen? Do you expect all your changes should suddenly disappear -- being replaced with whatever has just been pushed? I reckon, your answer would be obviously, no! ;-) But the thing is, Git absolutely does not care whether a repository is local or on the server -- Git is able to extract history from a repository and send it to another Git instance, and it is able to receive history from another Git instance and place it into the repository -- end of the story. Everything else is just policy. To absorb this idea better, just `cd` to another directory on your local filesystem and do git init . git clone /path/to/your/local/repo . git branch joke git push origin joke ...you'll then find a branch named joke in your original repository. Is that repository remote? For our new repository we've just created in the snippet above -- definitely yes; is it remote in your eyes? -- supposedly no. The same goes for truly remote repositories: they are deemed to be remote because no one works in them directly, and they only get updated (via pushes) and queried (via fetches) from clients. That's how we arrive to this simple fact: work trees are for programmers. The only way to update the work tree is to manually tell Git you want it based on such and such commit. There's no way to make Git somehow automatically update the repository's work tree when that repository receives new history. Now there's such thing as hooks: Git is able to run programs (typically scripts) when certain event happens in the repository -- say, the new stuff has just been pushed and some branches updated. That's exactly what people who still want to use Git as a deployment tool use: set up a post-update hook to check out stuff from some dedicated branch and be done with it. The hook is also able to compensate for features lacking in Git-as-a-deployment-tool: it does not store file ownership and access bits / ACLs. The final point to consider is that for normal repos (those with the work tree, that is, non-bare) Git by default disallows pushing to the branch is which is currently checked out. This is simply to remove the WTF-factor when your index all of a sudden is out of sync with the branch it's based on (read the official GIt FAQ for more). Because of all of the above, deployment is typically done to a bare repository which has a post-update hook which uses lower-level Git commands to populate/update work tree *disjoint* from that repository. Just google for more, and see [1]. Note that you might consider not using Git for deployment at all. For instance, things like git-ftp work really OK for PHP projects. 1. https://groups.google.com/d/topic/git-users/Lvv7ByIZZ1o/discussion -- 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] Re: git-http-backend on apache for public pull and private push?
On Wed, 17 Jun 2015 14:27:48 -0700 (PDT) tobias zellner tobias.zellne...@googlemail.com wrote: [...] But now, something strange happen. I have following behavior: 1. pull work fine for everybody. 2. push work for everybody. No credentials are asked. So now I have a repository that is not protected at all. Just everybody can read and write. [...] well I found my problem. I just did not enable the rewrite engine. So the working solution looks now like below: [...] Well stupid problem, simple solution. And well it works now with and without receivepack. Thanks for the status update! Starters of the theads which did not receive any responses tend to crawl back into the hole and do not show up with comments -- possibly thinking that if no one got interested no one will be interested in the update. IMO this is flat out wrong -- in part because we're indexed by web search engines and in part because not everyone among those who did not respond were uninterested or did not understand the question; they might just were unable to help, like I was, for instance. And now we have a problem and the solution in this thread -- to save the next guy who manages to google this. ;-) -- 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] Git Replacing Directory Delimiter (Forward Slash) With Colon
On Mon, 15 Jun 2015 07:05:38 -0700 (PDT) Steve Penza slpe...@gmail.com wrote: When using Windows to clone a GIT repository, several files in one directory are listed with a colon in the file name instead of the directory delimiter: a forward slash. The files cannot be created in Windows and they are automatically staged to be deleted. http://content.screencast.com/users/slpenza/folders/Jing/media/47bd6422-ae7b-4b70-b9a9-4bc46c384b93/2015-06-15_0955.png Attempting to unstage the files results in the following error. Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui. http://content.screencast.com/users/slpenza/folders/Jing/media/48845a78-251a-47da-b51a-074011d786dc/2015-06-15_1002.png When viewing the repository from iOS, the files appear without colons as expected. I'm sceptical about this approach: viewing the repository from iOS might mean too much things to reason about. Have you managed to clone the repository somehow to iOS? If yes, what tool did that (AFAIK, Git does not run natively on iOS)? Hence I'd start with exploring the repository innards to really see what pathnames those files have. You do this by starting with a particular commit and exploring it with `git ls-tree` and `git cat-file` -- going through three objects until you find that one which contains the file of interest and actually records its name. -- 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.
