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]
