{"thread":{"id":"9709","subject":"publishing a forked^W cloned directory with ancestry","startedAt":"2007-08-30T19:25:33Z","lastAt":"2007-09-04T14:17:30Z","messageCount":5,"participants":["martin f krafft","J. Bruce Fields","Bart Trojanowski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51929","messageId":"20070830192533.GA18751@piper.oerlikon.madduck.net","threadId":"9709","inReplyTo":null,"subject":"publishing a forked^W cloned directory with ancestry","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-30T19:25:33Z","receivedAt":"2007-08-30T19:25:33Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Dear list,\n\nI am the mdadm (software RAID management) maintainer for Debian and\na recent git convert. While preparing a new mdadm package tonight,\nI found myself screaming too often at SVN [0] and decided to convert\nDebian mdadm package maintenance to git. Upstream also uses git, so\nI said to myself \"jolly good\", clapped hands, and… froze as the\npieces weren't fitting together nicely, at least from my\nunderstanding of how git works.\n\nThere are multiple ways to maintain a Debian package and I shall\ntoday only concentrate on tracking an upstream VCS repo and\npackaging it for Debian \"when I please\" (others call that\nsnapshotting). Thus, I don't wait for upstream to publish tarballs,\nI make the package from a given HEAD. There are pros and cons to\nthis, but let's just assume that it's \"the way\".\n\nSo I clone upstream and find that git-branch -r includes\nupstream/master (s/origin/upstream/ for clarity). I then branch\n'debian' off upstream/master and make some required changes. With\nutter enjoyment of git, I wrap it up and package a new mdadm.deb.\nYay.\n\nAnd then I wonder: how do I now publish this result of my work? I'd\nlike to push my repository to git.debian.org so that others can\nclone it and help or submit patches against the debianised upstream.\n\nBut the remote branch upstream/master only really exists in\n$GIT_DIR, which is local and can't be pushed. Or well, even if\nI tried, the people cloning from the push location wouldn't see it\n[1].\n\nI saw two solutions to this: using two separate upstreams/origins,\nand submodules:\n\n1. I could tell my $GIT_DIR/config that upstream/* comes from mdadm\nupstream and debian/* comes from git.debian.org and then merge\nhappily across branches locally and be done with it. However, John\nDoe, who on a rainy Saturday afternoon has two hours to spend and\nwants to fix some mdadm bugs would have to jump through hoops to\nreplicate the setup: all the ties between upstream and the\ngit.debian.org repo are local to my machine and can't be pushed\nanywhere (except to verbose documentation).\n\n2. Let's assume for a moment that all Debian changes go to ./debian,\nthen submodules seem to want to save the day. Except that Debian\nchanges are not confined to ./debian, and from the perspective of\nthe Debian mdadm maintainer and with the semantics of git-submodules\nin the back of my head [2], I'd rather want it the other way around:\nupstream be a submodule of my Debian-specific repo; but upstream\nneeds to live in . and TTBOMK, submodules can't live in .\n\nSo neither of these work and thus I am turning to you. I want to\npublish my Debian \"fork\" of mdadm in such a way that people can\neasily clone it, without pulling all the components together. How\nwould you do it?\n\nI guess the cleanest solution I can come up with is to branch off\nupstream/master into branch \"upstream\" whenever *I* decide it's time\nto snapshot. Then, people using my repo would basically be confined\nto the state of the tree as it was the last time I rebased\n\"upstream\", but could work freely on the Debian-specific stuff.\nI think this is actually quite okay, but I am still interested in\nany comments you may have.\n\nCheers,\nm\n\n\nFootnotes:\n\n[0] fine \"too often\" tonight meant \"once\" but it's once too many.\n    Thanks Linus and Junio, since I touched git I can't work most\n    other VCS anymore (this is sarcastic... not).\n[1] I tried cloning B from A, then cloning C from B. Within C, there\n    is no reference to A's master branch, so unless B pulled changes\n    from A and C pulled changes from B, C could not be updated.\n[2] The submodule's commit ID is stored in the supermodules index\n    and a commit to the submodule also requires a commit to the\n    supermodule to restore consistency.\n\n-- \n\"if builders built buildings the way\n programmers wrote programs,\n then the first woodpecker that came along\n would destroy civilization.\"\n                                                  -- gerald weinberg\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51931","messageId":"20070830194716.GA19861@piper.oerlikon.madduck.net","threadId":"9709","inReplyTo":"20070830192533.GA18751@piper.oerlikon.madduck.net","subject":"Re: publishing a forked^W cloned directory with ancestry","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-30T19:47:16Z","receivedAt":"2007-08-30T19:47:16Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach martin f krafft <madduck@madduck.net> [2007.08.30.2125 +0200]:\n> And then I wonder: how do I now publish this result of my work? I'd\n> like to push my repository to git.debian.org so that others can\n> clone it and help or submit patches against the debianised upstream.\n\nWith this I mean: it would just be nice if people cloning the\ngit.debian.org repo could also use the upstream refs. I am aware\nthat the pack they download is complete in the sense that they can\njust build after cloning (thanks to Harri Ilari Tapio Liusvaara\nthough for clearing this up for me a bit). After all, this is what\nI meant when I wrote:\n\n> I guess the cleanest solution I can come up with is to branch off\n> upstream/master into branch \"upstream\" whenever *I* decide it's time\n> to snapshot. Then, people using my repo would basically be confined\n> to the state of the tree as it was the last time I rebased\n> \"upstream\", but could work freely on the Debian-specific stuff.\n\nBut I guess in the Debian world, a bug may be fixed upstream before\nit is fixed in Debian (not only because Debian is allegedly\noutdated, also because our users and developers often cooperate\ndirectly with upstream), and then when someone jumps in for me to\nrelease a new mdadm package, they might just need to rebase to the\nlatest upstream HEAD.\n\nIs it possible to enable this with git without asking those people\nto first set up their local repo to reference git.debian.org *and*\nupstream, all of which is likely going to be more than four\ncommands?\n\nHarri hinted at using Makefiles, and sure, I can use the Makefile to\nset up upstream if it's not already present, but I'd much rather\nhave a standard way that's going to be the same across all\ngit-maintained Debian packages.\n\nComments welcome,\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"no woman should ever be quite accurate about her age.\n it looks so calculating.\"\n                                                        -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51932","messageId":"20070830194947.GB10808@fieldses.org","threadId":"9709","inReplyTo":"20070830192533.GA18751@piper.oerlikon.madduck.net","subject":"Re: publishing a forked^W cloned directory with ancestry","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-08-30T19:49:47Z","receivedAt":"2007-08-30T19:49:47Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Aug 30, 2007 at 09:25:33PM +0200, martin f krafft wrote:\n> So I clone upstream and find that git-branch -r includes\n> upstream/master (s/origin/upstream/ for clarity). I then branch\n> 'debian' off upstream/master and make some required changes. With\n> utter enjoyment of git, I wrap it up and package a new mdadm.deb.\n> Yay.\n> \n> And then I wonder: how do I now publish this result of my work? I'd\n> like to push my repository to git.debian.org so that others can\n> clone it and help or submit patches against the debianised upstream.\n\nSo in the setup you describe if they clone your repo then they'll get a\nsingle branch called 'debian' with your work in it.  That sounds fine to\nme, actually.\n\n> But the remote branch upstream/master only really exists in\n> $GIT_DIR, which is local and can't be pushed. Or well, even if\n> I tried, the people cloning from the push location wouldn't see it\n\nThey can always just fetch from upstream as well if they'd like.  They\ncould do something like:\n\n\tgit clone git://coolproject.org/cool.git\n\tcd cool\n\tgit remote add debian git://git.debian.org/cool.git\n\tgit fetch debian\n\nThen they have a repository where git-branch -r reports something like\n\n\torigin/master\n\tdebian/debian\n\nOr they could do it the other way around, with \"origin\" pointing to you\nand an \"upstream\" remote pointing to coolproject.org.  The naming's\nobviously up to them.\n\n> 1. I could tell my $GIT_DIR/config that upstream/* comes from mdadm\n> upstream and debian/* comes from git.debian.org and then merge\n> happily across branches locally and be done with it. However, John\n> Doe, who on a rainy Saturday afternoon has two hours to spend and\n> wants to fix some mdadm bugs would have to jump through hoops to\n> replicate the setup: all the ties between upstream and the\n> git.debian.org repo are local to my machine and can't be pushed\n> anywhere (except to verbose documentation).\n\nMaybe the one extra \"git remote add ...; git remote fetch\" isn't such a\nbig deal?\n\n> I guess the cleanest solution I can come up with is to branch off\n> upstream/master into branch \"upstream\" whenever *I* decide it's time\n> to snapshot. Then, people using my repo would basically be confined\n> to the state of the tree as it was the last time I rebased\n> \"upstream\", but could work freely on the Debian-specific stuff.\n> I think this is actually quite okay, but I am still interested in\n> any comments you may have.\n\nSure, you can do that.  I don't think it's really necessary.\n\nMy local kernel repository, for example, currently knows about five\nother repos:\n\n\t$ git remote\n\tlabiaga\t\t# server pnfs work\n\tlinux-nfs\t# my public repo\n\torigin\t\t# Linus's repo\n\trichterd\t# a coworker's nfs work\n\ttrond\t\t# Trond's nfs stuff\n\nSure, each of those could add a \"linus\" branch that tracked upstream, so\nI could still get some idea what Linus's tree was even if I didn't\nhappen to already have it.  But then I'd end up with 4 different\nslightly-out-of-date pointers to the head of linus's repo in each of\nthose trees, which would end up being just be a bunch of cruft that I'd\nhave to ignore whenever I looked at them.\n\n--b.\n"},{"id":"51937","messageId":"20070830202747.GT10772@jukie.net","threadId":"9709","inReplyTo":"20070830192533.GA18751@piper.oerlikon.madduck.net","subject":"Re: publishing a forked^W cloned directory with ancestry","fromName":"Bart Trojanowski","fromEmail":"bart@jukie.net","sentAt":"2007-08-30T20:27:47Z","receivedAt":"2007-08-30T20:27:47Z","isPatch":false,"sender":{"key":"bart@jukie.net","avatar":"https://avatars.githubusercontent.com/u/6721?v=4"},"body":"* martin f krafft <madduck@madduck.net> [070830 15:25]:\n> [1] I tried cloning B from A, then cloning C from B. Within C, there\n>     is no reference to A's master branch, so unless B pulled changes\n>     from A and C pulled changes from B, C could not be updated.\n\nI think a .git/config like this will do what you want:\n\n[remote \"upstream\"]\n        url = git://mdadm-upstream-repo\n        fetch = +refs/heads/*:refs/remotes/upstream/*\n\n[remote \"debian\"]\n        url = git://debian-repo-you-want-to-publish-to\n        fetch = +refs/heads/*:refs/remotes/debian/*\n        push = refs/remotes/upstream/master:refs/heads/upstream\n        push = refs/heads/master:refs/heads/master\n\nNow when you 'git push debian' it will populate the 'upstream' and\n'master' branches properly.\n\nWhen someone clones your repo, they will get origin/master (your branch)\nand origin/upstream (the official mdadm branch).\n\nDid I understand the problem correctly?\n\n-Bart\n\n-- \n\t\t\t\tWebSig: http://www.jukie.net/~bart/sig/\n"},{"id":"52470","messageId":"20070904141730.GA25759@lapse.madduck.net","threadId":"9709","inReplyTo":"20070830202747.GT10772@jukie.net","subject":"Re: publishing a forked^W cloned directory with ancestry","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-04T14:17:30Z","receivedAt":"2007-09-04T14:17:30Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach J. Bruce Fields <bfields@fieldses.org> [2007.08.30.2149 +0200]:\n> Maybe the one extra \"git remote add ...; git remote fetch\" isn't\n> such a big deal?\n\n[...]\n\n> Sure, each of those could add a \"linus\" branch that tracked\n> upstream, so I could still get some idea what Linus's tree was\n> even if I didn't happen to already have it.  But then I'd end up\n> with 4 different slightly-out-of-date pointers to the head of\n> linus's repo in each of those trees, which would end up being just\n> be a bunch of cruft that I'd have to ignore whenever I looked at\n> them.\n\nThanks to you and everyone else who replied! I spent some time off\ncomputers and still found myself thinking about this as I was hiking\naround woods and mountains and in the end, it's perfectly obvious:\n\nI am trying to make it easy for third parties to contribute to my\ngit-managed project and I (somewhat rightfully) assumed that\nI needed to shield my poor contributors from git's complex\ntentacles. In doing so, I find myself going backwards and turning\ngit into something svn-like, thus losing much of its power.\n\nThe solution is clear: maintain only my Debian branch on\ngit.debian.org and expect those cloning it to add the upstream\nremote themselves in true distributed manners. A concise file in the\nproject root with instructions is a nice add-on.\n\n\n\nalso sprach Bart Trojanowski <bart@jukie.net> [2007.08.30.2227 +0200]:\n> Now when you 'git push debian' it will populate the 'upstream' and\n> 'master' branches properly.\n> \n> When someone clones your repo, they will get origin/master (your\n> branch) and origin/upstream (the official mdadm branch).\n\nThis is the solution I had stuck in my head for the longest time\n(after you proposed it), but I eventually discard it for one simple\nreason: the danger that someone pushes to the upstream branch and\nthus diverges it from the real upstream is just too high and would\nresult in a pretty nasty mess, as far as I can tell.\n\n> Did I understand the problem correctly?\n\nI think you did. And thanks for that. I hope my reasoning above also\nmakes sense.\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"the surest way to corrupt a youth is to instruct him to hold in\n higher esteem those who think alike than those who think\n differently.\"\n                                              -- friedrich nietzsche\n \nspamtraps: madduck.bogus@madduck.net\n"}]}