also sprach Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [2007.07.10.1905 +0200]: > These would get both branches (including all of the upstream, > of course), but that's ok, since git will share all the common > objects *anyway*, so there is no "duplication". You can have > a hundred branches, and they won't use one whit more memory of > bandwidth (apart from the branch refs themselves being sent > over, of course), and only the actual *differences* between > branches will take up space. The duplication I meant was when upstream uses SVN or a tarball, which I then have to track/import into my git repo. But it's just space and that's cheap these days. > Here, I don't really know how the debian package management is > supposed to work, but since they obviously aren't using git, > they must be using something else. A tar-ball or just a series > of patches? Both would be trivial to implement as just an > "export" from your git tree. Or you'd export the "debian" > branch as a separate SVN repo (I've not used the "export back > into a SVN" thing, so I don't know how well that works). Just in case you're interested, otherwise the following two paragraphs can be safely skipped: There is no standard for Debian packaging. In general, it's the upstream tarball and a diff to be applied for debianisation. Some people just use one giant diff, others use the diff to add patches as separate files to the unpacked contents of the tarball, which are then applied. I guess my final goal is to use git and branches, one to track upstream, one for every feature/patch I add, and then to create a source package from that by packaging the upstream branch into a tarball (or reusing an existing one), turning each branch into a single-file patch and then create the overall diff to add these single-files, including some glue to apply them automatically on unpacking/building. > > The way I tend to think about a pair of branches is that one > > depends on the other, or rather, one stems from the other. > > .. and no, that's not really how git works from a technical angle: > in the the git model, all branches are technically 100% equal, and > no branch "depends" on anything else, they are all equally > first-class citizens. Right, I knew that. What I meant is more that a branch derives off another, meaning that before and including the branching commit, they have shared ancestry. I wonder how to create a project with two completely independent branches which have no common ancestry. I don't think it's possible. One needs a throwaway branch to create the first commit, then branch each of the two branches off that, then delete the throwaya branch (or keep it around). But this is getting academic now... > > So if I made changes to the debian branch, I'd check it out > > first, then return to the upstream branch when done. > > It sounds like you would actually be fairly comfy with the git > "switch branches within one repository" model, and you might not > even need to make it look like two different trees. Definitely. As a Debian maintainer who really wants to use git for Debian packaging though, I also need to worry about all the other people who obtain my source package and need to be comfortable with it. I may well understand what my 123 branches are for and how they are interlinked, but that doesn't help Jane Schmoo fixing a release-critical bug while I'm backpacking in Southeast Asia. > But I don't want to fool you - I do think you'll have to change > *some* of how you work. But it sounds like your workflow is > *fairly* close to a very natural git flow. Thanks for the encouragement! -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck spamtraps: madduck.bogus@xxxxxxxxxxx it is better to have loft and lost than to never have loft at all. -- groucho marx
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)
