[git-users] Re: git-svn setup advice for newbie
Hi Graham, It sounds like you should just have a go at it :) I would first start off with learning some Git basics. Don't go into git-svn before you know Git a good bit. Quick intro: http://www.spheredev.org/wiki/Git_for_the_lazy Reference: http://progit.org/book/ Now, when you feel you're comfortable with the Git command line, start off with cloning the subversion project on your development host: git svn clone [url-to-project-in-svn] That should give you a git repository with a branch master. To update with newer changes from svn: git svn rebase That should get you started. Where you go from there with branches and so on I think you need to experiment a bit, or tell us a bit more specifically what you want to do. Just a small warning: Running different branches of development for different OS sounds like a poor approach, imho. If I were you, I would rather keep development in a single branch, and then do some kind of deployment step that copies in the OS-specific parts into being part of a deployable artifact. If you want a more extensive tutorial on how to work with Git and Subversion in parallel, check out this pagehttp://www.tfnico.com/presentations/git-and-subversion . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git-svn setup advice for newbie
Thanks Thomas Your videos were helpful. One of the doubts I had was the warnings about the difficulty of simultaneously interacting with a subversion master repository and multiple git repositories - which there are several different approaches to, including yours. Am I right to think that as long as I cannot write back from my git clone of the svn master to the svn master itself, and only need the ability to keep fetching from the svn master, most of the complications disappear? So that I can just treat the git clone of the master as one branch among others? Graham On 01/02/11 17:09, Thomas Ferris Nicolaisen wrote: Hi Graham, It sounds like you should just have a go at it :) I would first start off with learning some Git basics. Don't go into git-svn before you know Git a good bit. Quick intro: http://www.spheredev.org/wiki/Git_for_the_lazy Reference: http://progit.org/book/ Now, when you feel you're comfortable with the Git command line, start off with cloning the subversion project on your development host: git svn clone [url-to-project-in-svn] That should give you a git repository with a branch master. To update with newer changes from svn: git svn rebase That should get you started. Where you go from there with branches and so on I think you need to experiment a bit, or tell us a bit more specifically what you want to do. Just a small warning: Running different branches of development for different OS sounds like a poor approach, imho. If I were you, I would rather keep development in a single branch, and then do some kind of deployment step that copies in the OS-specific parts into being part of a deployable artifact. If you want a more extensive tutorial on how to work with Git and Subversion in parallel, check out this page http://www.tfnico.com/presentations/git-and-subversion. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git-svn setup advice for newbie
Hi Graham, I think you're saying, that you don't need to do any git svn dcommit in your git-svn clone. This sounds like the Git repo is a pure read only mirror of the Subversion project. Such a setup is quite straight-forward and won't give any problems. However, as far as I understand, you want to do commits in the git repo, making a few differences compared to the state in subversion (so yes, like you say, it's a branch of the code in svn). In this case, the danger lies in the regular pain of branching: Over time as you do more commits on the git side, each git svn rebase will stack your git commits historically on top of the commits that come from the Subversion side. Over time, you'll get a large set of git-commits that have to be replayed on top of the subversion updates, and chances of getting conflicts will increase, making it more and more painful to keep the git repo in sync with the latest changes from subversion (this is the same problems you run into when trying to maintain two branches in parallel, I guess). So, I'm still wondering if you really want to do what you want to do :) -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git-svn setup advice for newbie
On 01/02/11 23:06, Thomas Ferris Nicolaisen wrote: Hi Graham, I think you're saying, that you don't need to do any git svn dcommit in your git-svn clone. That is correct. This sounds like the Git repo is a pure read only mirror of the Subversion project. Such a setup is quite straight-forward and won't give any problems. Good! However, as far as I understand, you want to do commits in the git repo, making a few differences compared to the state in subversion (so yes, like you say, it's a branch of the code in svn). In this case, the danger lies in the regular pain of branching: Over time as you do more commits on the git side, each git svn rebase will stack your git commits historically on top of the commits that come from the Subversion side. Over time, you'll get a large set of git-commits that have to be replayed on top of the subversion updates, and chances of getting conflicts will increase, making it more and more painful to keep the git repo in sync with the latest changes from subversion (this is the same problems you run into when trying to maintain two branches in parallel, I guess). I think your description is what I'm expecting. At the moment I'm working directly on the subversion checkout (no git involved), doing a daily svn update from the remote subversion, and resolving any conflicts with my local changes manually. Periodically if I think a set of local changes will be accepted into the remote trunk I create a set of patches for them and mail them off for vetting. If they're accepted the difference between my local checkout and the remote repository shrinks for a while. This is tedious (especially creating the patch files) but does work, and I was assuming I could carry on doing this while working with git. The new thing I need, which has pushed me towards git, is that management want me to develop two different versions of the application for evaluation, so I want to combine the above situation with managing two branches, and thought this would be easier with git. Plus I want to learn it anyway. So, I'm still wondering if you really want to do what you want to do :) Well, I hope so - does the above make more sense? Graham -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Blame file execution permissions
Hi all, in a repository with multiple collaborators we have a file that should not be executable, and someone keeps making it executable, certainly due to its editor configuration. Is there some way to blame the file for its execution permissions (and its permissions in general) ? Also, is there a way to force the file permissions (through gitattributes, or whatever) ? Regards, Julien Nicoulaud -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] git-svn setup advice for newbie
On Sun, Jan 02, 2011 at 11:39:36PM +, graham wrote: [...] Hence, the course of action for you would probably be: 1) Prepare the authors file. 2) git-svn clone the Subversion repo. 3) Fork its master branch to your two local branches. Is there a best way to do the fork? For longstanding branches I guess a cp -r would be better than a git branch? I don't think so -- Git's switching of branches is light-fast and you only should consider something like `cp -r` (but *not* exactly this, see below) only if you for some reason really want to have these two branches available in parallel as two checkouts (two directories on your hard drive available both at the same time). Note that it's possible to switch to another branch while in the middle of hacking thanks to the `git stash` command -- you `git stash` the changes in your work tree (and hence make it clean), switch to another branch, do something on it, switch back, and `git stash pop` the changes you stashed at the first step. I think if you really want to have any two branches to be checked out in parallel, it suggests you'd better have two different repositories for them. Also there's no need to use `cp -r` in any case -- if you clone a repository locally, Git tries to hardlink everything it clones. There are even methods to explicitly share certain objects. 4) Add another two remotes (the first one will be svn, created by git-svn) which you will use to do pushes to your staging and production servers. I don't follow this step - why does one of the remotes need to be svn, not pure git? Bad phrasing on my part: the first is meant to designate the remote that `git svn init/clone` will create for you -- it is named svn by default. Then you add two other remotes for your Git servers. [...] -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
