Understanding the "Upstream syncing" work flow

[Dan Munckton]

On Fri, 2008-06-20 at 16:25 +0100, Dan Munckton wrote:
> On Fri, 2008-06-20 at 11:15 -0400, Ben Collins wrote:
> > On Fri, 2008-06-20 at 15:19 +0100, Dan Munckton wrote:
> > > I understand how I would rebase my local working tree to the upstream
> > > kernel. But am I right in presuming that when doing this for the main
> > > tree on kernel.ubuntu.com, it cannot be done in a local repository then
> > > pushed to the main repo? Surely this has to be done directly on the
> > > server? How do you guys manage to do this atomically so as not to
> > > disrupt folks who are pulling from the main repo?
> > > 
> > 
> > No, we don't do this on the server. We do it in a local tree, and then
> > git-push -f (after making sure there are no unsycned commits in the
> > server side). Basically just good communication keeps us from
> > overwriting each other.
> > 
> 
> Ben, Tim thanks for the info. I will rehearse this for the linux-ports
> source so that when I get access to zinc I can update it to 2.6.25.7.

Ok so I have the following steps:

$ git remote add linux-2.6.25.y \
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git

$ git fetch linux-2.6.25.y

See what's new upstream
$ git log HEAD..linux-2.6.25.y/master

See which commits will be rebased
$ git log linux-2.6.25.y/master..HEAD

Now rebase
$ git rebase linux-2.6.25.y/master

See what's the damage
$ gitk --all


Now, at this point I see all the old Ubuntu-* tags
(e.g. Ubuntu-2.6.25-1.1) are now gone. Do you recreate them or is there
a smart way to keep them?


If all is cool push back (warning other consumers first of course)
$ git push -f origin

As usual any feedback greatly appreciated.

Dan