Re: git-migration: Changes to 'master'
On Tue, Jan 09, 2007 at 09:35:01AM +0100, Michel Dänzer wrote: > On Mon, 2007-01-08 at 22:08 -0500, David Nusinow wrote: > > 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. > > I think the upstream-* branches would be useful for visualizing the > relation between upstream and Debian history, e.g. using gitk, which is > something SVN couldn't provide. Ok, let's just keep them then. If we decide to stop using them, it should be just as easy as it was to stop using the vendor branches. > > 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. > > The procedure looks good to me, but I suspect the "Merge branch > 'upstream-unstable'" commit may not be that useful in the upstream repo, > so cherry-picking might be better than merging in the last step. The problem with cherry-picking is that it would be a pain to cherry-pick a ton of changes, if your branch is a bit more substantial. That was Drew's scenario, and I thought it was worth figuring out if it was possible to make that easier to deal with. For simple changes though, I think you're right and I'd probably cherry-pick as well. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
On Mon, 2007-01-08 at 22:08 -0500, David Nusinow wrote: > 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. I think the upstream-* branches would be useful for visualizing the relation between upstream and Debian history, e.g. using gitk, which is something SVN couldn't provide. > 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. The procedure looks good to me, but I suspect the "Merge branch 'upstream-unstable'" commit may not be that useful in the upstream repo, so cherry-picking might be better than merging in the last step. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
On Mon, Jan 08, 2007 at 02:32:30PM +1100, Drew Parsons wrote: > David wrote: > > The reason for using upstream branches is twofold: > > > > 1) git-buildpackage expects to have it. It's nice to actually have access > > to this tool where we couldn't use svn-buildpackage, although there's > > still a few things I'd like to iron out. > > > > 2) It lets us easily separate the code and the packaging. It seems to be > > the standard recommendation in the git world to make extensive use of > > topic branches to do your work, and then pull in changes from a trusted > > source. This essentially makes our repo set up so that we have a topic > > branch for the upstream code that we ship and a topic branch for the > > packaging. This should avoid problems with merging in the future. > > > > 3) Because we can't figure out a way to set things up so that when you > > clone the alioth repo, you get a branch cloned from freedesktop also, > > this ensures that people at least get some standard upstream branch > > that we can use. > > > > The upstream branches aren't strictly necessary. We could potentially patch > > git-buildpackage to work without an upstream branch if we want. But after > > working with git's pull everything by default model for a little while, and > > seeing how you're supposed to use the cheap branching to avoid problems, I > > feel like we should hedge our bets and separate the code work from the > > packaging. > > I understand then that the idea behind the upstream branches is not for > pushing patches upstream as such, but rather is a kind of technical > convenience. For instance we could use them to generate orig tarballs if > the ones provided upstream were not available for some reason. Right, exactly. That's actually what git-buildpackage does right now. I think it may have a bug where it doesn't properly use the .orig.tar.gz if it's present though. I need to check this... > The Debian subdirectory will only appear in the Debian branch, of > course. Am I correct in understanding that no code patching at all is > to be done in the Debian branch? Code changes are made to the upstream > branch which is then merged across to the Debian branch? I can imagine > a practical problem with this: for me the most convenient way of > testing my code changes is to generate a test package which I install. > But if the code changes are in one branch while the packaging is in > another, this becomes less straightforward. I can think of a couple of > ways of handling it, for instance copying the Debian directory across > manually without committing it to the upstream branch, but what did you > have in mind here? Right, I don't think it's realistic that we'll be applying code to the upstream branch first for the reasons you mention. I think what's most realistic is that we'll do it in a local branch of the debian branch. Then there's two ways of doing it, either way is fine by me (and I wrote the proposed policy that way). 1. cherry-pick the change(s) to the upstream branch, then pull from the upstream branch to the debian branch. 2. pull the changes from your local branch to the debian branch, and then cherry pick the change in to the upstream branch. There's not a huge difference between these two methods really. Unfortunately, I don't think git allows you to "cherry-push" patches, so it has to be pulled in to the upstream branch. We also can't just pull or push all the changes from the local debian branch to upstream branch because then it'll take the packaging with it. > What procedure do we propose for pushing a patch upstream? Would we > individually pull "master" down from f.d.o and transfer the appropriate > commits from our upstream-unstable branch, say, into this master > branch? I think we probably want to deploy a patch in Debian first before pushing it upstream. So do the above, upload, 'n test. Then once we're happy with it, you'll probably want to cherry-pick or pull the change to your local copy of the upstream HEAD. If you cherry-pick, you can do it from either the upstream or debian branch. If you push, you'll need to do it from the upstream branch, although I'm not sure how well this will work if upstream HEAD is wildly diverged from our upstream branch. > I also understand that part of the idea in using git is that git will > contain our own patches applied (in the upstream branch) over the > original upstream source. This will make debian/patches somewhat more > empty, with quilt being somewhat superseded by git's revision history. > But if this is correct, then we lose one of the advantages of holding > explicitly separate patches, that is in order to push a patch we > developed to fix a specific bug, we'd have to trawl through the entire > git history entry by entry to collect any relevant commits, which is > more troublesome than having one patch containing all the required > changes collected in one file. What will t
Re: git-migration: Changes to 'master'
David wrote: > On Sun, Jan 07, 2007 at 08:38:08PM +1100, Drew Parsons wrote: > > > > Yeah, Michel is probably right, it seems I don't really understand what the > > intention with the upstream branches is. I had thought the idea was to > > facilitate pushing patches back to upstream, but if they are a merged > > amalgum of multiple upstream sources then this wouldn't work so well. > > > > The wiki doesn't seem to explain the meaning of the upstream branches. > > Could you explain the motivation for them again? > > Sure, sorry about that. Let me try again. I'll clean up the wiki tonight > also. > > The reason for using upstream branches is twofold: > > 1) git-buildpackage expects to have it. It's nice to actually have access > to this tool where we couldn't use svn-buildpackage, although there's > still a few things I'd like to iron out. > > 2) It lets us easily separate the code and the packaging. It seems to be > the standard recommendation in the git world to make extensive use of > topic branches to do your work, and then pull in changes from a trusted > source. This essentially makes our repo set up so that we have a topic > branch for the upstream code that we ship and a topic branch for the > packaging. This should avoid problems with merging in the future. > > 3) Because we can't figure out a way to set things up so that when you > clone the alioth repo, you get a branch cloned from freedesktop also, > this ensures that people at least get some standard upstream branch > that we can use. > > The upstream branches aren't strictly necessary. We could potentially patch > git-buildpackage to work without an upstream branch if we want. But after > working with git's pull everything by default model for a little while, and > seeing how you're supposed to use the cheap branching to avoid problems, I > feel like we should hedge our bets and separate the code work from the > packaging. I understand then that the idea behind the upstream branches is not for pushing patches upstream as such, but rather is a kind of technical convenience. For instance we could use them to generate orig tarballs if the ones provided upstream were not available for some reason. The Debian subdirectory will only appear in the Debian branch, of course. Am I correct in understanding that no code patching at all is to be done in the Debian branch? Code changes are made to the upstream branch which is then merged across to the Debian branch? I can imagine a practical problem with this: for me the most convenient way of testing my code changes is to generate a test package which I install. But if the code changes are in one branch while the packaging is in another, this becomes less straightforward. I can think of a couple of ways of handling it, for instance copying the Debian directory across manually without committing it to the upstream branch, but what did you have in mind here? What procedure do we propose for pushing a patch upstream? Would we individually pull "master" down from f.d.o and transfer the appropriate commits from our upstream-unstable branch, say, into this master branch? I also understand that part of the idea in using git is that git will contain our own patches applied (in the upstream branch) over the original upstream source. This will make debian/patches somewhat more empty, with quilt being somewhat superseded by git's revision history. But if this is correct, then we lose one of the advantages of holding explicitly separate patches, that is in order to push a patch we developed to fix a specific bug, we'd have to trawl through the entire git history entry by entry to collect any relevant commits, which is more troublesome than having one patch containing all the required changes collected in one file. What will the role of quilt be under git? I have a feeling I'm still missing something. Sorry! Hopefully it won't take too many more iterations of this discussion to be sure we've got it all straight! Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
On Sun, Jan 07, 2007 at 08:38:08PM +1100, Drew Parsons wrote: > Michel wrote: > > On Wed, 2007-01-03 at 23:02 -0500, David Nusinow wrote: > > > > > > On Thu, Jan 04, 2007 at 02:25:05PM +1100, Drew Parsons wrote: > > > > > > > > > > Why did you use 'upstream-master'? I probably was unclear in what I > > > > > wrote > > > > > down, looking back on the draft. What I had in mind was > > > > > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain > > > > > that > > > > > this is the best way to divide up the branches though. Do you think > > > > > having > > > > > 'upstream-master' is a better way of handling things? > > > > > > > > The way I understood it, we wanted our copies of the upstream branches > > > > to keep their own upstream names verbatim but with an "upstream-" > > > > prefixed to avert name clashes. Otherwise it would get really > > > > confusing figuring out which of our "upstream-" branches corresponds to > > > > which actual branch upstream. > > > > > > I'm not really sure if that would work out. Aside from master, there's no > > > really long-lived branches from upstream, so if we were to use any of the > > > other branches from upstream, we'd have to re-create it every time we > > > wanted to use a different short lived topic branch with a new name. > > > > > > Even harder would be if we wanted to pull from multiple topic branches > > > (which is something I'm thinking about doing for the server). The thought > > > of having upstream-pci-rework-randr1.2-for-server-1.2 sounds really > > > horrendous to me :-) > > > > > > I had envisioned that if you want to know which upstream version we pulled > > > from, you can just checkout the appropriate upstream branch and run git > > > log. > > > > I guess there's some confusion about what the upstream-* branches are > > supposed to be. I (and apparently Drew) thought they were supposed to be > > 1:1 copies of the corresponding upstream branches (directly from the > > upstream repos with git-fetch). But your description sounds like you > > envision merging from upstream into the upstream-* branches instead. I > > actually like that idea after thinking about it a bit. E.g. one problem > > with the 1:1 copies would be that git-fetch would no longer work after > > cherry-picking fixes onto our copies. > > Yeah, Michel is probably right, it seems I don't really understand what the > intention with the upstream branches is. I had thought the idea was to > facilitate pushing patches back to upstream, but if they are a merged > amalgum of multiple upstream sources then this wouldn't work so well. > > The wiki doesn't seem to explain the meaning of the upstream branches. > Could you explain the motivation for them again? Sure, sorry about that. Let me try again. I'll clean up the wiki tonight also. The reason for using upstream branches is twofold: 1) git-buildpackage expects to have it. It's nice to actually have access to this tool where we couldn't use svn-buildpackage, although there's still a few things I'd like to iron out. 2) It lets us easily separate the code and the packaging. It seems to be the standard recommendation in the git world to make extensive use of topic branches to do your work, and then pull in changes from a trusted source. This essentially makes our repo set up so that we have a topic branch for the upstream code that we ship and a topic branch for the packaging. This should avoid problems with merging in the future. 3) Because we can't figure out a way to set things up so that when you clone the alioth repo, you get a branch cloned from freedesktop also, this ensures that people at least get some standard upstream branch that we can use. The upstream branches aren't strictly necessary. We could potentially patch git-buildpackage to work without an upstream branch if we want. But after working with git's pull everything by default model for a little while, and seeing how you're supposed to use the cheap branching to avoid problems, I feel like we should hedge our bets and separate the code work from the packaging. I hope that's a little clearer. If I'm off my rocker (I'm definitely no git expert) then let's figure out why and fix this before we make the move. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
On Thu, Jan 04, 2007 at 09:38:35AM +0100, Michel Dänzer wrote: > On Wed, 2007-01-03 at 23:02 -0500, David Nusinow wrote: > > > > On Thu, Jan 04, 2007 at 02:25:05PM +1100, Drew Parsons wrote: > > > David asked: > > > > > URL: ssh://git.debian.org/git/pkg-xorg/$debian.git > > > > > -Pull: refs/heads/master:refs/heads/master-origin > > > > > +Push: refs/heads/master:refs/heads/debian-unstable > > > > > +Push: refs/heads/upstream-master:refs/heads/upstream-master > > > > > > > > Why did you use 'upstream-master'? I probably was unclear in what I > > > > wrote > > > > down, looking back on the draft. What I had in mind was > > > > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that > > > > this is the best way to divide up the branches though. Do you think > > > > having > > > > 'upstream-master' is a better way of handling things? > > > > > > The way I understood it, we wanted our copies of the upstream branches > > > to keep their own upstream names verbatim but with an "upstream-" > > > prefixed to avert name clashes. Otherwise it would get really > > > confusing figuring out which of our "upstream-" branches corresponds to > > > which actual branch upstream. > > > > I'm not really sure if that would work out. Aside from master, there's no > > really long-lived branches from upstream, so if we were to use any of the > > other branches from upstream, we'd have to re-create it every time we > > wanted to use a different short lived topic branch with a new name. > > > > Even harder would be if we wanted to pull from multiple topic branches > > (which is something I'm thinking about doing for the server). The thought > > of having upstream-pci-rework-randr1.2-for-server-1.2 sounds really > > horrendous to me :-) > > > > I had envisioned that if you want to know which upstream version we pulled > > from, you can just checkout the appropriate upstream branch and run git > > log. > > I guess there's some confusion about what the upstream-* branches are > supposed to be. I (and apparently Drew) thought they were supposed to be > 1:1 copies of the corresponding upstream branches (directly from the > upstream repos with git-fetch). But your description sounds like you > envision merging from upstream into the upstream-* branches instead. I > actually like that idea after thinking about it a bit. E.g. one problem > with the 1:1 copies would be that git-fetch would no longer work after > cherry-picking fixes onto our copies. Right, sorry about that. I'll explain the upstream* branches in reply to Drew's mail below a little better. > > The idea behind having a simple 1:1 mapping between our debian branch and > > the upstream branch at least makes it simple on our end to see what > > upstream version maps to what debian distro. You can check out the > > upstream-unstable, check the log, and know that that's what's in unstable. > > You don't even need to check out a branch to see its log. :) Oooh... cool! > > > On a different note, if we're forgoing a "master" branch in favour of > > > debian-unstable, then when I run git clone, which branch will present > > > by default, will it be debian-unstable? > > > > That's the idea. I'm setting up the beryl repositories right now according > > to this system, and I'm setting HEAD to be debian-unstable by default. I'm > > currently using upstream-unstable to import the upstream source, but if we > > decide to use upstream-master (or whatever else) it'll pretty trivial to > > create the new branch and delete the old one. > > AFAICS the beryl repositories don't have merge commits from upstream > repos though, so one still has to figure out which upstream branch(es) > the upstream bits came from, and there's no upstream history. Is that > intended? If so, IMO that would diminish the value of the upstream-* > branches considerably. Right, in this case the upstream-* branches are just tarball imports. We can probably use git-svn though if we want. In that case, Shawn would have a local branch that he could name whatever he wanted (Thierry and I seem to be talking about using upstream-master as a common name though) that he could fetch the upstream sources from using git-svn. He'd then pull the tagged release in to upstream-unstable, and push that to alioth. He'd merge from upstream-unstable in to debian-unstable, and the package would be built from there. If he doesn't use git-svn and we stick with just copying in tarballs then you're right, it's not nearly as useful, but at least the repo would be organized like all the others. The most important part though is the ability to use git-buildpackage, which expects an upstream branch. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
Michel wrote: > On Wed, 2007-01-03 at 23:02 -0500, David Nusinow wrote: > > > > On Thu, Jan 04, 2007 at 02:25:05PM +1100, Drew Parsons wrote: > > > > > > > > Why did you use 'upstream-master'? I probably was unclear in what I > > > > wrote > > > > down, looking back on the draft. What I had in mind was > > > > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that > > > > this is the best way to divide up the branches though. Do you think > > > > having > > > > 'upstream-master' is a better way of handling things? > > > > > > The way I understood it, we wanted our copies of the upstream branches > > > to keep their own upstream names verbatim but with an "upstream-" > > > prefixed to avert name clashes. Otherwise it would get really > > > confusing figuring out which of our "upstream-" branches corresponds to > > > which actual branch upstream. > > > > I'm not really sure if that would work out. Aside from master, there's no > > really long-lived branches from upstream, so if we were to use any of the > > other branches from upstream, we'd have to re-create it every time we > > wanted to use a different short lived topic branch with a new name. > > > > Even harder would be if we wanted to pull from multiple topic branches > > (which is something I'm thinking about doing for the server). The thought > > of having upstream-pci-rework-randr1.2-for-server-1.2 sounds really > > horrendous to me :-) > > > > I had envisioned that if you want to know which upstream version we pulled > > from, you can just checkout the appropriate upstream branch and run git > > log. > > I guess there's some confusion about what the upstream-* branches are > supposed to be. I (and apparently Drew) thought they were supposed to be > 1:1 copies of the corresponding upstream branches (directly from the > upstream repos with git-fetch). But your description sounds like you > envision merging from upstream into the upstream-* branches instead. I > actually like that idea after thinking about it a bit. E.g. one problem > with the 1:1 copies would be that git-fetch would no longer work after > cherry-picking fixes onto our copies. Yeah, Michel is probably right, it seems I don't really understand what the intention with the upstream branches is. I had thought the idea was to facilitate pushing patches back to upstream, but if they are a merged amalgum of multiple upstream sources then this wouldn't work so well. The wiki doesn't seem to explain the meaning of the upstream branches. Could you explain the motivation for them again? Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
* Michel Dänzer wrote: > On Wed, 2007-01-03 at 23:02 -0500, David Nusinow wrote: [...] > AFAICS the beryl repositories don't have merge commits from upstream > repos though, so one still has to figure out which upstream branch(es) > the upstream bits came from, and there's no upstream history. Is that > intended? If so, IMO that would diminish the value of the upstream-* > branches considerably. That would be due to the fact that the beryl project currently doesn't use git but SVN. AIUI those repositories were created from upstream tarballs. Thierry signature.asc Description: Digital signature
Re: git-migration: Changes to 'master'
On Wed, 2007-01-03 at 23:02 -0500, David Nusinow wrote: > > On Thu, Jan 04, 2007 at 02:25:05PM +1100, Drew Parsons wrote: > > David asked: > > > > URL: ssh://git.debian.org/git/pkg-xorg/$debian.git > > > > -Pull: refs/heads/master:refs/heads/master-origin > > > > +Push: refs/heads/master:refs/heads/debian-unstable > > > > +Push: refs/heads/upstream-master:refs/heads/upstream-master > > > > > > Why did you use 'upstream-master'? I probably was unclear in what I wrote > > > down, looking back on the draft. What I had in mind was > > > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that > > > this is the best way to divide up the branches though. Do you think having > > > 'upstream-master' is a better way of handling things? > > > > The way I understood it, we wanted our copies of the upstream branches > > to keep their own upstream names verbatim but with an "upstream-" > > prefixed to avert name clashes. Otherwise it would get really > > confusing figuring out which of our "upstream-" branches corresponds to > > which actual branch upstream. > > I'm not really sure if that would work out. Aside from master, there's no > really long-lived branches from upstream, so if we were to use any of the > other branches from upstream, we'd have to re-create it every time we > wanted to use a different short lived topic branch with a new name. > > Even harder would be if we wanted to pull from multiple topic branches > (which is something I'm thinking about doing for the server). The thought > of having upstream-pci-rework-randr1.2-for-server-1.2 sounds really > horrendous to me :-) > > I had envisioned that if you want to know which upstream version we pulled > from, you can just checkout the appropriate upstream branch and run git > log. I guess there's some confusion about what the upstream-* branches are supposed to be. I (and apparently Drew) thought they were supposed to be 1:1 copies of the corresponding upstream branches (directly from the upstream repos with git-fetch). But your description sounds like you envision merging from upstream into the upstream-* branches instead. I actually like that idea after thinking about it a bit. E.g. one problem with the 1:1 copies would be that git-fetch would no longer work after cherry-picking fixes onto our copies. > The idea behind having a simple 1:1 mapping between our debian branch and > the upstream branch at least makes it simple on our end to see what > upstream version maps to what debian distro. You can check out the > upstream-unstable, check the log, and know that that's what's in unstable. You don't even need to check out a branch to see its log. :) > > On a different note, if we're forgoing a "master" branch in favour of > > debian-unstable, then when I run git clone, which branch will present > > by default, will it be debian-unstable? > > That's the idea. I'm setting up the beryl repositories right now according > to this system, and I'm setting HEAD to be debian-unstable by default. I'm > currently using upstream-unstable to import the upstream source, but if we > decide to use upstream-master (or whatever else) it'll pretty trivial to > create the new branch and delete the old one. AFAICS the beryl repositories don't have merge commits from upstream repos though, so one still has to figure out which upstream branch(es) the upstream bits came from, and there's no upstream history. Is that intended? If so, IMO that would diminish the value of the upstream-* branches considerably. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Re: git-migration: Changes to 'master'
* David Nusinow wrote: [...] > On Wed, Jan 03, 2007 at 05:53:29PM +0100, Thierry Reding wrote: > > clone | 26 ++ > > 1 files changed, 22 insertions(+), 4 deletions(-) > > > > New commits: > > commit 0726222645eb8e6e4f25056e8f7244b4566825e3 > > Author: Thierry Reding <[EMAIL PROTECTED]> > > Date: Wed Jan 3 17:50:06 2007 +0100 > > > > Implement the proposed XSF git archive policy. > > [...] > Why did you use 'upstream-master'? I probably was unclear in what I wrote > down, looking back on the draft. What I had in mind was > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that > this is the best way to divide up the branches though. Do you think having > 'upstream-master' is a better way of handling things? > > - David Nusinow We've already discussed this on IRC, but here goes for everyone to read: since it's pretty difficult to figure out which tags to create the upstream-* branches off for each package, I thought to just put upstream-master into the repositories so that there would be some reference from which the other branches could be split off. After discussing this with David on IRC, I believe it would be better to rename upstream-master to upstream-unstable. Since we're pretty much at the beginning of a new release cycle, it would be the logical choice to have unstable track upstream's master. Once upstream tags releases, upstream-unstable could be updated to those tags to comply with the policy. This would leave it up to people working on the packages to create the upstream-etch (based off the corresponding upstream tag) and debian-etch branches for etch support. The same goes for experimental packages or for lenny once we get to its freeze. For some packages upstream's master might not be the optimal choice (take the X server for instance), but it should be possible to roll back upstream- and debian-unstable to some other tag or branch manually later on. We've settled on this primarily so most of the cloning, naming and possibly pushing can be scripted. It would still be good to have upstream's master branch when working on a package (for cherry-picking), so we've been thinking about ways to make it as easy as possible to pull it in while keeping it out of the Alioth repositories. Since git doesn't support anything similar to svn:externals and hooks don't seem to be able to do this when a repo is cloned, the only alternative would seem to be a script that needs to be run manually on each repository that clones upstream's master branch into the local repository. Does this sound about right to everyone? Thierry signature.asc Description: Digital signature
Re: git-migration: Changes to 'master'
Hi Drew, On Thu, Jan 04, 2007 at 02:25:05PM +1100, Drew Parsons wrote: > David asked: > > > URL: ssh://git.debian.org/git/pkg-xorg/$debian.git > > > -Pull: refs/heads/master:refs/heads/master-origin > > > +Push: refs/heads/master:refs/heads/debian-unstable > > > +Push: refs/heads/upstream-master:refs/heads/upstream-master > > > > Why did you use 'upstream-master'? I probably was unclear in what I wrote > > down, looking back on the draft. What I had in mind was > > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that > > this is the best way to divide up the branches though. Do you think having > > 'upstream-master' is a better way of handling things? > > The way I understood it, we wanted our copies of the upstream branches > to keep their own upstream names verbatim but with an "upstream-" > prefixed to avert name clashes. Otherwise it would get really > confusing figuring out which of our "upstream-" branches corresponds to > which actual branch upstream. I'm not really sure if that would work out. Aside from master, there's no really long-lived branches from upstream, so if we were to use any of the other branches from upstream, we'd have to re-create it every time we wanted to use a different short lived topic branch with a new name. Even harder would be if we wanted to pull from multiple topic branches (which is something I'm thinking about doing for the server). The thought of having upstream-pci-rework-randr1.2-for-server-1.2 sounds really horrendous to me :-) I had envisioned that if you want to know which upstream version we pulled from, you can just checkout the appropriate upstream branch and run git log. If you do want to map by name what version we're shipping, we could use the tag name (upstream-1.2 for example), but then we'd have to create a new upstream branch every time upstream makes a new release, which would quickly get ugly. Besides, that's why we have tags anyway. The idea behind having a simple 1:1 mapping between our debian branch and the upstream branch at least makes it simple on our end to see what upstream version maps to what debian distro. You can check out the upstream-unstable, check the log, and know that that's what's in unstable. Granted, checking the log isn't instant recognition, but it prevents us from having too many branches getting out of control. Please correct me if I'm misinterpreting you. I wouldn't be surprised if I missed something in your message. > On a different note, if we're forgoing a "master" branch in favour of > debian-unstable, then when I run git clone, which branch will present > by default, will it be debian-unstable? That's the idea. I'm setting up the beryl repositories right now according to this system, and I'm setting HEAD to be debian-unstable by default. I'm currently using upstream-unstable to import the upstream source, but if we decide to use upstream-master (or whatever else) it'll pretty trivial to create the new branch and delete the old one. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
David asked: > > URL: ssh://git.debian.org/git/pkg-xorg/$debian.git > > -Pull: refs/heads/master:refs/heads/master-origin > > +Push: refs/heads/master:refs/heads/debian-unstable > > +Push: refs/heads/upstream-master:refs/heads/upstream-master > > Why did you use 'upstream-master'? I probably was unclear in what I wrote > down, looking back on the draft. What I had in mind was > 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that > this is the best way to divide up the branches though. Do you think having > 'upstream-master' is a better way of handling things? The way I understood it, we wanted our copies of the upstream branches to keep their own upstream names verbatim but with an "upstream-" prefixed to avert name clashes. Otherwise it would get really confusing figuring out which of our "upstream-" branches corresponds to which actual branch upstream. On a different note, if we're forgoing a "master" branch in favour of debian-unstable, then when I run git clone, which branch will present by default, will it be debian-unstable? Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git-migration: Changes to 'master'
On Wed, Jan 03, 2007 at 05:53:29PM +0100, Thierry Reding wrote: > clone | 26 ++ > 1 files changed, 22 insertions(+), 4 deletions(-) > > New commits: > commit 0726222645eb8e6e4f25056e8f7244b4566825e3 > Author: Thierry Reding <[EMAIL PROTECTED]> > Date: Wed Jan 3 17:50:06 2007 +0100 > > Implement the proposed XSF git archive policy. > > diff --git a/clone b/clone > index 5df6b30..da15d46 100755 > --- a/clone > +++ b/clone > @@ -13,17 +13,35 @@ ( > debian=$(echo $line | cut -d' ' -f1) > upstream=$(echo $line | cut -d' ' -f2) > > + echo "Setting up $debian for cloning..." > if [ -d "$debian.git/.git/remotes" ]; then > # create remote `origin' branch for the alioth > repositories > cat > "$debian.git/.git/remotes/origin" << EOF > URL: ssh://git.debian.org/git/pkg-xorg/$debian.git > -Pull: refs/heads/master:refs/heads/master-origin > +Push: refs/heads/master:refs/heads/debian-unstable > +Push: refs/heads/upstream-master:refs/heads/upstream-master Why did you use 'upstream-master'? I probably was unclear in what I wrote down, looking back on the draft. What I had in mind was 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that this is the best way to divide up the branches though. Do you think having 'upstream-master' is a better way of handling things? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
