Re: Pulling one commit at a time.
- From
- Sanjiv Gupta <sanjiv.gupta@microchip.com>
- Date
- Aug 24, 2009, 07:55 UTC
- Message-ID
- <4A92476A.4060205@microchip.com>
- In-Reply-To
- <200908240946.52813.kai@samba.org>
Kai Blin wrote:
Show 56 quoted lines
> On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote: > > >>> In general the public history isn't necessarily a single straight line >>> like this picture and it doesn't make sense to merge one at a time for >>> all the commits on the public branch, but if that is what you really want >>> to do, you can do so. >>> >> Excellent description. Thanks for that. I want to merge commits one by >> one because I want to run a regression suite on each commit and >> therefore know if any one is causing failures. >> > > What I do for a case like this is using rebase. I'm not sure if I get the > explanation right enough to please all the git gurus on the list, but I'll > try. What this basically does is to back out all the commits you did on your > branch to the point you diverged from the branch you're rebasing on now. > > So assuming you had a structure like this: > > your 'master' HEAD > | > A---B---C > / > ---X---U---V---W---Y > | > public 'master' HEAD > > git would back out commits A-C, so your local branch HEAD would be at X. Then, > if forwards your branch to the branch you're rebasing on, so your local > branch HEAD is at Y now, like the public branch HEAD. > > After that, git applies all of your patches back to your local branch, > producing a tree that looks like this: > > your 'master' HEAD > | > A---B---C > / > ---X---U---V---W---Y > | > public 'master' head > > Personally I prefer that solution as it keeps the history linear. Of course > this means that all of your commits change sha1s, and you should not do this > on public branches with tags. But if you're still developing, it's much > easier to wrap your head around a history like this. It's also nice to > present feature branches to other people, as all of your commits are in one > block, without lots of annoying merge commits between them. > > rebase also handles more complicated cases of merging, but from the way I > understood your issue, this should already help. > > Cheers, > Kai >
Thanks Kai. What I would like is to "test *every* commit" available in the public master. There would be no local changes or commits that aren't pushed in the private copy. So I just want to clone one copy from the public master and then just keep pulling commits from the public master one by one and run regressions on each one.
It's a damn simple thing in SVN world. $ svn info will give you the current version you are at, assume it is "cur_rev" $ svn update -r `expr $cur_rev + 1` $ build $ test
Thanks, - Sanjiv