Re: git-migration: Changes to 'master'
On Mon, Jan 08, 2007 at 09:06:19PM -0500, David Nusinow wrote:
> Is this worth the overhead of maintaining the upstream branches? I'm not
> sure. Currently, our deltas from the usptream releases aren't that big for
> anything but the server, so this really may not be worthwhile. I tend to
> just look through the whole log and debian/changelog myself, so I'm not
> sure I'd even use the upstream branch for this. What does everyone else
> think? Is this just another vendor branch that we really don't need? I'm
> struggling to come up with another usage case for it, which probably means
> that the idea is flawed.
Ok... more brainstorming. The easiest method of dealing with moving changes
around in git is to pull or push them all. Cherry-picking is supported, but
it's not really the ideal model. So here's how you would create a change
destined for upstream and get it upstream using a pull/push-only method.
Say it's going to unstable and it's going to implement our Rock 'n Roll
feature.
1) Create local branches of debian-unstable and upstream-unstable. Call
them debian-rock and upstream-rock. No one will see these branches but
you in this scenario.
2) Make your changes of interest to the code in the upstream-rock branch.
Pull them in to debian-rock when you're ready to go.
3) Oops! We screwed up. You can either git-revert, git-reset, or just fix
your commit.
4) Re-checkout debian-rock, and merge upstream-rock again.
5) Build 'n test. Yay! Success! We're now ready to bring the rock.
6) Check out upstream-unstable. Pull the changes from upstream-rock.
7) Pull upstream-unstable in to debian-unstable.
8) Build, test, upload. Yay! It looks like our users are rocking out!
We're ready to let the rest of the X world experience the rock.
9) Pull upstream-unstable in to your local copy of upstream's HEAD. You'll
want to make sure it merges properly. Then push it to freedesktop.org.
10) Delete the debian-rock and upstream-rock local branches if you don't
think you'll want them any more.
This method would work around your scenario of having multiple changes in a
single set that we would need to push. The only way to really use a
pull/push-only method like this without an upstream branch is if we keep
everything in quilt. It can work once if we're shipping exactly upstream's
released version, but the moment we want to carry more than one set of
changes differing from usptream we can't do this any more. So I guess
that's another use case for having upstream* branches. If we want to make
our public branches in to things that we allow upstream to easily pull
from, or for us to push to upstream from, then this is probably the best
method.
As for pulling changes from freedesktop.org, I'm not sure that having
upstream* branches would be all that useful. We can just as easily pull or
cherry-pick straight to the debian* branches, so I don't see any win for
the extra complexity there.
Of course, the best solution is probably to just do any work destined for
upstream based off of the actual upstream HEAD, and then either let it
filter in to Debian or merge it yourself with a bit of work. We could chuck
the upstream* branches and make the debian-specific branches pull-only. I'm
leaning towards this more and more, mainly because we ended up dumping the
vendor branch in svn. I'll let this sit a bit. If anyone has any thoughts
on keeping or dumping upstream*, please speak up!
- David Nusinow
Reply to: