Comments on: Using Git for Local Version Control http://blog.shinetech.com/?p=95 Thoughts from Shine Technologies Tue, 07 Sep 2010 23:54:52 +0000 http://wordpress.org/?v=2.6.2 By: joez http://blog.shinetech.com/?p=95#comment-1647 joez Thu, 14 Jan 2010 07:43:57 +0000 http://blog.shinetech.com/?p=95#comment-1647 That is really what I am looking for, Thanks. The git-svn solution help a lot for the switch process from svn to git That is really what I am looking for, Thanks.
The git-svn solution help a lot for the switch process from svn to git

]]> By: My git-svn workflow | Shine Technologies Blog http://blog.shinetech.com/?p=95#comment-919 My git-svn workflow | Shine Technologies Blog Tue, 17 Mar 2009 00:50:35 +0000 http://blog.shinetech.com/?p=95#comment-919 [...] covered my motivations for using git for local version control in a previous post, so I won’t repeat them here. Nor am I going to provide a detailed tutorial on git and [...] [...] covered my motivations for using git for local version control in a previous post, so I won’t repeat them here. Nor am I going to provide a detailed tutorial on git and [...]

]]> By: Pete Moore http://blog.shinetech.com/?p=95#comment-915 Pete Moore Mon, 02 Feb 2009 02:29:27 +0000 http://blog.shinetech.com/?p=95#comment-915 Hi Ben, We are making Crucible a lot smarter wrt what to include in a review for the next major release. But right now there are two things that might make your life easier. 1. Select the commits you want included in your review oldest to newest when creating your review. Your review will then include a diff from previous to oldest revision to the newest of the changeset you selected. Note order is important, it (stupidly) doesn't work if you select commits newest to oldest. 2. You can tweak the "diff to" version one file at a time to be from the selected version. This is obviously not cool for large changes. All that said about half the crucible team use git locally. We will also have an alpha of a git plugin for crucible available very soon. Cheers, Pete. Hi Ben,

We are making Crucible a lot smarter wrt what to include in a review for the next major release. But right now there are two things that might make your life easier.

1. Select the commits you want included in your review oldest to newest when creating your review. Your review will then include a diff from previous to oldest revision to the newest of the changeset you selected. Note order is important, it (stupidly) doesn’t work if you select commits newest to oldest.

2. You can tweak the “diff to” version one file at a time to be from the selected version. This is obviously not cool for large changes.

All that said about half the crucible team use git locally. We will also have an alpha of a git plugin for crucible available very soon.

Cheers,
Pete.

]]> By: Thomas Lee » Taking the Pain Out of Complex Forms in Rails http://blog.shinetech.com/?p=95#comment-799 Thomas Lee » Taking the Pain Out of Complex Forms in Rails Sun, 20 Jul 2008 13:53:09 +0000 http://blog.shinetech.com/?p=95#comment-799 [...] other day I was discussing Rails’ form processing behavior with Ben, when the topic of editing multiple associations in a single form came up. Effectively, he needed [...] [...] other day I was discussing Rails’ form processing behavior with Ben, when the topic of editing multiple associations in a single form came up. Effectively, he needed [...]

]]> By: Screwtape http://blog.shinetech.com/?p=95#comment-778 Screwtape Fri, 20 Jun 2008 10:50:47 +0000 http://blog.shinetech.com/?p=95#comment-778 @Chad: After you checked out the trunk, did you run "git gc"? Unless you're trying to work with a Git repository on a network-mounted drive across the Internet, or less than 32MB of RAM or something similarly bizarre, Git shouldn't be that slow. Also, you might want to post your questions to the git mailing-list - they're very friendly, and are quite interested in learning about Git scalability issues like yours. @Chad:

After you checked out the trunk, did you run “git gc”? Unless you’re trying to work with a Git repository on a network-mounted drive across the Internet, or less than 32MB of RAM or something similarly bizarre, Git shouldn’t be that slow.

