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
--
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