I'm slowly getting my head around git.
I am trying it out on a large project, which is on a server (in my office) to which I have only SSH access, or access to the files via Samba. I ran a merge (which took quite while) and now need handle the conflicts.
Looking for a decent tool to assist with the merge, I find that most are GUI based, and that suits me fine (and will help me get others in the office to buy-in to using it). However, if I access the files over the samba share and run "git status" it takes a while (10 mins?), presumably because my local git is having to deal with a lot of traffic over the network.
Is there a better way to use a local merge tool on a remote repo?
Hi,
On 8 September 2010 10:07, Mark Rogers mark@quarella.co.uk wrote:
I am trying it out on a large project, which is on a server (in my office) to which I have only SSH access, or access to the files via Samba. I ran a merge (which took quite while) and now need handle the conflicts.
Ok, first, you've got to stop thinking of Git in terms of Subversion. It's not a centralised SCM.
buy-in to using it). However, if I access the files over the samba share and run "git status" it takes a while (10 mins?), presumably because my local git is having to deal with a lot of traffic over the network.
Second - drop Samba for this - it's not needed and seems to give you overheads.
For a visual Git merge tool, I am sure there are some, but I've only ever ran P4Merge, which may be a Windows-only thing - not sure.
What you want to do is have git access over ssh, then clone your repository (initially, then pull from then on) onto your local machine. Git status should then be very fast because all the files are on your local machine.
Do your work, commit, diff, poke about, whatever. Then when you are ready, 'git push' to your server over ssh.
I think the community Git book tells you how to do the ssh+git stuff, so take a look at that first. See http://book.git-scm.com/ for more info.
http://www.kernel.org/pub/software/scm/git/docs/git-clone.html has a section on protocols supported.
Srdjan
On 08/09/10 20:16, Srdjan Todorovic wrote:
Ok, first, you've got to stop thinking of Git in terms of Subversion. It's not a centralised SCM.
Fair comment, although I've not really used version control at all until now so I don't have any baggage!
What you want to do is have git access over ssh, then clone your repository (initially, then pull from then on) onto your local machine. Git status should then be very fast because all the files are on your local machine.
The problem with this is that this is a web application, which means (as I understand it) I'd need to edit my files, commit them, SSH to the server, checkout the latest revision, refresh my browser, see if the change worked, repeat. A lot of messing around! I could run a webserver on my desktop, and database server, but now I need to keep databases synchronised as well...
I think the community Git book tells you how to do the ssh+git stuff, so take a look at that first. See http://book.git-scm.com/ for more info.
I agree that I definitely need to do more reading! However, I know my weaknesses and if I have to park this while I read up on it, I'll have to continue working on the code outside git while I do the research, and the whole exercise will fall by the wayside (I know this, because that's what's happened when I've tried to get into CVS and SVN before!) So for the time being, visual merges from my desktop over the Samba share will have to continue...
On 08 Sep 10:07, Mark Rogers wrote:
I'm slowly getting my head around git.
I am trying it out on a large project, which is on a server (in my office) to which I have only SSH access, or access to the files via Samba. I ran a merge (which took quite while) and now need handle the conflicts.
Looking for a decent tool to assist with the merge, I find that most are GUI based, and that suits me fine (and will help me get others in the office to buy-in to using it). However, if I access the files over the samba share and run "git status" it takes a while (10 mins?), presumably because my local git is having to deal with a lot of traffic over the network.
Is there a better way to use a local merge tool on a remote repo?
This sounds like you're abusing git in ways it's not supposed to be abused in.
(1) Clone the git repository (using ssh) (2) Work on your (now local) clone of the code (3) Push the code to the shared repository (4) Add a post-commit hook to the shared repository that automagically checks out the latest head and deploys it on the server
Get in to a proper git workflow.
Also, if this is "live" code that the rest of the world should see, you should be deploying it to a staging server first to test, and probably have a release branch as well as a master branch, everyone works on master (or their own private branches off that), and then commits to master, when there's a stable version, merge it in to the release branch, tag the release, and bob's your mother's brother.
Using a git repository over samba sounds like a whole world of pain, samba doesn't really do file caching, either, so you're hitting a lot of network traffic when you probably don't need to.
When you say "I ran a merge" what do you mean?
Thanks,
On 09/09/10 11:19, Brett Parker wrote:
This sounds like you're abusing git in ways it's not supposed to be abused in.
Quite probably! But see other email: to test my changes they need to be on the webserver (the machine I'm SSHing to).
Also, if this is "live" code that the rest of the world should see, you should be deploying it to a staging server first to test,
No, it's an internal dev server, from where it would go to a staging server then to a live server.
The dev server is on the same local network as my desktop.
Using a git repository over samba sounds like a whole world of pain, samba doesn't really do file caching, either, so you're hitting a lot of network traffic when you probably don't need to.
To be fair to it, it was only the git status that was slow in the end; when I ran through the diffs merging the changes that was fast enough to be perfectly usable.
When you say "I ran a merge" what do you mean?
The full process I ran through was in the "Merging changes between directories" thread[1], but the actual merge was via "git merge master".
[1] http://lists.alug.org.uk/pipermail/main/2010-September/028357.html
On 9 Sep 2010, at 11:44, Mark Rogers wrote:
Using a git repository over samba sounds like a whole world of pain, samba doesn't really do file caching, either, so you're hitting a lot of network traffic when you probably don't need to.
To be fair to it, it was only the git status that was slow in the end; when I ran through the diffs merging the changes that was fast enough to be perfectly usable.
Whilst I agree with the methods Brett and Srdjan have suggested, it's possible that running "git fsck" and/or "git gc" on the repository on your dev server might speed it up a bit.
On 09/09/10 12:00, David Reynolds wrote:
Whilst I agree with the methods Brett and Srdjan have suggested, [...]
I'm not averse to checking out a working copy from git to my desktop, I just don't see how it fits in with testing on the webserver without a lot of messing around.
[...] it's possible that running "git fsck" and/or "git gc" on the repository on your dev server might speed it up a bit
I'll look at those, thanks.
Brett Parker wrote:
(4) Add a post-commit hook to the shared repository that automagically checks out the latest head and deploys it on the server
What's the favourite all-singing all-dancing post-commit script these days? I'm still using the primitive chain of git commands, but I suspect there must be a better one out there by now.
Thanks,
-
Brett Parker -
David Reynolds -
Mark Rogers -
MJ Ray -
Srdjan Todorovic