Re: Pulling one commit at a time.

[Sanjiv Gupta <sanjiv.gupta@microchip.com>]

Kai Blin wrote:
> 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