{"thread":{"id":"8424","subject":"Git Vs. Svn for a project which *must* distribute binaries too.","startedAt":"2007-06-04T11:48:17Z","lastAt":"2007-06-06T22:34:07Z","messageCount":21,"participants":["Bryan Childs","Julian Phillips","Theodore Tso","Johannes Schindelin","Linus Torvalds","Thomas Glanzmann","Olivier Galibert","Martin Langhoff","Joel Becker","Jakub Narebski","Daniel Barkalow","david@lang.hm"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43968","messageId":"5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com","threadId":"8424","inReplyTo":null,"subject":"Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Bryan Childs","fromEmail":"godeater@gmail.com","sentAt":"2007-06-04T11:48:17Z","receivedAt":"2007-06-04T11:48:17Z","isPatch":false,"sender":{"key":"godeater@gmail.com","avatar":"https://gravatar.com/avatar/9a89d9013a02939600457d86d6f5bc9f8718fa23fba71bb4c720f4ae087afc62?d=mp&s=160"},"body":"Hello git users / maintainers / fans,\n\nMy fellow projecteers and I watched a presentation given by Linus\nTorvalds on the advantages of git given at a google questions session\nsometime recently.\n\nOur project, www.rockbox.org, an open source firmware replacement\nproject for digital audio players currently makes use of subversion\nfor it's source code management system, but Linus's eloquent (though\nsometimes rather blunt) speech has made us question whether git is\nperhaps a better solution for us.\n\nOn the whole, we like a lot of the features it offers but, we have a\ncouple of issues which we've discussed, and so far have failed to come\nup with a decent resolution for them.\n\n1) Due to the nature of our project, with multiple architectures\nsupported, we strive to provide a binary build of our software with\nevery commit to the subversion repository. This is so that we can\nprovide a working firmware for the majority of our users that don't\nhave the necessary know-how for cross-compiling and so forth.\n\n2) Unlike the Linux Kernel, which Linus uses as a prime example of\nsomething git is very useful for, the Rockbox project has no central\nfigurehead for anyone to consider as owning the \"master\" repository\nfrom which to build the \"current\" version of the Rockbox firmware for\nany given target.\n\n3) With a central repository, for which we have a limited number of\nindividuals having commit access, it's easy for us to automate a build\nbased on each commit the repository receives.\n\nGiven these three points, we wonder how we'd best achieve the same\nusing git. As far as we can make out we'd need to appoint someone as a\nmaintainer for a master repository whose job it is to co-ordinate\npulls from people based on when they've made changes we wish to\ninclude in the latest version of our software. This sounds like a time\nconsuming role for a project which is only staffed by volunteers.\n\nCan anyone offer any insights for us here?\n\nBryan\n"},{"id":"43970","messageId":"Pine.LNX.4.64.0706041254230.12665@reaper.quantumfyre.co.uk","threadId":"8424","inReplyTo":"5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-06-04T11:56:40Z","receivedAt":"2007-06-04T11:56:40Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Mon, 4 Jun 2007, Bryan Childs wrote:\n\n> 2) Unlike the Linux Kernel, which Linus uses as a prime example of\n> something git is very useful for, the Rockbox project has no central\n> figurehead for anyone to consider as owning the \"master\" repository\n> from which to build the \"current\" version of the Rockbox firmware for\n> any given target.\n>\n> 3) With a central repository, for which we have a limited number of\n> individuals having commit access, it's easy for us to automate a build\n> based on each commit the repository receives.\n>\n> Given these three points, we wonder how we'd best achieve the same\n> using git. As far as we can make out we'd need to appoint someone as a\n> maintainer for a master repository whose job it is to co-ordinate\n> pulls from people based on when they've made changes we wish to\n> include in the latest version of our software. This sounds like a time\n> consuming role for a project which is only staffed by volunteers.\n\nYou can setup git to work in a centralised style if you wish.\n\nSee http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html\n\n-- \nJulian\n\n  ---\nIf reporters don't know that truth is plural, they ought to be lawyers.\n \t\t-- Tom Wicker\n"},{"id":"43974","messageId":"20070604131846.GC20342@thunk.org","threadId":"8424","inReplyTo":"5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-06-04T13:18:47Z","receivedAt":"2007-06-04T13:18:47Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jun 04, 2007 at 12:48:17PM +0100, Bryan Childs wrote:\n> 2) Unlike the Linux Kernel, which Linus uses as a prime example of\n> something git is very useful for, the Rockbox project has no central\n> figurehead for anyone to consider as owning the \"master\" repository\n> from which to build the \"current\" version of the Rockbox firmware for\n> any given target.\n\n> 3) With a central repository, for which we have a limited number of\n> individuals having commit access, it's easy for us to automate a build\n> based on each commit the repository receives.\n\nYou might want to take a look at http://repo.or.cz for an example of\nhow you can have a limited number of trusted inidividuals with commit\naccess.  As has been said before, <SCM> is not a substitute for\ncommunication, and if you have multiple people who can commit into a\nrepository, you had better make sure those trusted individuals with\ncommit access are talking to each other.  \n\nThere are some folks who have created hooks to do more fine-grained\naccess control systems, if you want to replicate SVN's ability to\ncontrol who can commit to which branch.  \n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"43979","messageId":"Pine.LNX.4.64.0706041554430.4046@racer.site","threadId":"8424","inReplyTo":"5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-04T14:58:35Z","receivedAt":"2007-06-04T14:58:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Jun 2007, Bryan Childs wrote:\n\n> 1) Due to the nature of our project, with multiple architectures\n> supported, we strive to provide a binary build of our software with\n> every commit to the subversion repository.\n\nGit has no problems with binaries. Actually, one could argue that it has \nless problems with binary files than with text files, since it only \nrecently acquired the capability (disabled by default) to transcribe \ncertain files into the CR/LF line ending some Windows programs still \ninsist on.\n\nAs for checking in binaries, you even could set up a post-commit hook, \nwhich builds the binary, and checks it into a separate branch...\n\nCiao,\nDscho\n"},{"id":"43981","messageId":"alpine.LFD.0.98.0706040755560.23741@woody.linux-foundation.org","threadId":"8424","inReplyTo":"5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-04T15:20:16Z","receivedAt":"2007-06-04T15:20:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Jun 2007, Bryan Childs wrote:\n> \n> 1) Due to the nature of our project, with multiple architectures\n> supported, we strive to provide a binary build of our software with\n> every commit to the subversion repository. This is so that we can\n> provide a working firmware for the majority of our users that don't\n> have the necessary know-how for cross-compiling and so forth.\n\nGit has no problems with binaries, but I _really_ I hope that you don't \nactually want to check these binaries into the repository? You could do \nthat, and the git delta algorithm might even be able to compress the \nbinaries against each other, but it could still be pretty nasty.\n\nAnd by \"pretty nasty\" I don't mean that git won't be able to handle it: I \nsuspect it's no worse from a disk size perspective than SVN.  But since \ngit is distributed, it means that everybody who fetches it will get the \nwhole archive with whole history - it means that cloning the result is \ngoing to be really painful with tons of old binaries that nobody really \ncares about beign pushed around.\n\nSo I *hope* that you want to just have automated build machinery that \nbuilds the binaries to a *separate* location? You could use git to archive \nthem, and you can obviously (and easily) name the resulting binary blobs \nby the versions in the source tree, but I'm just saying that trying to \ntrack the binaries from within the same git repository as the source code \nis less than optimal.\n\n> 2) Unlike the Linux Kernel, which Linus uses as a prime example of\n> something git is very useful for, the Rockbox project has no central\n> figurehead for anyone to consider as owning the \"master\" repository\n> from which to build the \"current\" version of the Rockbox firmware for\n> any given target.\n\nThe kernel is really kind of odd in that it has just a single maintainer. \nThat's usually the case only for much smaller projects.\n\nAnd no, git is not at all exclusively *designed* for that situation, \nalthough it is arguably one situation that git works really well for. \n\nThere is nothing to say that you cannot have shared repositories that are \nwritably by multiple users. Anything that works for a single person works \nequally well for a \"group of people\" that all write to the same central \ngit repo. It ends up not being how the kernel does things (not because of \ngit, but because it's not how I've ever worked), but the kernel situation \nreally _is_ pretty unusual.\n\nSo git makes everybody have their own repository in order to commit, but \nyou can (and some people do) just view that as your \"CVS working tree\", \nand every time you commit, you end up pushing to some central repository \nthat is writable by the \"core group\" that has commit access.\n\nIn *practice*, I suspect that once you get used to the git model, you'd \nactually end up with a hybrid scheme, where you might have a *smaller* \ncore group with commit access to the central repository (in git, it \nwouldn't be \"commit access\", it would really be \"ability to push\", but \nthat's a technical difference ratehr than anything conceptually huge), and \nmembers in that core group end up pulling from others.\n\nBut that would literally be once you have gotten used to the git model, \nand you can start out just totally emulating the old CVS/SVN model with a \nsingle central repository.\n\n> 3) With a central repository, for which we have a limited number of\n> individuals having commit access, it's easy for us to automate a build\n> based on each commit the repository receives.\n\n.. and that's exactly how you'd do it with git too. You wouldn't have a \n\"commit trigger\", but you'd have a \"receive trigger\", which triggers \nwhenever somebody pushes to the central repository.\n\nAnd that does mean that a developer might do a series of _five_ commits \nlocally on his own machine, and they are totally invisible to everybody \nuntil he pushes to the central repository: and then the build will build \njust the top-most end result commit. So you'd not necessarily have a \nbinary for _each_ commit, but:\n\n - you could (if you really wanted to) actually force people to always \n   send just one commit at a time. You could even enforce that in the \n   pre-receive triggers, so that people *cannot* push multiple commits at \n   a time.\n\n   Quite frankly, I really don't think you want to go this way. I think \n   you want to perhaps _encourage_ people to send just one commit at a \n   time, but the much better model is the other choice:\n\n - realize that the git model tends to encourage many small commits \n   (because you *can* make commits without impacting others), so when you \n   fix something, or add a new feature, with git, you can do it as many \n   small steps, and then only \"push\" when it's ready.\n\n   IOW, if you encourage people to do small step-wise changes, you \n   probably don't even *want* a build for each commit, you really want a \n   build for the case where \"my feature is now ready, I'll push\". So you'd \n   effectively get one build not per commit, but per \"publication point\".\n\nBut anyway, it really boils down to: you *can* use a distributed \ndevelopment model to emulate a totally centralized situation (put another \nway: \"centralized\" is just one very trivial special case of \n\"distributed\"), but I suspect that while you might want to start out \ntrying to change as little as possible in your development model, I \nequally strongly suspect that you'll find out that the distributed nature \nmakes _some_ changes to the model very natural, and you'll end up with \nmore of a hybrid setup: aspects of a centralized model, but with \ndistributed elements.\n\n\t\tLinus\n"},{"id":"43983","messageId":"5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com","threadId":"8424","inReplyTo":"alpine.LFD.0.98.0706040755560.23741@woody.linux-foundation.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Bryan Childs","fromEmail":"godeater@gmail.com","sentAt":"2007-06-04T15:38:59Z","receivedAt":"2007-06-04T15:38:59Z","isPatch":false,"sender":{"key":"godeater@gmail.com","avatar":"https://gravatar.com/avatar/9a89d9013a02939600457d86d6f5bc9f8718fa23fba71bb4c720f4ae087afc62?d=mp&s=160"},"body":"On 6/4/07, Linus Torvalds < [send email to\ntorvalds@linux-foundation.org via gmail]\ntorvalds@linux-foundation.org> wrote:\n> So I *hope* that you want to just have automated build machinery that\n> builds the binaries to a *separate* location? You could use git to archive\n> them, and you can obviously (and easily) name the resulting binary blobs\n> by the versions in the source tree, but I'm just saying that trying to\n> track the binaries from within the same git repository as the source code\n> is less than optimal.\n\nOh lord no - I never meant to imply that we'd be checking those\nbinaries in, I just meant to hi-light that we need a central\nrepository to build those binaries from - otherwise we'd end up with a\nselection of binaries for our users to download which contain a bunch\nof different features if they were built from a combination of\nrepositories. I know you think everyone else is a moron, but we're not\nquite dumb enough to think maintaining binaries in a repository is a\ngood idea :)\n\n\n> In *practice*, I suspect that once you get used to the git model, you'd\n> actually end up with a hybrid scheme, where you might have a *smaller*\n> core group with commit access to the central repository (in git, it\n> wouldn't be \"commit access\", it would really be \"ability to push\", but\n> that's a technical difference rather than anything conceptually huge), and\n> members in that core group end up pulling from others.\n\nThis sounds like what we eventually came up with. I'm not sure how\nsoon we'll make a switch to a git repository, but when we do, this\nseems to be the best model for the conversion in the short term, and\nperhaps in the long term too.\n\n\n> .. and that's exactly how you'd do it with git too. You wouldn't have a\n> \"commit trigger\", but you'd have a \"receive trigger\", which triggers\n> whenever somebody pushes to the central repository.\n\nYes, after I'd sent my email this morning I found you could do pushes\nas well as pulls. That'll teach me to RTFM properly next time.\n\n>  - realize that the git model tends to encourage many small commits\n>    (because you *can* make commits without impacting others), so when you\n>    fix something, or add a new feature, with git, you can do it as many\n>    small steps, and then only \"push\" when it's ready.\n\nThis is what I personally was trying to advocate in our discussion -\nbut I'm not sure everyone quite understood it. Hopefully your\nexplanation will do a better job :)\n\n>    IOW, if you encourage people to do small step-wise changes, you\n>    probably don't even *want* a build for each commit, you really want a\n>    build for the case where \"my feature is now ready, I'll push\". So you'd\n>    effectively get one build not per commit, but per \"publication point\".\n\nAbsolutely.\n\n>                 Linus\n\nThanks for your time (and everyone else who replied) - it's very much\nappreciated!\n\nBryan\n"},{"id":"43989","messageId":"alpine.LFD.0.98.0706040857380.23741@woody.linux-foundation.org","threadId":"8424","inReplyTo":"5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-04T16:23:08Z","receivedAt":"2007-06-04T16:23:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Jun 2007, Bryan Childs wrote:\n> \n> Oh lord no - I never meant to imply that we'd be checking those\n> binaries in, I just meant to hi-light that we need a central\n> repository to build those binaries from\n\nHeh. I get worried (and judging from other responses, I wasn't the only \none) when people start talking about generated binaries and SCM's.\n\nBecause people _have_ traditionally done things like commit the generated \nfiles too. \n\nBut if it's just an automated build server, everything is good. That's \ntrivial to do.\n\n> > In *practice*, I suspect that once you get used to the git model, you'd\n> > actually end up with a hybrid scheme, where you might have a *smaller*\n> > core group with commit access to the central repository (in git, it\n> > wouldn't be \"commit access\", it would really be \"ability to push\", but\n> > that's a technical difference rather than anything conceptually huge), and\n> > members in that core group end up pulling from others.\n> \n> This sounds like what we eventually came up with. I'm not sure how\n> soon we'll make a switch to a git repository, but when we do, this\n> seems to be the best model for the conversion in the short term, and\n> perhaps in the long term too.\n\nYes. As mentioned, the kernel model of having just one person push is \nactually fairly rare. \n\nWhen you have multiple people pushing, you have issues that I never have, \nbut that you've already seen with CVS/SVN, for all the same reasons: you \nmay need to merge the changes that others have done while you were working \non yours.\n\nHowever, the git \"push\" model is *different* from the CVS/SVN \"commit\" \nmodel.\n\nIn CVS/SVN, if you want to commit, and somebody else has done updates to \nthe central repository, the \"cvs commit\" phase will obviously tell you \nthat you're not up-to-date, and you cannot commit at all. So you end up \ndoing a \"cvs update -d\" equivalent to first update your tree, then you \nhave to resolve any conflicts, and then you can try to commit again.\n\nIn git, this is technically very different, yet similar. Since you can \nalways commit to your *local* repository, when you do a \"git commit\", \nyou'll never have any conflicts at all, because there is no conflicting \nwork!\n\nBut the conflicts happen when you then do a \"git push\" to send out your \ncommit(s) to the central repository. If nobody else has done any changes, \nat that point, you'll get exactly the same kind of situation as when you \ndo a CVS commit, and the server will tell you that you're not up-to-date, \nand will refuse to take your push.\n\n(The message is different: git will tell you that you try to push a commit \nthat is not a \"strict superset\" of what the central repository has).\n\nSo when that happens with git, you actually have two different options:\n\n - you can do \"git pull\" to merge the central changes, and in that case \n   you get the exact same kinds of conflict markers for any conflicting \n   code that you would have gotten for \"cvs update\"\n\n   This is how most people would probably use it, and it's the simplest \n   one, where you get very traditional commit conflict markers, fix it up, \n   and commit the merge. \n\n   However, it does end up making the history explicitly showing the \n   parallelism that happened, and while that is *correct* and can be very \n   useful, sometimes it means that especially if you've done just trivial \n   changes, you might want to take an alternate approach that \"linearizes\" \n   the history and makes it appear linear instead of parallel:\n\n - instead of doing a \"git pull\" that merges the two branches (your work, \n   and the work that happened by somebody else in the central repo while \n   you did it), you *may* also just want to do a \"git fetch\" to fetch the \n   changes from the central repo, and then do \"git rebase origin\" to \n   linearize the work you did on _top_ of those central repo one (so that \n   it no longer looks like a branch, and looks linear)\n\n   In the \"git rebase\" case, you'll effectively merge your commits one at \n   a time, and you may thus have to fix up *multiple* conflicts. So it's \n   potentially more work, but it results in a simpler history if you want \n   it.\n\nRegardless of how you ended up sorting out the fact that you had parallel \ndevelopment, once you've resolved it, you do a \"git push\" again, and now \nthe stuff you're pushing is a proper superset of what the central \nrepository had, so it will happily push it out.\n\n(Of course, the exact same thing that can happen with CVS central \nrepositories can happen with git ones too: by the time you've resolved all \nthe differences and are ready to push them to the central one, somebody \nelse might have pushed *more*, and you may need to do another \"update\" ;)\n\n> Yes, after I'd sent my email this morning I found you could do pushes\n> as well as pulls. That'll teach me to RTFM properly next time.\n\nI think we talk a lot more about pulls, because we have had more people \nask about them, and because more people tend to pull than to push.\n\nThe pull is also somewhat easier to explain. The pushing thing always has \nto talk about resolving differences when different people have pushed, so \nteaching people to push by necessity involves first teaching them about \nmerging (ie pull or rebase).\n\nAlso, \"push\" is also a bit more interesting to explain, because a \"push\" \nwon't update the working tree on the other end, so when you explain \npushing, you should also explain about \"bare\" repositories (which I didn't \ndo)), ie about having git repositories without any working tree associated \nwith them.\n\nSo there is a bit of a learning experience involved, but espeically if \nsome of the developers have seen git used in other environments (perhaps \nnot as developers, just as users), it shouldn't be *that* hard to pick up. \nBut there does seem to be a pretty big mental leap from the \"centralized\" \nthing to the \"distributed\" thing - I just moved over so long ago that I \neven have trouble understanding why people sometimes don't seem to find \nthe distributed model the only natural and sane thing to do.\n\n(It really does seem to be one of those \"aha!\" moments. People think \ndistributed just adds a lot of complexity, and it takes a \"Oh, *THAT* is \nhow it works\" kind of enlightenment to just switch your brain over, and I \nguarantee that once that moment on enlightenment hits, you'll never go \nback, but I cannot guarantee that that moment will happen for all \ndevelopers ;)\n\n\t\tLinus\n"},{"id":"43995","messageId":"20070604175751.GL19935@cip.informatik.uni-erlangen.de","threadId":"8424","inReplyTo":"alpine.LFD.0.98.0706040857380.23741@woody.linux-foundation.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Thomas Glanzmann","fromEmail":"thomas@glanzmann.de","sentAt":"2007-06-04T17:57:51Z","receivedAt":"2007-06-04T17:57:51Z","isPatch":false,"sender":{"key":"thomas@glanzmann.de","avatar":null},"body":"Hello,\n\n>  - instead of doing a \"git pull\" that merges the two branches (your work, \n>    and the work that happened by somebody else in the central repo while \n>    you did it), you *may* also just want to do a \"git fetch\" to fetch the \n>    changes from the central repo, and then do \"git rebase origin\" to \n>    linearize the work you did on _top_ of those central repo one (so that \n>    it no longer looks like a branch, and looks linear)\n\n>    In the \"git rebase\" case, you'll effectively merge your commits one at \n>    a time, and you may thus have to fix up *multiple* conflicts. So it's \n>    potentially more work, but it results in a simpler history if you want \n>    it.\n\nThank you a lot. I finally understood what \"git rebase\" is all about!\n\n        Thomas\n"},{"id":"44002","messageId":"alpine.LFD.0.98.0706041336440.23741@woody.linux-foundation.org","threadId":"8424","inReplyTo":"20070604175751.GL19935@cip.informatik.uni-erlangen.de","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-04T20:45:26Z","receivedAt":"2007-06-04T20:45:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Jun 2007, Thomas Glanzmann wrote:\n> \n> >  - instead of doing a \"git pull\" that merges the two branches (your work, \n> >    and the work that happened by somebody else in the central repo while \n> >    you did it), you *may* also just want to do a \"git fetch\" to fetch the \n> >    changes from the central repo, and then do \"git rebase origin\" to \n> >    linearize the work you did on _top_ of those central repo one (so that \n> >    it no longer looks like a branch, and looks linear)\n> > \n> >    In the \"git rebase\" case, you'll effectively merge your commits one at \n> >    a time, and you may thus have to fix up *multiple* conflicts. So it's \n> >    potentially more work, but it results in a simpler history if you want \n> >    it.\n> \n> Thank you a lot. I finally understood what \"git rebase\" is all about!\n\nI'd like to point out some more upsides and downsides of \"git rebase\".\n\nDownsides:\n\n - you're rewriting history, so you MUST NOT have made your pre-rebase \n   changes available publicly anywhere else (or you are in a world of pain \n   with duplicate history and tons of confusion)\n\n - you can only rebase \"simple\" commits. If you don't just have a linear \n   history of your own commits, but have merged from others, rebasing \n   isn't a sane alternative (yeah, we could make it do something half-way \n   sane, but really, it's not worth even contemplating)\n\nUpsides:\n\n - while there may be more conflicts you have to sort out, they may be \n   individually  simpler, so you *might* actually prefer to do it that \n   way.\n\n - if the reason for the conflicts is that upstream did some nice cleanup \n   in the same area, and you decide that you would actually want to re-do \n   your development based on that nice cleanup, then \"git rebase\" can \n   actually be used as a way to help you do exactly that. IOW, you can \n   take _advantage_ of the conflicts as a way to re-apply the patches but \n   also then fix them up by hand to work in the new (better) world order.\n\nAnd finally, the upside that is probably the most common case for using \n\"git rebase\", and has nothing to do with resolving conflicts before \npushing them out with \"git push\":\n\n - if you actually want to send your changes upstream as emailed *patches* \n   rather than by pushing them out (or asking somebody else to pull them),\n   rebasing is an excellent way to keep the set of patches \"fresh\" on top \n   of the current development tree.\n\n   People who send their patches out as emails are also unlikely to have \n   the downsides (ie they normally send them as patches exactly *because* \n   they don't want to make their git trees public, and they probably just \n   have a small set of simple patches in their tree anyway)\n\nSo I have to say, I'm still very ambivalent about rebasing. It's \ndefinitely a very useful thing to do, but at the same time I think \"git \npull\" in many ways is often the more honest and correct way to do things.\n\n\t\tLinus\n"},{"id":"44005","messageId":"20070604212121.GA31852@dspnet.fr.eu.org","threadId":"8424","inReplyTo":"alpine.LFD.0.98.0706041336440.23741@woody.linux-foundation.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2007-06-04T21:21:21Z","receivedAt":"2007-06-04T21:21:21Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:\n> I'd like to point out some more upsides and downsides of \"git rebase\".\n> \n> Downsides:\n> \n>  - you're rewriting history, so you MUST NOT have made your pre-rebase \n>    changes available publicly anywhere else (or you are in a world of pain \n>    with duplicate history and tons of confusion)\n\nWouldn't it be possible to register the rebase somewhere (weak parent?\nsome kind of note not influencing the sha1 ?) that pull/merge could\nfollow?  Rebases and cherry-picking are a special kind of merge, so\nmaybe it can be handled like one where it counts...\n\n  OG.\n"},{"id":"44006","messageId":"alpine.LFD.0.98.0706041429380.23741@woody.linux-foundation.org","threadId":"8424","inReplyTo":"20070604212121.GA31852@dspnet.fr.eu.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-04T21:33:18Z","receivedAt":"2007-06-04T21:33:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Jun 2007, Olivier Galibert wrote:\n\n> On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:\n> > I'd like to point out some more upsides and downsides of \"git rebase\".\n> > \n> > Downsides:\n> > \n> >  - you're rewriting history, so you MUST NOT have made your pre-rebase \n> >    changes available publicly anywhere else (or you are in a world of pain \n> >    with duplicate history and tons of confusion)\n> \n> Wouldn't it be possible to register the rebase somewhere (weak parent?\n> some kind of note not influencing the sha1 ?) that pull/merge could\n> follow?  Rebases and cherry-picking are a special kind of merge, so\n> maybe it can be handled like one where it counts...\n\nWell, it's not like duplicate history is a disaster from a *technical* \nangle. It might be a small space-waster etc, but that's really not the \nreal issue.\n\nThe problem with duplicate history is that it just makes things much \nharder to look at. IOW, it's *messy*. So the \"tons of confusion\" part is \nbasically purely about humans, not about git itself. Git won't really \ncare, and there's no reason to \"handle\" it specially in that sense.\n\nSo I would strongly discourage people from ever making rebased history \navailable, but that's not because of any particular git technical issues \nas just because of it being a good way to confuse all the _humans_ \ninvolved.\n\n(That said, gits own 'pu' branch ends up jumping around, and it hasn't \ncaused all that much confusion, so maybe I'm overstating even that human \nconfusion)\n\n\t\t\tLinus\n"},{"id":"44011","messageId":"46a038f90706041529p224c5d44u32f7a1a358d058f1@mail.gmail.com","threadId":"8424","inReplyTo":"5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-04T22:29:56Z","receivedAt":"2007-06-04T22:29:56Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/5/07, Bryan Childs <godeater@gmail.com> wrote:\n> Oh lord no - I never meant to imply that we'd be checking those\n> binaries in, I just meant to hi-light that we need a central\n> repository to build those binaries from - otherwise we'd end up with a\n\nIf your infrastructure to build the binaries is automated, you can\neasily script the build for new incoming commits. The output of\ngit-describe is really useful for this if you are going to name your\nbuilds `git describe`-<arch>.tar.gz.\n\nOTOH, commit is different from push (vs SVN where both are one op),\nand that means that when using git you can present a large change as a\nbetter-explained patch-series. That's actually a good practice for new\ndevelopment, and it might not make sense to have literally\none-build-per-commit.\n\nMaybe I'd enable auto-builds for maintenance/bugfixes branches, and on\nother (experimental/devel) branches only auto-build commits selected\nexplicitly (tagged?).\n\ncheers,\n\n\nmartin\n"},{"id":"44012","messageId":"20070604223003.GJ6528@ca-server1.us.oracle.com","threadId":"8424","inReplyTo":"alpine.LFD.0.98.0706041429380.23741@woody.linux-foundation.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2007-06-04T22:30:03Z","receivedAt":"2007-06-04T22:30:03Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Mon, Jun 04, 2007 at 02:33:18PM -0700, Linus Torvalds wrote:\n> (That said, gits own 'pu' branch ends up jumping around, and it hasn't \n> caused all that much confusion, so maybe I'm overstating even that human \n> confusion)\n\n\tIt survives because it is well-known.  Everyone expects it to\nbreak.  ocfs2 has an \"ALL\" branch that is everything we have working,\nsort of a \"test this bleeding edge\" thing.  It gets rebased all the\ntime, and everyone knows that they can't trust it to update linearly.\nOther developers have similar things in their repositories.\n\nJoel\n\n-- \n\n\"What no boss of a programmer can ever understand is that a programmer\n is working when he's staring out of the window\"\n\t- With apologies to Burton Rascoe\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"44015","messageId":"f427ur$ohs$1@sea.gmane.org","threadId":"8424","inReplyTo":"5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-06-04T23:46:39Z","receivedAt":"2007-06-04T23:46:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Bryan Childs wrote:\n\n> 3) With a central repository, for which we have a limited number of\n> individuals having commit access, it's easy for us to automate a build\n> based on each commit the repository receives.\n\nCheck out contrib/continuous/ scripts in git repository: you would have\nto enable it only on one machine, of course.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"44016","messageId":"Pine.LNX.4.64.0706041923580.22840@iabervon.org","threadId":"8424","inReplyTo":"5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-04T23:48:54Z","receivedAt":"2007-06-04T23:48:54Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 4 Jun 2007, Bryan Childs wrote:\n\n> On 6/4/07, Linus Torvalds < [send email to\n> torvalds@linux-foundation.org via gmail]\n> torvalds@linux-foundation.org> wrote:\n> > So I *hope* that you want to just have automated build machinery that\n> > builds the binaries to a *separate* location? You could use git to archive\n> > them, and you can obviously (and easily) name the resulting binary blobs\n> > by the versions in the source tree, but I'm just saying that trying to\n> > track the binaries from within the same git repository as the source code\n> > is less than optimal.\n> \n> Oh lord no - I never meant to imply that we'd be checking those\n> binaries in, I just meant to hi-light that we need a central\n> repository to build those binaries from - otherwise we'd end up with a\n> selection of binaries for our users to download which contain a bunch\n> of different features if they were built from a combination of\n> repositories. I know you think everyone else is a moron, but we're not\n> quite dumb enough to think maintaining binaries in a repository is a\n> good idea :)\n\nActually, I've been playing with using git's data-distribution mechanism \nto distribute generated binaries. You can do tags for arbitrary binary \ncontent (not in a tree or commit), and, if you have some way of finding \nthe right tag name, you can fetch that and extract it.\n\nI came up with this at my job when we were trying to decide what to do \nwith firmware images that we'd shipped, so that we'd be able to examine \nthem again even if we lose the compiler version we used at the time. We \nneeded an immutable data store with a mapping of tags to objects, and I \nrealized that we already had something with these exact characteristics.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"44019","messageId":"alpine.LFD.0.98.0706041715500.23741@woody.linux-foundation.org","threadId":"8424","inReplyTo":"Pine.LNX.4.64.0706041923580.22840@iabervon.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-05T00:21:20Z","receivedAt":"2007-06-05T00:21:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Jun 2007, Daniel Barkalow wrote:\n> \n> Actually, I've been playing with using git's data-distribution mechanism \n> to distribute generated binaries. You can do tags for arbitrary binary \n> content (not in a tree or commit), and, if you have some way of finding \n> the right tag name, you can fetch that and extract it.\n\nYes, I think git should be very nice for doing binary stuff like firmware \nimages too, my only worry is literally about \"mixing it in\" with other \nstuff.\n\nPutting lots of binary blobs into a git archive should work fine: but \nif you would then start tying them together (with a commit chain), it just \nmeans that even if you only really want _one_ of them, you end up getting \nthem all, which sounds like a potential disaster.\n\nOn the other hand, if you actually want a way to really *archive* the dang \nthings, that may well be what you actually want. In that case, having a \nseparate branch that only contains the binary stuff might actually be what \nyou want to do (and depending on the kind of binary data you have, the \ndelta algorithm might even be good at finding common data sequences and \ncompressing it).\n\n> I came up with this at my job when we were trying to decide what to do \n> with firmware images that we'd shipped, so that we'd be able to examine \n> them again even if we lose the compiler version we used at the time. We \n> needed an immutable data store with a mapping of tags to objects, and I \n> realized that we already had something with these exact characteristics.\n\nYeah, if you just tag individual blobs, git will keep track of them, but \nwon't link them together, so you can easily just look up and fetch a \nsingle one from such an archive. Sounds sane enough.\n\n\t\tLinus\n"},{"id":"44020","messageId":"Pine.LNX.4.64.0706041841010.6705@asgard.lang.hm","threadId":"8424","inReplyTo":"alpine.LFD.0.98.0706041715500.23741@woody.linux-foundation.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-06-05T01:42:02Z","receivedAt":"2007-06-05T01:42:02Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 4 Jun 2007, Linus Torvalds wrote:\n\n> On Mon, 4 Jun 2007, Daniel Barkalow wrote:\n>>\n>> Actually, I've been playing with using git's data-distribution mechanism\n>> to distribute generated binaries. You can do tags for arbitrary binary\n>> content (not in a tree or commit), and, if you have some way of finding\n>> the right tag name, you can fetch that and extract it.\n>\n> Yes, I think git should be very nice for doing binary stuff like firmware\n> images too, my only worry is literally about \"mixing it in\" with other\n> stuff.\n>\n> Putting lots of binary blobs into a git archive should work fine: but\n> if you would then start tying them together (with a commit chain), it just\n> means that even if you only really want _one_ of them, you end up getting\n> them all, which sounds like a potential disaster.\n\nif you put the binaries in a seperate repository and do shallow clones to \navoid getting all the old stuff wouldn't that work well?\n\nDavid Lang\n\n> On the other hand, if you actually want a way to really *archive* the dang\n> things, that may well be what you actually want. In that case, having a\n> separate branch that only contains the binary stuff might actually be what\n> you want to do (and depending on the kind of binary data you have, the\n> delta algorithm might even be good at finding common data sequences and\n> compressing it).\n>\n>> I came up with this at my job when we were trying to decide what to do\n>> with firmware images that we'd shipped, so that we'd be able to examine\n>> them again even if we lose the compiler version we used at the time. We\n>> needed an immutable data store with a mapping of tags to objects, and I\n>> realized that we already had something with these exact characteristics.\n>\n> Yeah, if you just tag individual blobs, git will keep track of them, but\n> won't link them together, so you can easily just look up and fetch a\n> single one from such an archive. Sounds sane enough.\n>\n> \t\tLinus\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"44025","messageId":"Pine.LNX.4.64.0706050345250.4046@racer.site","threadId":"8424","inReplyTo":"20070604212121.GA31852@dspnet.fr.eu.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-05T02:56:27Z","receivedAt":"2007-06-05T02:56:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Jun 2007, Olivier Galibert wrote:\n\n> On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:\n>\n> > I'd like to point out some more upsides and downsides of \"git rebase\".\n> > \n> > Downsides:\n> > \n> >  - you're rewriting history, so you MUST NOT have made your pre-rebase \n> >    changes available publicly anywhere else (or you are in a world of \n> >    pain with duplicate history and tons of confusion)\n> \n> Wouldn't it be possible to register the rebase somewhere (weak parent? \n> some kind of note not influencing the sha1 ?) that pull/merge could \n> follow?\n\nActually, with reflogs (if you did not explicitely disable them), you \nshould have the information already.\n\n> Rebases and cherry-picking are a special kind of merge, so maybe it can \n> be handled like one where it counts...\n\nThere is something I have to add as a real disadvantage in rebase:\n\nUsually you are expected to test your commits. So, say that you work on \nsome patch series, and produce 3 well tested patches. Then you fetch \nupstream and realize it advanced by some commits, and rebase your three \npatches.\n\nHowever, _none_ of your patches is well tested, because there is a quite \nreal chance that your patches interact _badly_ with the patches you just \nfetched.\n\nAnd if that is the case, git-bisect can very well attribute it to a wrong \npatch, either because more than one patch is bad, or because the last \npatch in your series _exposes_ the bug (but does not _introduce_ it).\n\nCiao,\nDscho\n"},{"id":"44027","messageId":"alpine.LFD.0.98.0706042057530.23741@woody.linux-foundation.org","threadId":"8424","inReplyTo":"Pine.LNX.4.64.0706041841010.6705@asgard.lang.hm","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-05T03:58:55Z","receivedAt":"2007-06-05T03:58:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Jun 2007, david@lang.hm wrote:\n> \n> if you put the binaries in a seperate repository and do shallow clones to\n> avoid getting all the old stuff wouldn't that work well?\n\nYes. I'm not a huge fan of shallow clones, and I suspect they've not \ngotten all that much testing, but that would certainly solve the problem \nof getting unnecessarily much data..\n\n\t\tLinus\n"},{"id":"44068","messageId":"20070605111904.GA12755@thunk.org","threadId":"8424","inReplyTo":"20070604223003.GJ6528@ca-server1.us.oracle.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-06-05T11:19:04Z","receivedAt":"2007-06-05T11:19:04Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jun 04, 2007 at 03:30:03PM -0700, Joel Becker wrote:\n> \tIt survives because it is well-known.  Everyone expects it to\n> break.  ocfs2 has an \"ALL\" branch that is everything we have working,\n> sort of a \"test this bleeding edge\" thing.  It gets rebased all the\n> time, and everyone knows that they can't trust it to update linearly.\n> Other developers have similar things in their repositories.\n\nI wonder if it would be useful to be able to be able to flag a\nbranches as \"jumping around a lot\", where this flag would be\ndownloaded from another repository when it is cloned, so that a naive\nuser could get some kind of warning before committing a patch on top\nof one of these branches that is known jump around.  \n\n\t\"This branch gets rebased all the time and is really meant for\n\ttesting.  If you really want to commit this changeset, please\n\tconfigure yourself for expert mode or use the --force.\"\n\nOr maybe just a warning, ala what we do with detached heads.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"44203","messageId":"f47cen$hms$1@sea.gmane.org","threadId":"8424","inReplyTo":"f427ur$ohs$1@sea.gmane.org","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-06-06T22:34:07Z","receivedAt":"2007-06-06T22:34:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Bryan Childs wrote:\n> \n>> 3) With a central repository, for which we have a limited number of\n>> individuals having commit access, it's easy for us to automate a build\n>> based on each commit the repository receives.\n> \n> Check out contrib/continuous/ scripts in git repository: you would have\n> to enable it only on one machine, of course.\n\nYou can also use something similar to dodoc.sh script in 'todo' branch of\ngit repository, which script makes some build results and saves them in\n_separate_ branch of repository.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}