skillzero@xxxxxxxxx writes:
> On Mon, Aug 24, 2009 at 12:55 AM, Sanjiv
> Gupta<sanjiv.gupta@xxxxxxxxxxxxx> wrote:
>
>> 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
>
> I'm not sure if this is the best way, but you can use git fetch to get
> the latest stuff from the server without merging it then you can merge
> from origin/master (i.e. the server) into your local master, one
> commit at a time, and verify at each step:
See my other reply, but I really don't think you want to _merge_ one
commit at a time. This would not mean "test each commit" but "test the
interaction between any two commits", which few people would care
about.
The example above in SVN doesn't merge each commit, it just walks
history (assuming the history is linear, the example wouldn't be as
simple if it had to walk /branches/* too). To continue the analogy,
merging commits one by one in Git would be more or less the equivalent
in SVN of:
$ svn status
# Hmm, OK, I have stuff to commit.
$ test
# Yes, it works. But do my changes work too on top of the previous
# commits?
$ while ...; do
svn update $(($cur_rev - 1))
build
test
done
# If so, then
$ svn update
$ svn commit
That is: test the interaction between your new change with any other
changes in the repository. 'never seen anyone interested by such
thing, but why not ;-).
--
Matthieu
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html