{"thread":{"id":"8949","subject":"how to combine two clones in a collection","startedAt":"2007-07-09T22:22:50Z","lastAt":"2007-07-11T19:22:25Z","messageCount":16,"participants":["martin f krafft","Linus Torvalds","Junio C Hamano","Martin Langhoff","Brian Gernhardt","Kalle Pokki","Robin Rosenberg","Jakub Narebski","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46896","messageId":"20070709222250.GA8007@piper.oerlikon.madduck.net","threadId":"8949","inReplyTo":null,"subject":"how to combine two clones in a collection","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-09T22:22:50Z","receivedAt":"2007-07-09T22:22:50Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Dear list,\n\nI am new to git but already quite sold on it. Especially git-svn\nmakes my heart jump.\n\nI am now ready to move to using git for most of my everyday work,\nbut I am still unsure how to tackle one specific aspect of it, for\nwhich I used svn:externals in the past. I know about git\nsubprojects, but these aren't what I want, really.\n\nI am a Debian developer, and while the upstream trunk is usually\nmaintained in SVN by upstream him/herself, I maintain the ./debian\ndirectory elsewhere.\n\nWith SVN, I would have a directory with two external entries:\n\n upstream.trunk svn+ssh://svn.upstream.org/path/to/trunk\n upstream.trunk/debian svn+ssh://svn.debian.org/svn/pkg/trunk/debian\n\nI hope this makes what I mean obvious. GNU arch has a similar\nconcept called configs.\n\nHow can I do this with git? I am aware that maybe the best way would\nbe to use git-svn to track the upstream branch remotely and to add\n./debian in a separate git branch (and to stop using SVN and switch\nto git for ./debian), but I am not sure I want to mirror all\nupstream projects in git repos published on svn.debian.org, and if\nit's only for space reasons.\n\nDo you know of other approaches, short of writing my own\nconfig-manager?\n\nThanks,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \n\"never eat more than you can lift.\"\n -- miss piggy\n"},{"id":"46905","messageId":"alpine.LFD.0.999.0707091923300.3412@woody.linux-foundation.org","threadId":"8949","inReplyTo":"20070709222250.GA8007@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-10T02:35:21Z","receivedAt":"2007-07-10T02:35:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 10 Jul 2007, martin f krafft wrote:\n> \n> I am now ready to move to using git for most of my everyday work,\n> but I am still unsure how to tackle one specific aspect of it, for\n> which I used svn:externals in the past. I know about git\n> subprojects, but these aren't what I want, really.\n\nI really _think_ that what you want is to just use separate branches, if I \nunderstand correctly. That makes it really easy to just have both lines of \ndevelopment (both the \"trunk\" and your \"debian\" one) in one git \nrepository.\n\nOf course, especially if you want to continue to work the way you probably \nworked with SVN (ie you are used to seeing those two branches as two \nseparate directories), that means that while you can (and should) see it \nas a single git project, you'd normally end up just having two copies of \nthat project: they'd _both_ have two branches, but they'd just en dup \nhaving different branches checked out.\n\nOf course, after you get comfy enough with the setup, you might end up \njust deciding that you might as well just switch branches around in a \nsingle repository (which is what a lot of git users end up doing), but at \nleast initially, it's probably easier from a conceptual standpoint to just \nhave the two branches checked out in separate copies of the repos.\n\n> With SVN, I would have a directory with two external entries:\n> \n> upstream.trunk svn+ssh://svn.upstream.org/path/to/trunk\n> upstream.trunk/debian svn+ssh://svn.debian.org/svn/pkg/trunk/debian\n\nSo in git, you'd have just one \"project\" with two branches - perhaps just \ncalled \"upstream\" and \"debian\".\n\nOf course, with git, that single \"project\" can then exist in a distributed \nmanner in many different places, and having two copies with different \nbranches checked out would just happen to be the one that most closely \nresembles your current situation.\n\n> How can I do this with git? I am aware that maybe the best way would\n> be to use git-svn to track the upstream branch remotely and to add\n> ./debian in a separate git branch (and to stop using SVN and switch\n> to git for ./debian)\n\nI don't think you'd have to stop using SVN. Just continue to track the \n\"upstream\" branch with git-svn, and then you can merge in the upstream \ninto your \"debian\" branch that also has all the debian-specific stuff.\n\n(And no, I don't know what the standard debian package management setup \nlooks like, but I would hope that your extra stuff would be just a few \nfiles and package descriptions, and obviously any of the local debian \nchanges to the project).\n\n\t\tLinus\n"},{"id":"46919","messageId":"20070710062104.GA22603@piper.oerlikon.madduck.net","threadId":"8949","inReplyTo":"alpine.LFD.0.999.0707091923300.3412@woody.linux-foundation.org","subject":"Re: how to combine two clones in a collection","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-10T06:21:04Z","receivedAt":"2007-07-10T06:21:04Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Thanks, Linus, for your time in answering my questions. I have some\nmore comments and questions in reply. I hope I am coherent enough,\nthis subject matter doesn't exactly flow off my tongue with ease\nyet...\n\nalso sprach Linus Torvalds [2007.07.10.0435 +0200]:\n> I really _think_ that what you want is to just use separate\n> branches, if I understand correctly. That makes it really easy to\n> just have both lines of development (both the \"trunk\" and your\n> \"debian\" one) in one git repository.\n\nIt does mean, however, that I duplicate the upstream into my repo,\nand thus into the published repo at git.debian.org, because I cannot\njust publish a single branch ('debian') in such a way that people\ncould clone it and still be able to build the package against\nupstream (which they'd have to obtain for themselves), right?\n\n> Of course, especially if you want to continue to work the way you\n> probably worked with SVN (ie you are used to seeing those two\n> branches as two separate directories), that means that while you\n> can (and should) see it as a single git project, you'd normally\n> end up just having two copies of that project: they'd _both_ have\n> two branches, but they'd just en dup having different branches\n> checked out.\n\nThe way I tend to think about a pair of branches is that one depends\non the other, or rather, one stems from the other. Thus, I'd\nprobably branch the 'debian' branch off 'upstream', and add the\n./debian directory, and then either rebase the debian branch onto\nnew upstream heads, or merge upstream into the debian branch on new\nversions.\n\nThis makes perfect sense and I have been experimenting with such\na workflow before:\nhttp://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html\n\nSo if I made changes to the debian branch, I'd check it out first,\nthen return to the upstream branch when done.\n\nYour suggestion to checkout the same repo twice with different\nbranches does sound a lot like the way I used to do things in SVN.\nHowever, I guess what I am trying to prevent is having to manually\nset up this hierarchy on each machine I choose to work on. Instead,\nI'd rather be able to clone a repository and be ready to work.\n\nIn your scenario, would I make two branches and then import upstream\ninto one, the ./debian directory into the other, and never ever\nmerge back and forth again, thus treating them as separate\ndirectories?\n\n> Of course, after you get comfy enough with the setup, you might\n> end up just deciding that you might as well just switch branches\n> around in a single repository (which is what a lot of git users\n> end up doing), but at least initially, it's probably easier from\n> a conceptual standpoint to just have the two branches checked out\n> in separate copies of the repos.\n\nOkay, this is beginning to make sense. However, the debian branch\ntracks changes mostly to ./debian/*. To check it out separately,\nI need a directory. If usptream is checked out to ., then if I'd\ncheck out the debian branch do ./debian, I'd end up with\n./debian/debian. Do you suggest the use of a symlink then?\n\n> > How can I do this with git? I am aware that maybe the best way\n> > would be to use git-svn to track the upstream branch remotely\n> > and to add ./debian in a separate git branch (and to stop using\n> > SVN and switch to git for ./debian)\n> \n> I don't think you'd have to stop using SVN.\n\nI think I would want to. :)\n\n> (And no, I don't know what the standard debian package management\n> setup looks like, but I would hope that your extra stuff would be\n> just a few files and package descriptions, and obviously any of\n> the local debian changes to the project).\n\nYour hopes seem to be quite close to reality. :)\n\nThanks,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \nhttp://www.vcnet.com/bms/\n"},{"id":"46921","messageId":"7v3azwsp6a.fsf@assigned-by-dhcp.cox.net","threadId":"8949","inReplyTo":"20070710062104.GA22603@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-10T07:17:33Z","receivedAt":"2007-07-10T07:17:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"martin f krafft writes:\n\n> Thanks, Linus, for your time in answering my questions. I have some\n> more comments and questions in reply. I hope I am coherent enough,\n> this subject matter doesn't exactly flow off my tongue with ease\n> yet...\n>\n> also sprach Linus Torvalds [2007.07.10.0435 +0200]:\n>> I really _think_ that what you want is to just use separate\n>> branches, if I understand correctly. That makes it really easy to\n>> just have both lines of development (both the \"trunk\" and your\n>> \"debian\" one) in one git repository.\n>\n> It does mean, however, that I duplicate the upstream into my repo,\n> and thus into the published repo at git.debian.org, because I cannot\n> just publish a single branch ('debian') in such a way that people\n> could clone it and still be able to build the package against\n> upstream (which they'd have to obtain for themselves), right?\n\nI've seen two kinds of debianized source tree. One kind has\nchanges already applied to the pristine source outside debian/\nsubdirectory, and debian/rules does the debian specific\ncustomized build, install and packaging. The other kind does\nnot have _any_ change to the pristine except it has debian/\nsubdirectory and the first thing debian/rules does is to apply\npatches to pristine from patch files kept in debian/\nsubdirectory. The answer largely depends on which arrangement\nyou have in mind for your package.\n\nFor the former kind, It is unavoidable for people to get your\n(slightly modified) upstream source from you --- there is\nnowhere else that stores what you changed. Extracting the\nvanilla pristine and debian/ separately would not cut it. For\nsuch an arrangement, \"upstream\" (or \"pristine\") branch would\ncontain everything you get from your upstream tarball (or SVN)\nwithout any of Debianization changes (you can still have generic\n\"fixes and enhancements\" of your own there to be fed upstream).\nYour \"master\" (you could call it \"debianization\") branch will\nfork off of that branch, and the first commit on that branch\nwould add debian/ subdirectory. All the debianization\nmodification to the upstream, if needed, also go to this branch.\nYour users will clone and pull from your \"master\" and do\n\"fakeroot debian/rules binary\" or whatever, and all is good.\n\nFor the latter, since the changes from upstream is isolated to\nyour additional debian/ subdirectory, you could arrange your\nrepository like this, even without using the subproject support:\n\n\t.git/\n .gitignore (perhaps untracked)\n Makefile (upstream)\n foo.c (upstream)\n ...\n debian/.git\n debian/rules (yours)\n debian/control (yours)\n ...\n\nThen, have the top-level .git/ repository control pristine\nupstream sources from SVN (you may want to add .gitignore to\nignore debian/ subdirectory). In debian/, you create another\nindependent repository, and maintain _ONLY_ debianization. You\ncould even publish only that repository to your users without\npublishing the upstream sources, if they know which version of\nupstream source to use.\n\nI tend to prefer the former, from the end user's point of view.\n"},{"id":"46923","messageId":"20070710074013.GA457@piper.oerlikon.madduck.net","threadId":"8949","inReplyTo":"7v3azwsp6a.fsf@assigned-by-dhcp.cox.net","subject":"Re: how to combine two clones in a collection","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-10T07:40:13Z","receivedAt":"2007-07-10T07:40:13Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Junio C Hamano [2007.07.10.0917 +0200]:\n> For the former kind, It is unavoidable for people to get your\n> (slightly modified) upstream source from you --- there is\n> nowhere else that stores what you changed.\n\nThis is pretty similar to a method developed by Manoj Srivastava adn\ndescribed here: http://arch.debian.org/arch/private/srivasta/ and\nit's very promising, albeit a little complex for newcomers, in my\nexperience. As linked previously, I presented a similar workflow\nwith git[0] at DebConf7[1].\n\n0. http://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html\n1. https://penta.debconf.org/~joerg/events/53.en.html\n\nI actually knew the answers to my questions, I guess, but I was way\ntoo confused to get the picture straight. Thanks to both of you for\nyour time in helping me understand.\n\nI shall spend some time experimenting and will then blog about my\nexperience of converting the various types of Debian source packages\nto the suggested style of maintenance. I shall post the URL to this\nthread too.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \n\"for art to exist, for any sort of aesthetic activity or perception to\n exist, a certain physiological precondition is indispensable:\n intoxication.\"\n -- friedrich nietzsche\n"},{"id":"46925","messageId":"46a038f90707100051l5f226799sa8f3231b1c096722@mail.gmail.com","threadId":"8949","inReplyTo":"20070710062104.GA22603@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-07-10T07:51:11Z","receivedAt":"2007-07-10T07:51:11Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 7/10/07, martin f krafft wrote:\n> It does mean, however, that I duplicate the upstream into my repo,\n> and thus into the published repo at git.debian.org, because I cannot\n> just publish a single branch ('debian') in such a way that people\n> could clone it and still be able to build the package against\n> upstream (which they'd have to obtain for themselves), right?\n\nYes. But is that a problem? In most cases, the complete history of the\nproject is fairly small if your repo is well packed. Often not much\nbigger than a tarball of one source snapshot.\n\nWhat does the following say?\n\n git repack -a -d\n du -sh .git/objects/pack\n\ncheers,\n\n\nmartni\n"},{"id":"46967","messageId":"alpine.LFD.0.999.0707100950520.3412@woody.linux-foundation.org","threadId":"8949","inReplyTo":"20070710062104.GA22603@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-10T17:05:53Z","receivedAt":"2007-07-10T17:05:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 10 Jul 2007, martin f krafft wrote:\n> \n> also sprach Linus Torvalds [2007.07.10.0435 +0200]:\n> > I really _think_ that what you want is to just use separate\n> > branches, if I understand correctly. That makes it really easy to\n> > just have both lines of development (both the \"trunk\" and your\n> > \"debian\" one) in one git repository.\n> \n> It does mean, however, that I duplicate the upstream into my repo,\n> and thus into the published repo at git.debian.org, because I cannot\n> just publish a single branch ('debian') in such a way that people\n> could clone it and still be able to build the package against\n> upstream (which they'd have to obtain for themselves), right?\n\nWell, I think you have two cases:\n\n - the git users\n\n These would get both branches (including all of the upstream, of \n course), but that's ok, since git will share all the common objects \n *anyway*, so there is no \"duplication\". You can have a hundred \n branches, and they won't use one whit more memory of bandwidth (apart \n from the branch refs themselves being sent over, of course), and only \n the actual *differences* between branches will take up space.\n\n - the non-git users\n\n Here, I don't really know how the debian package management is supposed \n to work, but since they obviously aren't using git, they must be using \n something else. A tar-ball or just a series of patches? Both would be \n trivial to implement as just an \"export\" from your git tree. Or you'd \n export the \"debian\" branch as a separate SVN repo (I've not used the \n \"export back into a SVN\" thing, so I don't know how well that works).\n\nIn particular, if all your \"debian-specific\" stuff is almost all in the \n\"debian\" subdirectory, then you can trivially make a tar-file by just \nusing\n\n\tgit archive --prefix=upstream- HEAD debian > upstream-debian.tar\n\nand git will literally generate the tar-file of that directory for you.\n\n> The way I tend to think about a pair of branches is that one depends\n> on the other, or rather, one stems from the other.\n\n.. and no, that's not really how git works from a technical angle: in the \nthe git model, all branches are technically 100% equal, and no branch \n\"depends\" on anything else, they are all equally first-class citizens.\n\nBut while *technically* all branches are equal in git, at the same time \nthere's no reason not to _think_ of branches as having a hierarchy if you \nwant to. In particular:\n\n - it's how people tend to use git anyway (ie the \"origin\" branch is \n what you're tracking, and you have your own changes in your local \n branches)\n\n - and git will never duplicate information for branches that have a \n common history or contents anyway. So while git branches are totally \n \"independent\" in the technical sense, the data structures are all \n designed so that they will share everything that they can possibly \n share (in fact, thanks to the \"delta-against-anything\" model, different \n branches will share much more than in something like CVS/SVN)\n\n> So if I made changes to the debian branch, I'd check it out first,\n> then return to the upstream branch when done.\n\nIt sounds like you would actually be fairly comfy with the git \"switch \nbranches within one repository\" model, and you might not even need to make \nit look like two different trees.\n\n> Okay, this is beginning to make sense. However, the debian branch\n> tracks changes mostly to ./debian/*. To check it out separately,\n> I need a directory. If usptream is checked out to ., then if I'd\n> check out the debian branch do ./debian, I'd end up with\n> ./debian/debian. Do you suggest the use of a symlink then?\n\nNo, I'm suggesting that you have the upstream thing checked out in \".\", \nand you have the \"debian\" branch IN THE SAME PLACE. So when you do\n\n\tgit checkout debian\n\nit will just check out all the debian stuff in the same directory, so now \nyou'll get a ./debian/ directory with all your debian stuff.\n\nWhen you do\n\n\tgit checkout upstream\n\nthe files in that directory just go away, because it doesn't exist in \nthe \"upstream\" branch\n\nBut I don't want to fool you - I do think you'll have to change *some* of \nhow you work. But it sounds like your workflow is *fairly* close to a very \nnatural git flow.\n\n\t\tLinus\n"},{"id":"46971","messageId":"20070710174543.GA16054@piper.oerlikon.madduck.net","threadId":"8949","inReplyTo":"alpine.LFD.0.999.0707100950520.3412@woody.linux-foundation.org","subject":"Re: how to combine two clones in a collection","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-10T17:45:43Z","receivedAt":"2007-07-10T17:45:43Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Linus Torvalds [2007.07.10.1905 +0200]:\n> These would get both branches (including all of the upstream,\n> of course), but that's ok, since git will share all the common\n> objects *anyway*, so there is no \"duplication\". You can have\n> a hundred branches, and they won't use one whit more memory of\n> bandwidth (apart from the branch refs themselves being sent\n> over, of course), and only the actual *differences* between\n> branches will take up space.\n\nThe duplication I meant was when upstream uses SVN or a tarball,\nwhich I then have to track/import into my git repo. But it's just\nspace and that's cheap these days.\n\n> Here, I don't really know how the debian package management is\n> supposed to work, but since they obviously aren't using git,\n> they must be using something else. A tar-ball or just a series\n> of patches? Both would be trivial to implement as just an\n> \"export\" from your git tree. Or you'd export the \"debian\"\n> branch as a separate SVN repo (I've not used the \"export back\n> into a SVN\" thing, so I don't know how well that works).\n\nJust in case you're interested, otherwise the following two\nparagraphs can be safely skipped:\n\n There is no standard for Debian packaging. In general, it's the\n upstream tarball and a diff to be applied for debianisation. Some\n people just use one giant diff, others use the diff to add patches\n as separate files to the unpacked contents of the tarball, which\n are then applied.\n\n I guess my final goal is to use git and branches, one to track\n upstream, one for every feature/patch I add, and then to create\n a source package from that by packaging the upstream branch into\n a tarball (or reusing an existing one), turning each branch into\n a single-file patch and then create the overall diff to add these\n single-files, including some glue to apply them automatically on\n unpacking/building.\n\n> > The way I tend to think about a pair of branches is that one\n> > depends on the other, or rather, one stems from the other.\n> \n> .. and no, that's not really how git works from a technical angle:\n> in the the git model, all branches are technically 100% equal, and\n> no branch \"depends\" on anything else, they are all equally\n> first-class citizens.\n\nRight, I knew that. What I meant is more that a branch derives off\nanother, meaning that before and including the branching commit,\nthey have shared ancestry.\n\nI wonder how to create a project with two completely independent\nbranches which have no common ancestry. I don't think it's possible.\nOne needs a throwaway branch to create the first commit, then branch\neach of the two branches off that, then delete the throwaya branch\n(or keep it around).\n\nBut this is getting academic now...\n\n> > So if I made changes to the debian branch, I'd check it out\n> > first, then return to the upstream branch when done.\n> \n> It sounds like you would actually be fairly comfy with the git\n> \"switch branches within one repository\" model, and you might not\n> even need to make it look like two different trees.\n\nDefinitely.\n\nAs a Debian maintainer who really wants to use git for Debian\npackaging though, I also need to worry about all the other people\nwho obtain my source package and need to be comfortable with it.\nI may well understand what my 123 branches are for and how they are\ninterlinked, but that doesn't help Jane Schmoo fixing\na release-critical bug while I'm backpacking in Southeast Asia.\n\n> But I don't want to fool you - I do think you'll have to change\n> *some* of how you work. But it sounds like your workflow is\n> *fairly* close to a very natural git flow.\n\nThanks for the encouragement!\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \nit is better to have loft and lost\nthan to never have loft at all.\n -- groucho marx\n"},{"id":"46976","messageId":"72218C10-EE5E-4CD9-B5DE-DFEC40EBEF27@silverinsanity.com","threadId":"8949","inReplyTo":"20070710174543.GA16054@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-07-10T18:27:39Z","receivedAt":"2007-07-10T18:27:39Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 10, 2007, at 1:45 PM, martin f krafft wrote:\n> I wonder how to create a project with two completely independent\n> branches which have no common ancestry. I don't think it's possible.\n> One needs a throwaway branch to create the first commit, then branch\n> each of the two branches off that, then delete the throwaya branch\n> (or keep it around).\n>\n> But this is getting academic now...\n\nBut interesting.\n\nWhat you describe won't create two independent branches. They'll \nshare the root commit. I think what you have do is create the first \nbranch as normal, then clear out the working copy (be sure not to \ndelete .git) and do the commit manually. I believe it goes something \nlike this:\n\n git init\n # Create files for master\n git add .\n git commit\n rm -rf * .git/index\n # Create files for second branch\n git add .\n tree=$(git write-tree)\n # Edit commit message into some file (commit-msg here)\n commit=$(git commit-tree $tree < commit-msg)\n git update-ref refs/branches/independent $commit\n\nThe important bits are to be sure to remove the index so you don't \ncommit the wrong files and the last four lines that do the heavy \nlifting. You could also create the branch in a second repository and \npull it from there into the first (probably simpler), or perhaps \ntrick git-commit into thinking there isn't any commits yet (remove \nthe index and HEAD perhaps?).\n\n~~ Brian\n"},{"id":"46979","messageId":"m3644suki6.fsf@host32.eke.fi","threadId":"8949","inReplyTo":"72218C10-EE5E-4CD9-B5DE-DFEC40EBEF27@silverinsanity.com","subject":"Re: how to combine two clones in a collection","fromName":"Kalle Pokki","fromEmail":"kalle.pokki@iki.fi","sentAt":"2007-07-10T19:27:45Z","receivedAt":"2007-07-10T19:27:45Z","isPatch":false,"sender":{"key":"kalle.pokki@iki.fi","avatar":null},"body":"Brian Gernhardt writes:\n\n> What you describe won't create two independent branches. They'll\n> share the root commit. I think what you have do is create the first\n> branch as normal, then clear out the working copy (be sure not to\n> delete .git) and do the commit manually. I believe it goes something\n> like this:\n\nYou can also just create two different git repositories and start making\nthe commits in the master (or any other) branch. Then combine the\nrepositories by fetching\n\n cd repo1\n git fetch ../repo2 master:repo2\n\nThis way the branches don't share anything, do they?\n"},{"id":"46982","messageId":"47015E14-FEA7-45C5-B9CB-C949B87B6494@silverinsanity.com","threadId":"8949","inReplyTo":"m3644suki6.fsf@host32.eke.fi","subject":"Re: how to combine two clones in a collection","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-07-10T20:00:49Z","receivedAt":"2007-07-10T20:00:49Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 10, 2007, at 3:27 PM, Kalle Pokki wrote:\n\n> You can also just create two different git repositories and start \n> making\n> the commits in the master (or any other) branch. Then combine the\n> repositories by fetching\n>\n> cd repo1\n> git fetch ../repo2 master:repo2\n>\n> This way the branches don't share anything, do they?\n\nYes, that's what I was referring to at the end when I wrote:\n\n> You could also create the branch in a second repository and pull it \n> from there into the first (probably simpler),\n\nBut it seemed too simple. ;-) And that is exactly how I'd do it... \nAssuming I thought of it before using write-tree, commit-tree, and \nupdate-ref. (Which is what happened. I thought of the complicated \nmethod and wrote it up before thinking \"duh, just use a second repo.\")\n\n~~ Brian\n"},{"id":"46993","messageId":"200707110145.28931.robin.rosenberg.lists@dewire.com","threadId":"8949","inReplyTo":"47015E14-FEA7-45C5-B9CB-C949B87B6494@silverinsanity.com","subject":"Re: how to combine two clones in a collection","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-10T23:45:27Z","receivedAt":"2007-07-10T23:45:27Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 10 juli 2007 skrev Brian Gernhardt:\n> \n> On Jul 10, 2007, at 3:27 PM, Kalle Pokki wrote:\n> \n> > You can also just create two different git repositories and start \n> > making\n> > the commits in the master (or any other) branch. Then combine the\n> > repositories by fetching\n> >\n> > cd repo1\n> > git fetch ../repo2 master:repo2\n> >\n> > This way the branches don't share anything, do they?\n> \n> Yes, that's what I was referring to at the end when I wrote:\n> \n> > You could also create the branch in a second repository and pull it \n> > from there into the first (probably simpler),\n> \n> But it seemed too simple. ;-) And that is exactly how I'd do it... \n> Assuming I thought of it before using write-tree, commit-tree, and \n> update-ref. (Which is what happened. I thought of the complicated \n> method and wrote it up before thinking \"duh, just use a second repo.\")\n\nAnd the simplest way to create an new indpendent branch:\n\necho ref: refs/heads/newbranch >.git/HEAD\nThen prepare the content and commit like you used to do.\n\n-- robin\n"},{"id":"47021","messageId":"f72ceh$ke6$1@sea.gmane.org","threadId":"8949","inReplyTo":"20070710174543.GA16054@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-11T10:46:39Z","receivedAt":"2007-07-11T10:46:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"martin f krafft wrote:\n\n> I wonder how to create a project with two completely independent\n> branches which have no common ancestry. I don't think it's possible.\n> One needs a throwaway branch to create the first commit, then branch\n> each of the two branches off that, then delete the throwaya branch\n> (or keep it around).\n\nGit repository itself has a few completely independent branches, some of\nthem visible. One of them, the 'todo' branch is actually from independent\nrepository, two other, 'man' and 'html' are generated automatically by the\nbuild script.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"47053","messageId":"20070711181301.GA26815@piper.oerlikon.madduck.net","threadId":"8949","inReplyTo":"200707110145.28931.robin.rosenberg.lists@dewire.com","subject":"Re: how to combine two clones in a collection","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-11T18:13:01Z","receivedAt":"2007-07-11T18:13:01Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach robin:\n> And the simplest way to create an new indpendent branch:\n\n> echo ref: refs/heads/newbranch >.git/HEAD\n> Then prepare the content and commit like you used to do.\n\nHi Robin, thanks for this nice suggestion, which doesn't only\ncreatea a new, independent branch, it also teaches me yet a bit\nmore about git.\n\nI am a little uneasy about touching files in .git with non-git\ntools, but everyone seems to be doing it, so I guess it's okay, and\nit make git a lot more powerful too.\n\nAnyway, I tried your method and there is one small problem:\n\n piper:~> git init-db\n Initialized empty Git repository in .git/\n piper:~> date > date; git add date; git commit -m.\n Created initial commit 2dd8d6f: .\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 date\n piper:~> echo ref: refs/heads/newbranch >| .git/HEAD\n piper:~> git status\n # On branch newbranch\n #\n # Initial commit\n #\n # Changes to be committed:\n # (use \"git rm --cached ...\" to unstage)\n #\n # new file: date\n #\n\nIf I were to run commit now, the file 'date' would become part of\nthe first commit to newbranch. But it's already in the master\nbranch.\n\nIs there anyway I can prevent this and start a new branch from\nscratch without having to unstage all previous additions?\n\nThanks,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \n\"anyone who is capable of getting themselves made president\n should on no account be allowed to do the job\"\n -- douglas adams\n"},{"id":"47057","messageId":"Pine.LNX.4.64.0707111929120.4516@racer.site","threadId":"8949","inReplyTo":"20070711181301.GA26815@piper.oerlikon.madduck.net","subject":"Re: how to combine two clones in a collection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-11T18:37:10Z","receivedAt":"2007-07-11T18:37:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Jul 2007, martin f krafft wrote:\n\n> also sprach robin:\n> > And the simplest way to create an new indpendent branch:\n> \n> > echo ref: refs/heads/newbranch >.git/HEAD\n> > Then prepare the content and commit like you used to do.\n> \n> I am a little uneasy about touching files in .git with non-git\n> tools, but everyone seems to be doing it, so I guess it's okay, and\n> it make git a lot more powerful too.\n\nYou can achieve the same with\n\n\tgit symbolic-ref HEAD refs/heads/newbranch\n\nThere. No editing in .git/.\n\n> piper:~> echo ref: refs/heads/newbranch >| .git/HEAD\n> piper:~> git status\n> # On branch newbranch\n> #\n> # Initial commit\n> #\n> # Changes to be committed:\n> # (use \"git rm --cached ...\" to unstage)\n> #\n> # new file: date\n> #\n\nHowever, this is much easier without Git commands:\n\n\trm .git/index\n\nOf course, you can remove all files one by one, but that is certainly not \neasier:\n\n\tgit ls-files --cached -z | xargs -0 git rm --cached\n\nBut then, you really can learn from both examples: .git/index contains \nreferences to the objects which are staged (in Git speak: \"in the index\"). \nGit plays nicely when that file is missing, and assumes the index to be \nempty.\n\nWith \"git ls-files --cached\", you can list the files which are in the \nindex, and with \"git rm --cached\", you remove the file _only_ from the \nindex, but keep it in the working tree (if it is there). The options \"-z\" \nand \"-0\" are only to separate the names by NUL instead of newlines, to \nallow funny file names, too.\n\nIf a few more people ask for that feature, we could enhance the semantics \nof \"git branch\" and \"git checkout\" to interpret the empty string \nsimilar to \"git push :\".\n\nCiao,\nDscho\n"},{"id":"47063","messageId":"20070711192225.GB31957@piper.oerlikon.madduck.net","threadId":"8949","inReplyTo":"Pine.LNX.4.64.0707111929120.4516@racer.site","subject":"Re: how to combine two clones in a collection","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-07-11T19:22:25Z","receivedAt":"2007-07-11T19:22:25Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Thanks, Johannes, for this explanation. I actually had to prod him\non IRC a bit more until I understood, but the result is now\navailable on my blog:\n\n http://blog.madduck.net/vcs/2007.07.11_creating-a-git-branch-without-ancestry\n\n [...]\n Update: Johannes Schindelin taught me how to do the same without\n touching files in .git/:\n\n $ git symbolic-ref HEAD refs/heads/newbranch\n [...]\n\n and also addressed the issue which would have all files already\n committed to the \"master\" branch now appear in the git status\n output as staged.\n\n This is because the index contains the full copy of a revision of\n a file, as it would be if committed at any point. git status shows\n the differences between what has been committed, what would be\n committed, and what is available in the working tree. Since we\n pointed HEAD to nowhere (\"newbranch\" does not yet exist), the\n index and what has been committed (nothing in this case) diverge,\n the files are still staged, and thus are scheduled to be part of\n the impending commit.\n\n The way to fix this is to remove the index:\n\n $ rm .git/index\n\n This may seem weird, but it works, because git recreates the index\n whenever you switch branches:\n\n piper:~> git init-db\n Initialized empty Git repository in .git/\n piper:~> echo 1 > a; git add a; git commit -m.\n Created initial commit e774324: .\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 a\n piper:~> git symbolic-ref HEAD refs/heads/newbranch\n piper:~> rm .git/index\n piper:~> git status\n # On branch newbranch\n #\n # Initial commit\n #\n # Untracked files:\n # (use \"git add ...\" to include in what will be committed)\n #\n # a\n nothing added to commit but untracked files present (use \"git add\" to track)\n piper:~> echo 2 > b; git add b; git commit -m.\n Created initial commit 54ff342: .\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 b\n piper:~> git branch\n master\n * newbranch\n piper:~> git checkout master\n fatal: Untracked working tree file 'a' would be overwritten by merge.\n piper:~> git checkout -f master\n\n Switched to branch \"master\"\n piper:~> git status\n # On branch master\n nothing to commit (working directory clean)\n piper:~> ls\n a\n piper:~> git checkout newbranch\n Switched to branch \"newbranch\"\n piper:~> git status\n # On branch newbranch\n nothing to commit (working directory clean)\n piper:~> ls\n b\n\n As you can see, the creation of the branch is a bit complex, but\n once you (forcefully) switched back to master, you can then\n freely switch between and commit to them.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nspamtraps: madduck.bogus@madduck.net\n \n\"when women love us, they forgive us everything, even our crimes;\n when they do not love us, they give us credit for nothing,\n not even our virtues.\"\n -- honoré de balzac\n"}]}