Also, you might want to post your questions to the git mailing-list - they’re very friendly, and are quite interested in learning about Git scalability issues like yours.

]]> By: thomasl http://blog.shinetech.com/?p=95#comment-777 thomasl Fri, 20 Jun 2008 10:43:18 +0000 http://blog.shinetech.com/?p=95#comment-777 Andrew: too right -- I think it's a big reason why many open source projects are switching over to DVCS. Funny how times change -- very rarely would anyone choose a distributed SCM two or three years ago. Dustin: reading more about this here: http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive Sounds like a nice alternative to my nasty shell script. :) Chad: I've run into similar problems trying to clone a fairly large, remote repository (the Python codebase, to be precise). Unfortunately I don't know of anything to remedy this, and the docs aren't much help. I guess this is the price we pay for relying on the git-svn bridge rather than making a full switch to git. I hope somebody reading this can help you out. Andrew: too right — I think it’s a big reason why many open source projects are switching over to DVCS. Funny how times change — very rarely would anyone choose a distributed SCM two or three years ago.

Dustin: reading more about this here:

http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive

Sounds like a nice alternative to my nasty shell script. :)

Chad: I’ve run into similar problems trying to clone a fairly large, remote repository (the Python codebase, to be precise). Unfortunately I don’t know of anything to remedy this, and the docs aren’t much help. I guess this is the price we pay for relying on the git-svn bridge rather than making a full switch to git. I hope somebody reading this can help you out.

]]> By: Chad http://blog.shinetech.com/?p=95#comment-776 Chad Fri, 20 Jun 2008 09:11:59 +0000 http://blog.shinetech.com/?p=95#comment-776 Hi Ben or anyone else, I've been using git-svn as my Subversion client for the same reasons you have, and I was wondering if you knew a way to efficiently check out an entire Subversion repository, including branches and tags. Our Subversion repository is around 30 GB, containing nearly 50k revisions. Checking out trunk with git-svn is fine*, but if I try to include all of the branches, git-svn downloads the entire history of the repository for every branch. I let this run on the actual Subversion server (a Core 2 Duo with 2 GB of RAM) for about five days before giving up. Do you know a way to have it follow branches without redownloading the shared history for each one? Thanks, Chad * Checking out trunk takes about 24 hours, and each git command thenceforth pegs the cpu for several minutes, so it clearly could be better... but it's kind of usable. Hi Ben or anyone else,

I’ve been using git-svn as my Subversion client for the same reasons you have, and I was wondering if you knew a way to efficiently check out an entire Subversion repository, including branches and tags. Our Subversion repository is around 30 GB, containing nearly 50k revisions. Checking out trunk with git-svn is fine*, but if I try to include all of the branches, git-svn downloads the entire history of the repository for every branch. I let this run on the actual Subversion server (a Core 2 Duo with 2 GB of RAM) for about five days before giving up. Do you know a way to have it follow branches without redownloading the shared history for each one?

Thanks,
Chad

* Checking out trunk takes about 24 hours, and each git command thenceforth pegs the cpu for several minutes, so it clearly could be better… but it’s kind of usable.

]]> By: Dustin http://blog.shinetech.com/?p=95#comment-775 Dustin Fri, 20 Jun 2008 07:46:11 +0000 http://blog.shinetech.com/?p=95#comment-775 You'd probably be a lot happier if you replaced that shell script with ``git rebase -i git-svn'' With this, you'll be presented with a list of your changes in your text editor and be allowed to squash multiple of them into the changesets you actually want to go upstream. You can also reorder them, edit them, etc... You’d probably be a lot happier if you replaced that shell script with “git rebase -i git-svn” With this, you’ll be presented with a list of your changes in your text editor and be allowed to squash multiple of them into the changesets you actually want to go upstream. You can also reorder them, edit them, etc…

]]> By: Andrew Binstock http://blog.shinetech.com/?p=95#comment-774 Andrew Binstock Fri, 20 Jun 2008 06:59:31 +0000 http://blog.shinetech.com/?p=95#comment-774 Good, helpful post. Thanks! Interesting to note is that SVN's structure specifically prevents you being able to use a local and remote SVN repository simultaneously, so you're basically forced to use a second SCM tool to accomplish this. I asked the SVN folks about this in person and they had no solution except something of the form you've described. Good, helpful post. Thanks!

Interesting to note is that SVN’s structure specifically prevents you being able to use a local and remote SVN repository simultaneously, so you’re basically forced to use a second SCM tool to accomplish this. I asked the SVN folks about this in person and they had no solution except something of the form you’ve described.

]]>