{"thread":{"id":"2279","subject":"git versus CVS (versus bk)","startedAt":"2005-10-31T01:50:49Z","lastAt":"2005-11-10T16:20:03Z","messageCount":61,"participants":["walt","Martin Langhoff","H. Peter Anvin","Linus Torvalds","Johannes Schindelin","wa1ter@myrealbox.com","Randal L. Schwartz","Joel Becker","Junio C Hamano","Daniel Barkalow","Theodore Ts'o","Petr Baudis","Catalin Marinas","Chris Mason","Chuck Lever","Josef Weidendorfer","Pavel Machek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10836","messageId":"Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg","threadId":"2279","inReplyTo":null,"subject":"git versus CVS (versus bk)","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-10-31T01:50:49Z","receivedAt":"2005-10-31T01:50:49Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"My memory is playing tricks on me. I seem to remember running linux\nin the 1980's, but the earliest kernel I can find on kernel.org is\ndated 1994. Maybe I'm remembering xenix...dunno.\n\nAnyway, I've been tracking Linus's kernel for many years -- long\nbefore bitkeeper or git.\n\nI know just enough to compile and run a kernel, but not enough to\nbe a software developer. And that is where my question comes from:\n\nCould someone explain to me the shortcomings of CVS which prompted\nthe development of bk (and then git) -- in a way that a non-developer\nlike me can understand? Pretend that you are Albert Einstein, trying\nto explain your theories to a ten-year-old -- this is always a useful\nexercise for those of you who are drowning in micro-details!\n\nI've already done some googling on this subject, but everything I've\nfound is drenched in those micro-details which make the subject\nopaque to me.\n\nThanks for any pointers!\n"},{"id":"10837","messageId":"46a038f90510301759p26fa4b0wd67025f069c2373a@mail.gmail.com","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg","subject":"Re: git versus CVS (versus bk)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-31T01:59:41Z","receivedAt":"2005-10-31T01:59:41Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/31/05, walt wrote:\n> Could someone explain to me the shortcomings of CVS which prompted\n> the development of bk (and then git) -- in a way that a non-developer\n> like me can understand?\n\nYou need to understand the SCM \"problem space\" at least a little bit.\nCan't cheat on that unfortunately.\n\nThe writeup at http://www.dwheeler.com/essays/scm.html is not perfect,\nbut should give you a bit of background. It barely covers git -- we\nneed to prod the author to update it ;)\n\n\n\nmartin\n"},{"id":"10838","messageId":"43657B5E.6020200@zytor.com","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg","subject":"Re: git versus CVS (versus bk)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-31T02:03:10Z","receivedAt":"2005-10-31T02:03:10Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"walt wrote:\n> My memory is playing tricks on me. I seem to remember running linux\n> in the 1980's, but the earliest kernel I can find on kernel.org is\n> dated 1994. Maybe I'm remembering xenix...dunno.\n\nThe very first version of Linux came out in 1991.\n\n\t-hpa\n"},{"id":"10839","messageId":"Pine.LNX.4.64.0510301811390.27915@g5.osdl.org","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510301720390.14972@x2.ybpnyarg","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T02:35:08Z","receivedAt":"2005-10-31T02:35:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 30 Oct 2005, walt wrote:\n>\n> My memory is playing tricks on me. I seem to remember running linux\n> in the 1980's, but the earliest kernel I can find on kernel.org is\n> dated 1994. Maybe I'm remembering xenix...dunno.\n\n-91 was the first version. It was usable (depending on your definition of \n\"usable\" ;) in early -92.\n\n> Could someone explain to me the shortcomings of CVS which prompted\n> the development of bk (and then git) -- in a way that a non-developer\n> like me can understand?\n\nIt's really not very easy to explain why CVS sucks. After all, sometimes \npeople who have used it for decades have a hard time understanding the \nsuckiness.\n\nI've used CVS for \"real work\" at Transmeta, and hey, it worked well \nenough. When you have groups of just a couple of tens of people max, and \nvery strict rules on how to do things, and you trust everybody, CVS works \nfine. It starts to really show its problems whenever you need to work \nremotely, but there are things you can do to make the pain less.\n\nA lot of CVS people will tell you that it sucks because it can't do \nrenames, and because certain operations take forever (tagging etc). That's \nonly superficially true, and it is really a suckiness that comes from some \nimplementation issues.\n\nSVN fixes (supposedly) those \"implementation suckiness\" issues. It does so \nlargely by doing a much better database, which allows it to do certain \nthings much more efficiently. Personally that part scares me, since I \nthink it's also a much more fragile setup and there's apparently been \npeople who lost their entire database to corruption (something that is \nvery hard to do with CVS, since the \"database\" is so weak), but that's a \ndifferent issue.\n\nBut the things that SVN fixes are not the things that really matter in the \nend. SVN i sa better CVS, but it still has all the basic fundamental \nproblems. Namely the fact that it's centralized.\n\nThe problem with a centralized model is that there's one point of contact: \nyou can replicate the central database endlessly, but you can only really \nmodify it in one place. Which means that anybody who wants to modify \nanything at all needs to have write access to that one repository.\n\nNow, you can limit write access in various ways (\"user xyz can only write \nto these files\"), but it still requires an a-priori trust network rather \nthan a dynamic one. So every single CVS project (and SVN does zero in this \nregard) always ends up having politics around the question of who gets \ncommit privileges, and what the rules for them are.\n\nSo one of the worst downsides of CVS is _politics_. People, not \ntechnology.\n\nThe other implication of centralization is the fact that it means that you \ncan't do any off-line work. You need to be able to access the central \ndatabase in order to do real work. You can replicate the repository and \ntry to take it with you and then back-port whatever changes you did when \nyou come back, but more commonly it means that when you go off with a \nlaptop, you're either in read-only mode, or you need to have an internet \nconnection whenever you want to do development. That's just nasty.\n\nThe upside of centralization is that a lot of things are easier. Easier to \nthink about, easier to get a stupid and straightforward idea working. \n\nBut if you have hundreds of developers, and you have a dynamic trust \nnetwork (I trust some people, they trust others, and we all tend to trust \npeople more or less depending on what they work on), the CVS model is \nabsolutely HORRID. It just doesn't work.\n\nGit does all of that right. So did BK, for that matter. There's no \na-priori \"these people can commit\", because there's no central database. \nThere's no problem with off-line work, because every repository is totally \nself-contained and independent of every other one.\n\n\t\t\tLinus\n"},{"id":"10849","messageId":"Pine.LNX.4.63.0510311111340.2916@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510301811390.27915@g5.osdl.org","subject":"Re: git versus CVS (versus bk)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-31T10:24:11Z","receivedAt":"2005-10-31T10:24:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 30 Oct 2005, Linus Torvalds wrote:\n\n> It's really not very easy to explain why CVS sucks. After all, sometimes \n> people who have used it for decades have a hard time understanding the \n> suckiness.\n>\n> [...]\n\nHow about adding the whole explanation as\n\n\tgit/Documentation/howto/tell-why-cvs-sucks.txt\n\n(maybe with some more polite name)?\n\nAlso, I´d like to add that CVS branching/merging is no good:\n\n\n\nSometimes a developer gets an idea, or the need, to implement a certain \nfeature to a piece of free software. Now, this idea might seem good, but \nit might take a while to\n\n\t- implement it,\n\t- flesh the bugs out, and\n\t- maybe realize the idea was not all that good.\n\nAll the while, the project is prospering, and you have to keep up-to-date. \nWith CVS, you would do \"cvs update\" every once in a while, and clean up \nthe merge conflicts. In effect, you would track the history of the \nupstream project.\n\nOften, however, you would like to track *your* changes, too. This is not \npossible in CVS. You just can´t track two different histories in the same \nworking directory.\n\nNow, if you are working on two or more different ideas, which you want to \ntest separately *and* together, you need to merge your local branches \nevery once in a while. If it weren´t for \"every once in a while\", but \n\"once\", you still could do it in CVS. If you want to merge several times \n(keeping the separate development branches), you can´t.\n\n\n\nCiao,\nDscho\n"},{"id":"10850","messageId":"Pine.LNX.4.64.0510310450230.10881@x2.ybpnyarg","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510301811390.27915@g5.osdl.org","subject":"Re: git versus CVS (versus bk)","fromName":"","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-10-31T13:00:40Z","receivedAt":"2005-10-31T13:00:40Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"\n\nOn Sun, 30 Oct 2005, Linus Torvalds wrote:\n\n> On Sun, 30 Oct 2005, walt wrote:\n\n> > Could someone explain to me the shortcomings of CVS which prompted\n> > the development of bk (and then git) -- in a way that a non-developer\n> > like me can understand?\n\n> It's really not very easy to explain...\n\n\n\nBut you explained very well, thank you! And thanks to the others who\nresponded -- all very helpful. I'm off to read the link that Martin\nsupplied -- looks gossipy enough to keep me awake :o)\n"},{"id":"10855","messageId":"Pine.LNX.4.64.0510310804400.27915@g5.osdl.org","threadId":"2279","inReplyTo":"Pine.LNX.4.63.0510311111340.2916@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T16:18:49Z","receivedAt":"2005-10-31T16:18:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Johannes Schindelin wrote:\n> \n> How about adding the whole explanation as\n> \n> \tgit/Documentation/howto/tell-why-cvs-sucks.txt\n> \n> (maybe with some more polite name)?\n\nHey, if somebody else does it, that's fine.\n\nI'm personally _so_ biased against CVS that I'm not neutral. I really hate \nthe thing. I'd much rather use tar-balls and patches than CVS: I think \n\"quilt\" ends up being much nicer in many ways than CVS can be.\n\nSo feel free to take my explanations and write something up. I just don't \nwant to do it, because I fear I might be unfair to CVS (well.. I'm \npersonally 120% convinced I'm not, but still, there's a lot of people who \nactually _use_ it, so..).\n\n> Also, I´d like to add that CVS branching/merging is no good:\n> \n> \n> \n> Sometimes a developer gets an idea, or the need, to implement a certain \n> feature to a piece of free software. Now, this idea might seem good, but \n> it might take a while to\n> \n> \t- implement it,\n> \t- flesh the bugs out, and\n> \t- maybe realize the idea was not all that good.\n\n[ details deleted ]\n\nYes. I consider this to be part of the centralized/distributed issue, but \nit's worth talking about. A distributed system automatically implies that \nyou can have \"throw-away branches\" for testing, and you can combine two or \nmore of these test-branches without ever disturbing (or even _notifying_) \nthe \"real development\" branch.\n\nIn a centralized system, any branches will always be in that central \nrepository, so you can't do throw-away stuff without affecting everybody \nelse. Maybe the actual _code_ won't be in the \"real development\" branch, \nbut you're writing and affecting the same repository where the development \nhappens.\n\nAgain, you could replicate the whole repo, and do things there, but then \nyou can't ever merge again, which in effect makes the small branch a big \nfork. So in that sense the CVS/SVN mentality basically encourages forking \nand discourages working together. This is more of the same thing that I \nalluded to when saying that CVS inevitably leads to \"politics\" - having a \ncentral place means that you have people who fight for control over it, \neven when they'd otherwise _want_ to cooperate.\n\nWith git (or with BK, or any truly decentralized model), you just make \nyour own repo, do your development there, and you never need to ask for \npermissions from the central repo people. If the development works out, \nyou just ask people to merge back. And if it doesn't, you don't even have \nto tell people what a total failure you were.\n\nSo with the distributed model, you don't have to publicly humiliate \nyourself when you do something stupid. Similarly, you don't have to \npublicly prove that you're \"good enough\" before you can play in the \nsandbox. In other words, there's no need for politics and egos.\n\n(Now, obviously, when you've actually done the work, if people recognize \nthat you're a mental giant, they'll be more likely to merge with you, and \nyou'll generally have an easier time. So I'm not saying that a distributed \nmodel takes away the need for showing how good you are, but it doesn't \nmake that a central pre-conception).\n\n\t\t\tLinus"},{"id":"10861","messageId":"Pine.LNX.4.64.0510311013200.11219@x2.ybpnyarg","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510310804400.27915@g5.osdl.org","subject":"Re: git versus CVS (versus bk)","fromName":"","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-10-31T18:18:03Z","receivedAt":"2005-10-31T18:18:03Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"\n\nOn Mon, 31 Oct 2005, Linus Torvalds wrote:\n\n> ...CVS inevitably leads to \"politics\" - having a\n> central place means that you have people who fight for control over it,\n> even when they'd otherwise _want_ to cooperate...\n\nAhh -- the lightbulb just lit up. Using CVS is just like being married.\nNo wonder you hate it...\n"},{"id":"10869","messageId":"867jbtii85.fsf@blue.stonehenge.com","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510311013200.11219@x2.ybpnyarg","subject":"Re: git versus CVS (versus bk)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2005-10-31T19:44:58Z","receivedAt":"2005-10-31T19:44:58Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"wa1ter\" == wa1ter writes:\n\nwa1ter> Ahh -- the lightbulb just lit up. Using CVS is just like\nwa1ter> being married. No wonder you hate it...\n\nNow, hey hey. I've met Tove. She's very nice. I doubt that Linus\nwould compare his marriage to her with CVS. :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"10870","messageId":"20051031195010.GM11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510310804400.27915@g5.osdl.org","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-10-31T19:50:10Z","receivedAt":"2005-10-31T19:50:10Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Mon, Oct 31, 2005 at 08:18:49AM -0800, Linus Torvalds wrote:\n> With git (or with BK, or any truly decentralized model), you just make \n> your own repo, do your development there, and you never need to ask for \n> permissions from the central repo people. If the development works out, \n> you just ask people to merge back. And if it doesn't, you don't even have \n> to tell people what a total failure you were.\n\n\tActually, Linus, this provokes a question I've always wanted the\nanswer to. I'm well aware of the centralized/distributed stuff you are\ndiscussing, but there is policy regarding the distributed merges I've\nnever been quite clear on.\n\tWhen one does a feature branch, one creates a \"throw-away\"\nrepository. They work on the feature, and when they are done, they\npull/push back to the main repository. This pattern is pretty much\nidentical in both centralized in distributed environments, even if the\nnuts-and-bolts are different.\n\tIn the CVS/Subversion world, this merge becomes a single commit\non the \"main\" line of development (\"trunk\", or whatever you call it).\nThe merge has no concept of the steps taken to create the change, just\nthe actual patch. This has the disadvantage that you have to work hard\nin the branch namespace to find the actual steps taken (the working\nrepository for the feature), but the advantage that a quick look does\nnot have to wade through fits and starts as the feature takes shape.\n\tIn the distributed world, a pull of the \"feature\" repository\npulls in all changes - the full history of the work. This includes\naborted tries, rewritten pieces, bug fixes, etc. Here, the main\nrepository has the detritus of the development process, but that also\ncontains the full context of the work. It goes against your claim that:\n\n> So with the distributed model, you don't have to publicly humiliate \n> yourself when you do something stupid. Similarly, you don't have to \n\nbecause that history will contain all your something stupids, plus your\nfixes for them.\n\tBut that's not how the kernel and git appear to work. Many\ndevelopers have popularized dropping that context. They take their\nworking repository, diff it against your mainline repository, and then\ncreate a new repository that is merely your mainline plus one commit,\nthe patch of their changes.\n\tThis violently breaks the model of \"work in a new repository,\nthen have it pulled into the 'main' repository.\" It has no real support\nin the git/cogito command space (that I know of). It does, however,\nleave all the intermediate commits out of your tree, with only a feature\ncommit remaining.\n\tWhere do you stand on this? Would you rather see the full\nhistory pulled? Do you prefer the one-clean-patch approach? If so, is\nthere any way to get a cogito/git command for it (git-pull-as-one?)?\n\nJoel\n\n-- \n\n\"Drake! We're LEAVING!\"\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10873","messageId":"46a038f90510311228v50743158q80d79e963bd503ce@mail.gmail.com","threadId":"2279","inReplyTo":"20051031195010.GM11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-31T20:28:30Z","receivedAt":"2005-10-31T20:28:30Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/1/05, Joel Becker wrote:\n> Where do you stand on this? Would you rather see the full\n> history pulled? Do you prefer the one-clean-patch approach? If so, is\n> there any way to get a cogito/git command for it (git-pull-as-one?)?\n\nYou can do a diff that spans all the commits and apply it with a new\ncommit msg. With cogito:\n\n cg-diff -r from:to | patch -p1\n\nWith git you can also do it directly within the repo/index with\n\n git-read-tree -m from HEAD to\n\nIn practice, a new developer will often roll up commits to avoid\nsending a string of shameful patches and corrections on top -- I often\ndo that ;-) . Developers with more \"mana\" will have published repos\nwhere Junio pulls directly from -- and they get merged with full\nhistory. Of course -- they don't have brown-paper-bag commits like I\ndo...\n\nSounds like a reasonable, organic/dynamic way of doing it.\n\ncheers,\n\n\nmartin\n"},{"id":"10879","messageId":"7vr7a1e719.fsf@assigned-by-dhcp.cox.net","threadId":"2279","inReplyTo":"20051031195010.GM11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T21:00:18Z","receivedAt":"2005-10-31T21:00:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joel Becker writes:\n\n> \tIn the distributed world, a pull of the \"feature\" repository\n> pulls in all changes - the full history of the work. This includes\n> aborted tries, rewritten pieces, bug fixes, etc. Here, the main\n> repository has the detritus of the development process, but that also\n> contains the full context of the work. It goes against your claim that:\n>\n>> So with the distributed model, you don't have to publicly humiliate \n>> yourself when you do something stupid. Similarly, you don't have to \n>\n> because that history will contain all your something stupids, plus your\n> fixes for them.\n\nDo you think anybody is that perfect?\n\nWhat happens in reality is something like this:\n\n - you have a master tree, and your own throwaway topic\n branches.\n\n - you play in your own topic branches. you make stupid\n mistakes and redo your changes many times.\n\n - when the tips of your topic branches are in good shape, you\n review the changes from the master tree as a whole, without\n the history.\n\n - you decompose the diff between the tips of your topic branch\n and the master branch into logical steps.\n\n - you branch off \"sanitized\" branches from the tip of the\n master, and apply the decomposed diffs, making one commit per\n logical change, until all your decomposed diffs are applied.\n\n - after making sure that the tips of the sanitized branches\n match the tips of their corresponding topic branch you did\n your work on, you throw away your true history and pretend\n you are perfect human. Either ask your peer to pull from\n your sanitized branch tips, or run git-format-patch between\n the master and the sanitized branch tips and send them out as\n patches.\n\nI do not know about the kernel tree but I would be surprised if\nany self-respecting developer wouldn't be doing this. The\nreview-decomposition-reapplication cycle is *very* important for\nboth keeping the public history clean and reviewable, and\npreservign your public image ;-).\n"},{"id":"10881","messageId":"20051031213003.GN11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"46a038f90510311228v50743158q80d79e963bd503ce@mail.gmail.com","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-10-31T21:30:03Z","receivedAt":"2005-10-31T21:30:03Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 09:28:30AM +1300, Martin Langhoff wrote:\n> You can do a diff that spans all the commits and apply it with a new\n> commit msg. With cogito:\n> \n> cg-diff -r from:to | patch -p1\n\n\tI'm well aware of this, my question was rather one of\napplicability. First, do we want it to work this way, losing the\nhistory. Second, you'd like the process to be all encompasing if you go\nthis route.\n\n ((cd old-repo && cg-diff -r from) | patch -p1) && cg-commit\n\nor any equivalent. Why should I have to muck with patch and diff, when\nI can have a 'pull-as-one' operation. Sure, it's a wrapper, but if its\nthe intended mode of development, let's make it a first-class citizen.\n\nJoel\n\n-- \n\nLife's Little Instruction Book #157 \n\n\t\"Take time to smell the roses.\"\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10883","messageId":"Pine.LNX.4.64.0510311323090.27915@g5.osdl.org","threadId":"2279","inReplyTo":"20051031195010.GM11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T21:35:39Z","receivedAt":"2005-10-31T21:35:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Joel Becker wrote:\n> \n> \tIn the CVS/Subversion world, this merge becomes a single commit\n> on the \"main\" line of development (\"trunk\", or whatever you call it).\n> The merge has no concept of the steps taken to create the change, just\n> the actual patch. This has the disadvantage that you have to work hard\n> in the branch namespace to find the actual steps taken (the working\n> repository for the feature), but the advantage that a quick look does\n> not have to wade through fits and starts as the feature takes shape.\n\nNote that I'm a big proponent of people cleaning up their private \nwork-in-progress trees before merging.\n\nIn fact, I'll refuse to merge with too dirty a repository. It's ok to have \nsome fixes for mistakes, but if you have a lot of ugly stuff, use git to \nfirst track the development, and then start a new branch that has the \ncleaned-up version in it.\n\n> > So with the distributed model, you don't have to publicly humiliate \n> > yourself when you do something stupid. Similarly, you don't have to \n> \n> because that history will contain all your something stupids, plus your\n> fixes for them.\n\nNo, exactly because you do _not_ have to publicly humiliate yourself with \nshowing what a nincompoop you are.\n\nPeople should try things out, but they should clean up their worst \nmistakes too. Git allows both.\n\n\t\tLinus\n"},{"id":"10884","messageId":"20051031213616.GO11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"7vr7a1e719.fsf@assigned-by-dhcp.cox.net","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-10-31T21:36:16Z","receivedAt":"2005-10-31T21:36:16Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Mon, Oct 31, 2005 at 01:00:18PM -0800, Junio C Hamano wrote:\n> Do you think anybody is that perfect?\n\n\tI was being slightly facetious. Of course everyone makes\nmistakes and corrects them. But if you _want_ the history, you have to\ntake it. Otherwise, you are required to throw away the history\ncompletely. And that -- do you want the whole history or none of it --\nis the crux of my question.\n\n> What happens in reality is something like this:\n\n[ understood work model snipped ]\n\n> I do not know about the kernel tree but I would be surprised if\n> any self-respecting developer wouldn't be doing this. The\n> review-decomposition-reapplication cycle is *very* important for\n> both keeping the public history clean and reviewable, and\n> preservign your public image ;-).\n\n\tI could care less about preserving my public image. I'm an\nidiot, I screw up all the time. I only care that the tip of my tree is\nrespectable.\n\tI've seen arguments from folks on both sides -- the intermediate\nhistory is important, warts and all, vs throw it all out for a clean\npublic history. It seems that you fall into the second camp.\n\tThat's fine, but can we make that work model a first-class\ncitizen? Can we get a script that pulls one branch as a single,\nun-historied (sic) commit into the current branch? If this is The Way,\nI should have to be mucking about with many steps of diff/patch (at\nleast unless my change is large enough to require split patches).\n\nJoel\n \n\n-- \n\n\"It is not the function of our government to keep the citizen from\n falling into error; it is the function of the citizen to keep the\n government from falling into error.\"\n\t- Robert H. Jackson\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10886","messageId":"Pine.LNX.4.64.0510311346110.27915@g5.osdl.org","threadId":"2279","inReplyTo":"20051031213616.GO11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T21:53:21Z","receivedAt":"2005-10-31T21:53:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Joel Becker wrote:\n> \n> \tI could care less about preserving my public image. I'm an\n> idiot, I screw up all the time. I only care that the tip of my tree is\n> respectable.\n\nI definitely care about more than just the tip.\n\nA broken history is a _problem_. Automatic tools like \"git bisect\" can't \nhelp you if you have lots of commits in between that are fundamentally \nbroken. And even ignoring that, it just makes it harder for everybody to \nunderstand what the code does when \"git-whatchanged\" shows total crap that \nwas undone.\n\nHistory is important. It's important enough that you should keep it \nmeaningful. And \"meaningful\" does not mean \"show all your mistakes\". \n\nSome people will say that the mistakes are as important as the fixes. I \ncall bull on that. Mistakes are mistakes. Dead ends aren't useful, even as \nhistorical examples. \n\nAt the same time, I'm not a rabid \"history must be perfect\" freak. \nMistakes happen. Just fix then and move on.\n\nWhen you have guests over, I sure hope that you don't walk around in your \nbathrobe, with pieces of your anatomy sticking out that shouldn't stick \nout. Sure, it may be the \"real you\", but there's a difference between \nbeing honest, and just being disgusting.\n\nThe same is true of SCM history. There's \"honesty\", and there's \"digusting \nmess\". At least when it comes to the kernel, I want the \"honest\" kind of \nhistory, not the \"disgusting\" kind.\n\n\t\t\tLinus\n"},{"id":"10887","messageId":"7vk6ftcp0d.fsf@assigned-by-dhcp.cox.net","threadId":"2279","inReplyTo":"20051031213616.GO11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T22:14:58Z","receivedAt":"2005-10-31T22:14:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joel Becker writes:\n\n> On Mon, Oct 31, 2005 at 01:00:18PM -0800, Junio C Hamano wrote:\n>> Do you think anybody is that perfect?\n>\n> \tI was being slightly facetious. Of course everyone makes\n> mistakes and corrects them. But if you _want_ the history, you have to\n> take it. Otherwise, you are required to throw away the history\n> completely. And that -- do you want the whole history or none of it --\n> is the crux of my question.\n\n> \tI could care less about preserving my public image. I'm an\n> idiot, I screw up all the time. I only care that the tip of my tree is\n> respectable.\n> \tI've seen arguments from folks on both sides -- the intermediate\n> history is important, warts and all, vs throw it all out for a clean\n> public history. It seems that you fall into the second camp.\n> \tThat's fine, but can we make that work model a first-class\n> citizen? Can we get a script that pulls one branch as a single,\n> un-historied (sic) commit into the current branch?\n\nI think you read me wrong. Didn't I say \"decompose and make\nthem into logical stepS\", emphasis on plural \"S\"?\n\nSingle big consolidated patch is not what I am advocating for.\nIt is impossible to review and evaluate. To be merged into a\npublic tree, such unhistoried commit is often unacceptable.\n"},{"id":"10890","messageId":"20051031224246.GP11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"7vk6ftcp0d.fsf@assigned-by-dhcp.cox.net","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-10-31T22:42:46Z","receivedAt":"2005-10-31T22:42:46Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Mon, Oct 31, 2005 at 02:14:58PM -0800, Junio C Hamano wrote:\n> I think you read me wrong. Didn't I say \"decompose and make\n> them into logical stepS\", emphasis on plural \"S\"?\n> \n> Single big consolidated patch is not what I am advocating for.\n> It is impossible to review and evaluate. To be merged into a\n> public tree, such unhistoried commit is often unacceptable.\n\n\tNo, you're reading me wrong, but I wasn't clear enough either.\nAt the end of my message, I'm noting that I'm considering smaller\nchanges here, not huge features.\n\tBasically, I'm not talking about merging with Linus. I'm\ntalking about merging with myself. Let's assume we're all going with\nthe clean-up-your-history model. It is quite clear that you and Linus\nagree on that model, and I wasn't so much arguing against it as querying\neveryone's opinion on it.\n\tSo, I have a git repository that is my For-Linus repository.\nIt's got a clean history. What's my workflow?\n\n\t1) Clone the repo to a Work tree.\n\t2) Create and test fix X, with perhaps some >1 number of commits.\n\t3) Bring that fix back to the For-Linus repository.\n\n\tThis is a small change. It's not something that needs stepS, as\nyou put them. But my history in the Work tree is \"dirty,\" so I cannot\njust pull from Work to For-Linus.\n\tAs the tools currently stand, I need to hand-diff and patch my\ncommits. Neither git nor cogito have a command to do this first-class\n\"the way you should do it\" common operation. It is, in my experience, a\npain. Not as large a pain as some things, but certainly second class to\nmuch of the workflow git/cogito provide. If it is supposed to be a\nregular part of my workflow, what's wrong with making it a first-class\noperation?\n\tObviously, large features should and do have logical steps. I'm\nnever going to be against that.\n\nJoel\n\n-- \n\nLife's Little Instruction Book #15\n\n\t\"Own a great stereo system.\"\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10893","messageId":"dk6a46$dqv$1@sea.gmane.org","threadId":"2279","inReplyTo":"867jbtii85.fsf@blue.stonehenge.com","subject":"Re: git versus CVS (versus bk)","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-10-31T23:41:59Z","receivedAt":"2005-10-31T23:41:59Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"Randal L. Schwartz wrote:\n> ...I doubt that Linus\n> would compare his marriage...with CVS. :)\n\nI dunno why not. If my wife knew CVS she would probably agree\nwith me (for a change).\n\nI've learned a great deal from reading this thread -- as I hope\nothers have. I did learn one important thing while reading about\nold Al Einstein: you can get some astonishing insights by asking\nreally dumb questions of really smart people.\n\nI've had many such astonishing insights from reading Linus's posts\nover the years (and I look forward to many more). I've been amazed\nby Linus's understanding of both machines and people -- this combo\nis rare indeed!\n\nLinus, have you considered a career in marriage counseling?\n"},{"id":"10896","messageId":"Pine.LNX.4.64.0510311905120.25300@iabervon.org","threadId":"2279","inReplyTo":"867jbtii85.fsf@blue.stonehenge.com","subject":"Re: git versus CVS (versus bk)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-01T00:15:22Z","receivedAt":"2005-11-01T00:15:22Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 31 Oct 2005, Randal L. Schwartz wrote:\n\n> >>>>> \"wa1ter\" == wa1ter writes:\n> \n> wa1ter> Ahh -- the lightbulb just lit up. Using CVS is just like\n> wa1ter> being married. No wonder you hate it...\n> \n> Now, hey hey. I've met Tove. She's very nice. I doubt that Linus\n> would compare his marriage to her with CVS. :)\n\nHe did say that CVS worked reasonably at Transmeta. He's probably just as \nglad she's not married to the entire Linux development community...\n\nBeing married is great, but it just doesn't scale past a dozen people who \ntrust each other and have rules on how they do things.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"10897","messageId":"7vbr15b4m4.fsf@assigned-by-dhcp.cox.net","threadId":"2279","inReplyTo":"20051031224246.GP11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-01T00:20:51Z","receivedAt":"2005-11-01T00:20:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joel Becker writes:\n\n> \tNo, you're reading me wrong, but I wasn't clear enough either.\n> At the end of my message, I'm noting that I'm considering smaller\n> changes here, not huge features.\n\nOK. Consolidating two or more patches into one is something I\nhave done too, but I never felt need for tool support, so that's\nprobably why I misunderstood you.\n\nAfter extracting a sequence of the dirty commits using\ngit-format-patch, I would say:\n\n\tfor i in 0*.txt; do git-apply --index $i; done\n\nto bring my tree up to date, and then just say \"git commit\".\n\nTypically when I do this, I have one \"significant\" commit among\nthem, usually early in the series, which is followed by smaller\n\"fix this, fix that, oops fix that too\" commits. So I edit the\nlog message using the log of the significant commit, and add\nsome missing bits.\n\nI guess another way to do it without even first extracting them\nas patches would be:\n\n $ git checkout -b mytopic master\n $ work work work, commit commit commit.\n $ git checkout master\n $ git-read-tree -m -u master mytopic\n $ git-commit -c \n\nIf you want a tool support for this workflow, probably the last\ntwo could be somewhat automated. But what would the user input\nfor that be? You need to tell what tree shape you want the\nafter-commit tree to be in, and where you would want the bulk of\nyour commit message to come from.\n\nOne possibility.\n\n $ git-squash-pick mytopic\n\nwould be something like this:\n\n\t#!/bin/sh\n #\n git-read-tree -m -u HEAD \"$1\"\n git log HEAD..\"$1\" >.tmp-commit\n git-commit -F .tmp-commit -e\n\nYour commit-log edit buffer would start with the concatenation\nof all the commit logs in that throwaway history, and hopefully\nyou would mostly need to delete lines and move some parts around\nbefore committing. I do not know how useful this kind of\nspecialized tool would be, though...\n\nSplitting and merging patches into logical steps is something I\ndream of to be automated, but I do not know how (nor even if it\nis possible) offhand. Sometimes, when you want truly logical\nsteps, you would end up needing intermediate steps that never\nexisted in your true history (i.e. \"in the hindsight, my\ndevelopment should have progressed in these steps.\")\n\n\n\n\t\n"},{"id":"10898","messageId":"Pine.LNX.4.64.0510311620410.27915@g5.osdl.org","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510311905120.25300@iabervon.org","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-01T00:21:19Z","receivedAt":"2005-11-01T00:21:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Daniel Barkalow wrote:\n> \n> Being married is great, but it just doesn't scale past a dozen people who \n> trust each other and have rules on how they do things.\n\nThis thread is getting a big psychedelic.\n\nPeople, take your meds, please,\n\n\t\tLinus\n"},{"id":"10900","messageId":"20051101002554.GA7634@thunk.org","threadId":"2279","inReplyTo":"20051031224246.GP11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2005-11-01T00:25:54Z","receivedAt":"2005-11-01T00:25:54Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 31, 2005 at 02:42:46PM -0800, Joel Becker wrote:\n> \tAs the tools currently stand, I need to hand-diff and patch my\n> commits. Neither git nor cogito have a command to do this first-class\n> \"the way you should do it\" common operation. It is, in my experience, a\n> pain. Not as large a pain as some things, but certainly second class to\n> much of the workflow git/cogito provide. If it is supposed to be a\n> regular part of my workflow, what's wrong with making it a first-class\n> operation?\n\nFor an example of how to make it a first-class operation, it might be\nworthwhile to look at Chris Mason's \"Mercurial Queues\" extention to\nMercurial:\n\n\thttp://www.selenic.com/mercurial/wiki/index.cgi/MqExtension\n\nI've used it once or twice, and hg mq is definitely very nice and\nconvenient, and it makes commits a first-class operation. On the\nother hand, I've found that the combination of quilt and\nMercurial/BK/git works just fine, even for my own internal development\nof (for example) the e2fsprogs tree.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"10901","messageId":"Pine.LNX.4.64.0510311916150.25300@iabervon.org","threadId":"2279","inReplyTo":"20051031224246.GP11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-01T00:31:50Z","receivedAt":"2005-11-01T00:31:50Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 31 Oct 2005, Joel Becker wrote:\n\n> \tSo, I have a git repository that is my For-Linus repository.\n> It's got a clean history. What's my workflow?\n> \n> \t1) Clone the repo to a Work tree.\n> \t2) Create and test fix X, with perhaps some >1 number of commits.\n> \t3) Bring that fix back to the For-Linus repository.\n> \n> \tThis is a small change. It's not something that needs stepS, as\n> you put them. But my history in the Work tree is \"dirty,\" so I cannot\n> just pull from Work to For-Linus.\n> \tAs the tools currently stand, I need to hand-diff and patch my\n> commits. Neither git nor cogito have a command to do this first-class\n> \"the way you should do it\" common operation. \n\nI actually have a set of scripts that I use for this, which I've been too \nlame to clean up properly and send in. The basic idea is:\n\n (1) \"git branch clean mainline\"\n (2) \"git checkout clean\"\n (now I'm looking at the clean history, which doesn't have anything \n yet)\n (3) \"git refine dirty\"\n (this says I'm trying to match the content of the head with the \n dirty history)\n (4) editor window pops up with the diff between the working tree and \n dirty\n (5) edit the patch, removing hunks which go later in the series, or which \n I don't want to do at all and forgot to revert.\n (6) it applies the patch; if there are rejects, it goes back to (4)\n (7) normal thing for committing happens\n (8) if there is any difference between the working tree and dirty, it \n goes back to (4) for the next in the series\n\nI still need to correct the flow control and make it invoke the editor \nautomatically and such, and provide some way out of the middle if you want \nto give up or stop without reaching the end, and I have to detect the done \ncondition. But the general method does work, provided you're at least \nsomewhat comfortable editing patches (with the safety net that nobody else \nwill ever see the patch, so it doesn't matter too much if you screw it \nup).\n\nIf somebody else wants to clean this up, I can post my version; dunno when \nI'll get around to making it really right.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"10903","messageId":"20051101004255.GQ11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"7vbr15b4m4.fsf@assigned-by-dhcp.cox.net","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-11-01T00:42:55Z","receivedAt":"2005-11-01T00:42:55Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Mon, Oct 31, 2005 at 04:20:51PM -0800, Junio C Hamano wrote:\n> After extracting a sequence of the dirty commits using\n> git-format-patch, I would say:\n> \tfor i in 0*.txt; do git-apply --index $i; done\n> to bring my tree up to date, and then just say \"git commit\".\n\n\tYeah, but this is a lot of by-hand (as you note below).\n\n> Typically when I do this, I have one \"significant\" commit among\n> them, usually early in the series, which is followed by smaller\n> \"fix this, fix that, oops fix that too\" commits. So I edit the\n> log message using the log of the significant commit, and add\n> some missing bits.\n\n\tWhen I work, regardless of SCM, I generally have many\ncheckpoints along the way. It might be a particular subfeature is\ncomplete (and probably deserves a split-out patch of its own when I do\nthe \"clean\" merge), but it could also just be \"I changed a lot today,\nand I'd really like to save that off.\" So, while somtimes it looks just\nlike your \"significant commit + fixes\" model, it might also be \"1/4 the\nwork\", \"compile fix on other platform, \"1/2 the work\", \"fix\", \"the rest\nof the work\", all over the course of two days.\n\n> $ git-read-tree -m -u master mytopic\n> $ git-commit -c \n\n\tReplace with and you\nhave the workflow I'm talking about.\n\tYou know, this is a simpler command set than I am using. I've\nbeen using Cogito, because it makes many of the 5-step git operations a\nsingle step, more like some other tools. But I know no way to tell\nCogito to merge all the changes of the branch into the master without\nalso pulling in the commit history. That's the thing here. Petr, do\nyou have a way of doing this that I don't know about?\n\tWhat I mean is, for the \"naive\" Cogito workflow:\n\n\tcg-clone repo working\n\tcd working\n\thack hack hack, commit commit commit\n\tcd mainline\n\tcg-pull working\n\nthe cg-pull command merges the changes back, but it also includes the\nfull commit history. Not what we want. Compare the \"identical\"\nworkflow:\n\n\tcg-clone repo working\n\tcd working\n\thack hack hack, commit commit commit\n\tcg-diff mainline working > patch\n\tcd mainline\n\tcg-apply < patch\n\tcg-commit\n\nMy basic premise is that I shouldn't have to deal with diff/patch as an\nexternal step, especially since git knows more about the tree than\ndiff/patch do. It's a useless hoop to jump through.\n\tMaybe Cogito contains something like what you describe above, a\nway to get all the file changes without actually pulling in the commit\nhistory. I don't care that the read-tree and the commit are separate\nstages. I just have to type them.\n\n\n> is possible) offhand. Sometimes, when you want truly logical\n> steps, you would end up needing intermediate steps that never\n> existed in your true history (i.e. \"in the hindsight, my\n> development should have progressed in these steps.\")\n\n\tYes, I always do. But I'm not talking about that sort of large\nfeature add or whatever. I'm talking about merely doing something on a\nsmall scale, but in a temporary repository.\n\nJoel\n\n-- \n\nLife's Little Instruction Book #510\n\n\t\"Count your blessings.\"\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10905","messageId":"46a038f90510311702wfb43281rf4464a02e8e3be2@mail.gmail.com","threadId":"2279","inReplyTo":"20051101004255.GQ11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-01T01:02:43Z","receivedAt":"2005-11-01T01:02:43Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/1/05, Joel Becker wrote:\n> > is possible) offhand. Sometimes, when you want truly logical\n> > steps, you would end up needing intermediate steps that never\n> > existed in your true history (i.e. \"in the hindsight, my\n> > development should have progressed in these steps.\")\n>\n> Yes, I always do. But I'm not talking about that sort of large\n> feature add or whatever. I'm talking about merely doing something on a\n> small scale, but in a temporary repository.\n\nI'm really surprised that Calalin hasn't chimed in. If you are into\nrewriting/merging/splitting your patches, StGIT is your friend. Check\nout: http://www.procode.org/stgit/\n\ncheers,\n\n\nmartin\n"},{"id":"10907","messageId":"20051101012915.GR11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"46a038f90510311702wfb43281rf4464a02e8e3be2@mail.gmail.com","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-11-01T01:29:15Z","receivedAt":"2005-11-01T01:29:15Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 02:02:43PM +1300, Martin Langhoff wrote:\n> I'm really surprised that Calalin hasn't chimed in. If you are into\n> rewriting/merging/splitting your patches, StGIT is your friend. Check\n> out: http://www.procode.org/stgit/\n\n\tBut I'm not. I don't want patches in the first place. I want\ncg-pull but with a flattened history.\n\nJoel\n\n\n-- \n\n\"Any man who is under 30, and is not a liberal, has not heart;\n and any man who is over 30, and is not a conservative, has no brains.\"\n - Sir Winston Churchill \n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10908","messageId":"Pine.LNX.4.64.0510311747580.27915@g5.osdl.org","threadId":"2279","inReplyTo":"20051101012915.GR11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-01T01:48:46Z","receivedAt":"2005-11-01T01:48:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Joel Becker wrote:\n> \n> \tBut I'm not. I don't want patches in the first place. I want\n> cg-pull but with a flattened history.\n\nWell, that you've largely got in \"git rebase\". But if you wanrt to merge \ncommits, you'd have to do that logic yourself..\n\n\t\tLinus\n"},{"id":"10910","messageId":"86hdaxf6wq.fsf@blue.stonehenge.com","threadId":"2279","inReplyTo":"46a038f90510311228v50743158q80d79e963bd503ce@mail.gmail.com","subject":"Re: git versus CVS (versus bk)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2005-11-01T02:17:41Z","receivedAt":"2005-11-01T02:17:41Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Martin\" == Martin Langhoff writes:\n\nMartin> You can do a diff that spans all the commits and apply it with a new\nMartin> commit msg. With cogito:\n\nMartin> cg-diff -r from:to | patch -p1\n\nWhat's the easiest way then to toss all that intermediate history?\nI'm thinking of the rcs \"-o\" switch that \"outdates\" any deltas in that\nrange.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"10911","messageId":"Pine.LNX.4.64.0510311822080.27915@g5.osdl.org","threadId":"2279","inReplyTo":"86hdaxf6wq.fsf@blue.stonehenge.com","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-01T02:23:02Z","receivedAt":"2005-11-01T02:23:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Randal L. Schwartz wrote:\n> \n> Martin> cg-diff -r from:to | patch -p1\n> \n> What's the easiest way then to toss all that intermediate history?\n> I'm thinking of the rcs \"-o\" switch that \"outdates\" any deltas in that\n> range.\n\nStart a new branch before the sequence you want to clean up. Then, move \nthe cleaned-up history to that branch, and eventually you can just delete \nthe old one.\n\n\t\tLinus\n"},{"id":"10912","messageId":"86r7a1drji.fsf@blue.stonehenge.com","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510311822080.27915@g5.osdl.org","subject":"Re: git versus CVS (versus bk)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2005-11-01T02:34:57Z","receivedAt":"2005-11-01T02:34:57Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> Start a new branch before the sequence you want to clean\nLinus> up. Then, move the cleaned-up history to that branch, and\nLinus> eventually you can just delete the old one.\n\nSo if I toss something in git/refs, the objects pointed to by that are\neventually reclaimed? Do I need to git-fsck-objects to do that? Or\nis there some cg command to do the whole thing?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"10913","messageId":"7vvezd9jt8.fsf@assigned-by-dhcp.cox.net","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0510311822080.27915@g5.osdl.org","subject":"Re: git versus CVS (versus bk)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-01T02:35:31Z","receivedAt":"2005-11-01T02:35:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 31 Oct 2005, Randal L. Schwartz wrote:\n>> \n>> Martin> cg-diff -r from:to | patch -p1\n>> \n>> What's the easiest way then to toss all that intermediate history?\n>> I'm thinking of the rcs \"-o\" switch that \"outdates\" any deltas in that\n>> range.\n>\n> Start a new branch before the sequence you want to clean up. Then, move \n> the cleaned-up history to that branch, and eventually you can just delete \n> the old one.\n\nBig caveat --- do that before you make that dirty tree available\nto outside, otherwise you would be in hot water ;-)\n"},{"id":"10914","messageId":"Pine.LNX.4.64.0510311845020.27915@g5.osdl.org","threadId":"2279","inReplyTo":"86r7a1drji.fsf@blue.stonehenge.com","subject":"Re: git versus CVS (versus bk)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-01T02:47:07Z","receivedAt":"2005-11-01T02:47:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, Randal L. Schwartz wrote:\n> \n> Linus> Start a new branch before the sequence you want to clean\n> Linus> up. Then, move the cleaned-up history to that branch, and\n> Linus> eventually you can just delete the old one.\n> \n> So if I toss something in git/refs, the objects pointed to by that are\n> eventually reclaimed? Do I need to git-fsck-objects to do that? Or\n> is there some cg command to do the whole thing?\n\nYou can do \"git prune\". It's pretty expensive, though, and the extra \nobjects don't _hurt_, so there's no reason to do pruning very \naggressively. I tend to prune immediately just because I run \ngit-fsck-objects all the time, and if you don't prune, it will nag you \nabout \"dangling commit\".\n\nYou may also decide to just rename the old broken branch. Keeping it \naround for local historical reasons and never push it out.\n\n\t\tLinus\n"},{"id":"10918","messageId":"20051101090804.GA11618@pasky.or.cz","threadId":"2279","inReplyTo":"20051101002554.GA7634@thunk.org","subject":"hgmq vs. StGIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T09:08:04Z","receivedAt":"2005-11-01T09:08:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 01, 2005 at 01:25:54AM CET, I got a letter\nwhere Theodore Ts'o told me that...\n> For an example of how to make it a first-class operation, it might be\n> worthwhile to look at Chris Mason's \"Mercurial Queues\" extention to\n> Mercurial:\n> \n> \thttp://www.selenic.com/mercurial/wiki/index.cgi/MqExtension\n> \n> I've used it once or twice, and hg mq is definitely very nice and\n> convenient, and it makes commits a first-class operation. On the\n> other hand, I've found that the combination of quilt and\n> Mercurial/BK/git works just fine, even for my own internal development\n> of (for example) the e2fsprogs tree.\n\nDid anyone do any current detailed comparison between hg mq and StGIT?\n\nI'm very happy with StGIT, modulo few UI gripes I'm still not getting\naround to fix, and the fact that I cannot version my changes to patches\n- this is one advantage of having quilt stuff tracked by GIT, I think,\nbut that feels ugly.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10919","messageId":"20051101091533.GB11618@pasky.or.cz","threadId":"2279","inReplyTo":"20051031213003.GN11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T09:15:33Z","receivedAt":"2005-11-01T09:15:33Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Oct 31, 2005 at 10:30:03PM CET, I got a letter\nwhere Joel Becker told me that...\n> On Tue, Nov 01, 2005 at 09:28:30AM +1300, Martin Langhoff wrote:\n> > You can do a diff that spans all the commits and apply it with a new\n> > commit msg. With cogito:\n> > \n> > cg-diff -r from:to | patch -p1\n> \n> \tI'm well aware of this, my question was rather one of\n> applicability. First, do we want it to work this way, losing the\n> history. Second, you'd like the process to be all encompasing if you go\n> this route.\n> \n> ((cd old-repo && cg-diff -r from) | patch -p1) && cg-commit\n> \n> or any equivalent. Why should I have to muck with patch and diff, when\n> I can have a 'pull-as-one' operation. Sure, it's a wrapper, but if its\n> the intended mode of development, let's make it a first-class citizen.\n\nPersonally, from my POV it is the intended mode of development only if\nyou keep strictly topical branches (a single logical change and fixes of\nit on top of that). Otherwise, this is horrid because it loses the\n_precious_ history and bundles us different changes to a single commit,\nwhich is one of the thing that are wrong on CVS/SVN merging.\n\nThat said, with a big warning, I would be willing to do something like\ncg-merge -s and cg-update -s (s as squash), with a big warning that this\nis suitable only for topical branches. And I think it'd be still much\nbetter to spend the work making StGIT able to track history of changes\nto a particular patch.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10920","messageId":"20051101091710.GC11618@pasky.or.cz","threadId":"2279","inReplyTo":"20051101012915.GR11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T09:17:11Z","receivedAt":"2005-11-01T09:17:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 01, 2005 at 02:29:15AM CET, I got a letter\nwhere Joel Becker told me that...\n> On Tue, Nov 01, 2005 at 02:02:43PM +1300, Martin Langhoff wrote:\n> > I'm really surprised that Calalin hasn't chimed in. If you are into\n> > rewriting/merging/splitting your patches, StGIT is your friend. Check\n> > out: http://www.procode.org/stgit/\n> \n> \tBut I'm not. I don't want patches in the first place. I want\n> cg-pull but with a flattened history.\n\nStGIT does not work with patches but with commits. You can manage the\nlogical changes with StGIT and when it's time, just merge your\nStGIT-tracked branch with whatever else. \"Patch\" here is really just a\ndifferent name for logical change / commit.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10921","messageId":"b0943d9e0511010123i1f9eb679w@mail.gmail.com","threadId":"2279","inReplyTo":"20051101090804.GA11618@pasky.or.cz","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T09:23:55Z","receivedAt":"2005-11-01T09:23:55Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Petr Baudis wrote:\n> Did anyone do any current detailed comparison between hg mq and StGIT?\n\nNot AFAIK. I looked a bit at mq but didn't have time to play with it.\n\n> I'm very happy with StGIT, modulo few UI gripes I'm still not getting\n> around to fix, and the fact that I cannot version my changes to patches\n> - this is one advantage of having quilt stuff tracked by GIT, I think,\n> but that feels ugly.\n\nThat's not too far away. Chuck Lever has a patch (and there were some\nother discussions in the past) for tracking the history of a patch.\nBasically, there would be another commit object, not reachable from\nHEAD but only via an StGIT command, which would chain all the versions\nof a patch. You would be able to view them with gitk for example.\n\nMy main issue was whether we should store every state resulted from a\nrefresh or use a separate command (somebody suggested 'freeze') to\nmark the states that should be preserved in the history. Chuck's patch\nimplements the first. The drawback is that a future 'stg prune'\ncommand would not be able to remove the history and some states of the\npatch might not be useful (there are times when I do a refresh only to\npop the patch and modify a different one, without any logical meaning\nfor the state of the patch).\n\nI'm open to other suggestions as well. Otherwise, Chuck's patch should\ndo the job.\n\n--\nCatalin\n"},{"id":"10922","messageId":"20051101101004.GD11618@pasky.or.cz","threadId":"2279","inReplyTo":"b0943d9e0511010123i1f9eb679w@mail.gmail.com","subject":"Re: hgmq vs. StGIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T10:10:04Z","receivedAt":"2005-11-01T10:10:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter\nwhere Catalin Marinas told me that...\n> On 01/11/05, Petr Baudis wrote:\n> > and the fact that I cannot version my changes to patches\n> > - this is one advantage of having quilt stuff tracked by GIT, I think,\n> > but that feels ugly.\n> \n> That's not too far away. Chuck Lever has a patch (and there were some\n> other discussions in the past) for tracking the history of a patch.\n> Basically, there would be another commit object, not reachable from\n> HEAD but only via an StGIT command, which would chain all the versions\n> of a patch. You would be able to view them with gitk for example.\n\nPerhaps you could emulate the topical branches - one patch == one head.\nE.g. for patch foo-bar on branch 'master', you would create head\nmaster/foo-bar, etc.\n\n> My main issue was whether we should store every state resulted from a\n> refresh or use a separate command (somebody suggested 'freeze') to\n> mark the states that should be preserved in the history. Chuck's patch\n> implements the first. The drawback is that a future 'stg prune'\n> command would not be able to remove the history and some states of the\n> patch might not be useful (there are times when I do a refresh only to\n> pop the patch and modify a different one, without any logical meaning\n> for the state of the patch).\n\nI'd prefer the snapshotting being done in refresh anyway. Perhaps you\nwould be asked for log message when you refresh by default, but when you\nrefresh -n or something, only a temporary commit would be created and\nnext refresh would mutate it instead of creating another commit.\n\nAnyway, \"freeze\" is confusing. Perhaps \"snapshot\" if anything...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10924","messageId":"tnxd5lkwld8.fsf@arm.com","threadId":"2279","inReplyTo":"46a038f90510311702wfb43281rf4464a02e8e3be2@mail.gmail.com","subject":"Re: git versus CVS (versus bk)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T13:25:39Z","receivedAt":"2005-11-01T13:25:39Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Martin Langhoff wrote:\n> On 11/1/05, Joel Becker wrote:\n>> > is possible) offhand. Sometimes, when you want truly logical\n>> > steps, you would end up needing intermediate steps that never\n>> > existed in your true history (i.e. \"in the hindsight, my\n>> > development should have progressed in these steps.\")\n>>\n>> Yes, I always do. But I'm not talking about that sort of large\n>> feature add or whatever. I'm talking about merely doing something on a\n>> small scale, but in a temporary repository.\n>\n> I'm really surprised that Calalin hasn't chimed in.\n\nWell, it was night here when this discussion took off :-).\n\n> If you are into rewriting/merging/splitting your patches, StGIT is\n> your friend. Check out: http://www.procode.org/stgit/\n\nStGIT mainly resembles Quilt workflow but there are no patches, only\ncommit objects which are indefinitely replaceable (push/pop/refresh).\n\nWhat I usually do is create smaller commits for different features and\njust stack them together. That's usually for features which are\ndependent on each-other and you can control them with a finer grain\nthan having separate branches. One can push/pop patches (commits) to\nbring the patch to be modified at the top. After modification, a\nrefresh command would save it as a commit. All the patches (commits)\nin the stack are accessible via HEAD and are seen as GIT commits.\n\nIt may happen to just have a bigger patch which needs splitting. What\nI usually do in this case is import the patch as an StGIT patch\n(i.e. GIT commit object), pop it from the stack so that it is no\nlonger applied, split the physical patch (diff file) into smaller, logical\nchanges and apply them one by one with StGIT. When you think al the\nbig patch was completely applied, pushing it should result in an empty\npatch, otherwise you might have missed something that needs applying.\n\nWith StGIT you can also pick a commit object from a different branch\nas a StGIT patch or you could merge two patches into one.\n\nOnce you are OK with the patches in the stack, just ask the gatekeeper\nto pull the changes from your tree using plain GIT or mail them\nautomatically with StGIT.\n\n-- \nCatalin\n"},{"id":"10925","messageId":"20051101141149.GA26847@watt.suse.com","threadId":"2279","inReplyTo":"20051101090804.GA11618@pasky.or.cz","subject":"Re: hgmq vs. StGIT","fromName":"Chris Mason","fromEmail":"mason@suse.com","sentAt":"2005-11-01T14:11:49Z","receivedAt":"2005-11-01T14:11:49Z","isPatch":false,"sender":{"key":"mason@suse.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 10:08:04AM +0100, Petr Baudis wrote:\n> Dear diary, on Tue, Nov 01, 2005 at 01:25:54AM CET, I got a letter\n> where Theodore Ts'o told me that...\n> > For an example of how to make it a first-class operation, it might be\n> > worthwhile to look at Chris Mason's \"Mercurial Queues\" extention to\n> > Mercurial:\n> > \n> > \thttp://www.selenic.com/mercurial/wiki/index.cgi/MqExtension\n> > \n> > I've used it once or twice, and hg mq is definitely very nice and\n> > convenient, and it makes commits a first-class operation. On the\n> > other hand, I've found that the combination of quilt and\n> > Mercurial/BK/git works just fine, even for my own internal development\n> > of (for example) the e2fsprogs tree.\n> \n> Did anyone do any current detailed comparison between hg mq and StGIT?\n\nI don't think so, but I'll give it a rough try. I have not used stgit\nextensively, so please correct any mistakes below. Most of the\ndifferences center around the ways we store patches.\n\nBoth tools make patches into commits during push. This allows the\nvarious history commands to see the currently applied patches.\n\nBoth tools allow you to make changes to files without running some form\nof quilt add first.\n\nStGIT has the ability to rebase patches via three-way merge. This is\nstill on my todo list for mq.\n\nStGIT patch storage is very different from quilt and mq. StGIT keeps\ngit commit/tree objects around for patches that have been applied. It\nthen stores a directory with metadata about the patch\n(author/description etc) and the ids of the git commit objects.\n\nIn StGIT, importing new patches seems to require stg import, and exporting patches\nrequires stg export (or a similar git command). But once the patches\nare stored in stgit, push/pop will be very fast.\n\nmq is closer to quilt. The patches are stored as patches, and hg qpush\nis very similar to importing a patch. This means metadata must be\nstored at the top of the patch in some form the import code can\nunderstand (it tries to be smart about this).\n\nhg qrefresh will update the patch file, so the patch is always up to\ndate wrt to the hg repo.\n\nYou can import/export patches with hg commands, or by copying patches\ninto/from the .hg/patches directory. This also means you can take a\nquilt patch dir, copy it into .hg/patches and just start using mq.\n\nmq has some support for putting the patches directory under\nrevision control (as a separate repository).\n\nMost of the other differences come from differences between hg and git.\nI'm not sure if stgit has some form of annotate, but it's a nice way to\nfind out which patch changed a given loc in hg/mq.\n\n-chris\n"},{"id":"10926","messageId":"436787BD.9080705@citi.umich.edu","threadId":"2279","inReplyTo":"b0943d9e0511010123i1f9eb679w@mail.gmail.com","subject":"Re: hgmq vs. StGIT","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2005-11-01T15:20:29Z","receivedAt":"2005-11-01T15:20:29Z","isPatch":false,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Catalin Marinas wrote:\n> On 01/11/05, Petr Baudis wrote:\n> \n>>Did anyone do any current detailed comparison between hg mq and StGIT?\n> \n> \n> Not AFAIK. I looked a bit at mq but didn't have time to play with it.\n> \n> \n>>I'm very happy with StGIT, modulo few UI gripes I'm still not getting\n>>around to fix, and the fact that I cannot version my changes to patches\n>>- this is one advantage of having quilt stuff tracked by GIT, I think,\n>>but that feels ugly.\n> \n> \n> That's not too far away. Chuck Lever has a patch (and there were some\n> other discussions in the past) for tracking the history of a patch.\n> Basically, there would be another commit object, not reachable from\n> HEAD but only via an StGIT command, which would chain all the versions\n> of a patch. You would be able to view them with gitk for example.\n> \n> My main issue was whether we should store every state resulted from a\n> refresh or use a separate command (somebody suggested 'freeze') to\n> mark the states that should be preserved in the history. Chuck's patch\n> implements the first. The drawback is that a future 'stg prune'\n> command would not be able to remove the history and some states of the\n> patch might not be useful (there are times when I do a refresh only to\n> pop the patch and modify a different one, without any logical meaning\n> for the state of the patch).\n> \n> I'm open to other suggestions as well. Otherwise, Chuck's patch should\n> do the job.\n\nif there is interest i can post what i have. unfortunately there's some \nother stuff in front of it so i don't think it will apply directly to \ncatalin's stgit without some futzing. in lieu of that, here's a command \nsynopsis:\n\n[cel@seattle ~]$ stg revisions -h\nusage: stg revisions [options] [patch-name]\n\nDisplay the change history of a patch or revert a patch to a previous\ncommit. By itself, the command will display all committed changes,\nordered by date, of a patch. Each committed change is listed with a\nnumeric label. The label can be used with the --patch or --diff options\nto examine specific changes in detail. The --revert option can revert\na patch to any previous version.\n\noptions:\n --commit=commit-label\n show the commit details of the specified commit\n --diff=commit-label show changes between the specified commit and \nthe next\n --file= show changes made to a specific file\n --patch=commit-label show the state of patch-name at the specified \ncommit\n --revert=commit-label\n revert the patch to the specified previous commit\n -h, --help show this help message and exit\n[cel@seattle ~]$\n\nand some usage examples:\n\n[cel@seattle main]$ stg revisions\nPrevious revisions of patch \"revisions-command\":\n 0: Sat Oct 1 21:54:43 2005 -0400\n 1: Sat Oct 1 21:58:45 2005 -0400\n 2: Sat Oct 1 22:13:27 2005 -0400\n 3: Sat Oct 1 22:55:28 2005 -0400\n 4: Sat Oct 1 23:02:22 2005 -0400\n\n ... snipped ...\n\n 86: Mon Oct 31 14:19:25 2005 -0500\n 87: Mon Oct 31 14:22:00 2005 -0500\n 88: Mon Oct 31 14:23:40 2005 -0500\n 89: Mon Oct 31 14:24:39 2005 -0500\n 90: Mon Oct 31 14:27:34 2005 -0500\n[cel@seattle main]$\n\nan entry is added to this list automatically after every operation that \ndoes a \"refresh\".\n\nthe idea is to expose and manipulate the change history of a patch \nwithout having to use cumbersome sha1 hash values.\n\nwithout options, \"stg revisions\" shows a list of changes to a patch, by \ndate. each change has a label (just a number) which you can use to \ngenerate diffs and such. to wit:\n\n stg revisions --patch=45\n\nwould show a diff between the previous patch, and the state of the patch \nat change 45.\n\n stg revisions --diff=45\n\nwould show a diff between change 45 and change 44.\n\n stg revisions --commit=45\n\nwould show pretty-printed commit information for change 45.\n\n stg revisions --revert=45\n\nwould revert the patch back to the way it was in change 45. notably, \nyou don't throw away changes 46 through 90 when you do this. a new \nchange is added which changes the state of the patch to the way it was \nin change 45. (well, that's how it's supposed to work, anyway).\n\ni'm interested to hear what folks on the list think of the idea.\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Linux NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763-4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668-1089\nx-mozilla-html:FALSE\nurl:http://www.monkey.org/~cel/\nversion:2.1\nend:vcard\n\n"},{"id":"10927","messageId":"20051101153650.GB26847@watt.suse.com","threadId":"2279","inReplyTo":"436787BD.9080705@citi.umich.edu","subject":"Re: hgmq vs. StGIT","fromName":"Chris Mason","fromEmail":"mason@suse.com","sentAt":"2005-11-01T15:36:50Z","receivedAt":"2005-11-01T15:36:50Z","isPatch":false,"sender":{"key":"mason@suse.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 10:20:29AM -0500, Chuck Lever wrote:\n[ ... ]\n> would show pretty-printed commit information for change 45.\n> \n> stg revisions --revert=45\n> \n> would revert the patch back to the way it was in change 45. notably, \n> you don't throw away changes 46 through 90 when you do this. a new \n> change is added which changes the state of the patch to the way it was \n> in change 45. (well, that's how it's supposed to work, anyway).\n> \n> i'm interested to hear what folks on the list think of the idea.\n\nI'm probably not familiar enough with stgit, but it\nlooks to me as though you're tracking individual patch history only.\n\nIn trees I work with, patches rarely stand alone. There are typically\ncollections of patches implementing a given feature, or a change to one\npatch requires rebasing a number of (perhaps unrelated) others.\n\nI think the command set you describe above will lose that grouping.\n\n-chris\n"},{"id":"10929","messageId":"Pine.LNX.4.64.0511010757040.27915@g5.osdl.org","threadId":"2279","inReplyTo":"20051101141149.GA26847@watt.suse.com","subject":"Re: hgmq vs. StGIT","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-01T16:00:25Z","receivedAt":"2005-11-01T16:00:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 1 Nov 2005, Chris Mason wrote:\n> \n> StGIT has the ability to rebase patches via three-way merge. This is\n> still on my todo list for mq.\n\nBtw, I have to say that I was a bit uncertain about doing the rebasing by \nway of a three-way merge, but when I recently did a revert, I was _really_ \nhappy with how well \"git revert\" did the rebasing of the revert. It wasn't \neven a clean merge, but leaving the conflict in the tree and allowing me \nto fix it up made what would otherwise have been a much more complex \nmanual operation be 99% automated.\n\nSo I'm _neither_ a StGIT not mq user, but I can definitely say that \nrebasing with a three-way merge instead of just trying to apply the patch \n(whether in reverse like in a merge, or just re-apply it straigt) is \nreally really nice.\n\n\t\tLinus\n"},{"id":"10931","messageId":"20051101161730.GV11488@ca-server1.us.oracle.com","threadId":"2279","inReplyTo":"20051101091533.GB11618@pasky.or.cz","subject":"Re: git versus CVS (versus bk)","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-11-01T16:17:30Z","receivedAt":"2005-11-01T16:17:30Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:\n> Personally, from my POV it is the intended mode of development only if\n> you keep strictly topical branches (a single logical change and fixes of\n> it on top of that). Otherwise, this is horrid because it loses the\n> _precious_ history and bundles us different changes to a single commit,\n> which is one of the thing that are wrong on CVS/SVN merging.\n\n\tHere we have the \"precious\" history vs the \"throwaway\" history\nargument again. You are correct, this does look like CVS/Subversion\nmerging. But I'm quite capable of keeping my patches single-topic.\nAnything that requires multiple patches in a logical separation still\nneeds that extra love.\n\n> That said, with a big warning, I would be willing to do something like\n> cg-merge -s and cg-update -s (s as squash), with a big warning that this\n\n\tWouldn't it be cg-pull? I guess I'm not conversant enough of\nall ways to merge branches in cogito.\n\n> is suitable only for topical branches. And I think it'd be still much\n> better to spend the work making StGIT able to track history of changes\n> to a particular patch.\n\n\tI like quilt for certain work, and what I read from you and\nCaitlin makes me interested in StGIT for those large changes that\nrequire split-out patches. But for simple tasks, I just want to use the\nSCM, you know?\n\nJoel\n\n-- \n\n\"The cynics are right nine times out of ten.\" \n - H. L. Mencken\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"10932","messageId":"b0943d9e0511010913p2914ae85k@mail.gmail.com","threadId":"2279","inReplyTo":"Pine.LNX.4.64.0511010757040.27915@g5.osdl.org","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T17:13:26Z","receivedAt":"2005-11-01T17:13:26Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Linus Torvalds wrote:\n> On Tue, 1 Nov 2005, Chris Mason wrote:\n> > StGIT has the ability to rebase patches via three-way merge. This is\n> > still on my todo list for mq.\n>\n> So I'm _neither_ a StGIT not mq user, but I can definitely say that\n> rebasing with a three-way merge instead of just trying to apply the patch\n> (whether in reverse like in a merge, or just re-apply it straigt) is\n> really really nice.\n\nStGIT first tries a \"git-diff-tree | git-apply\" since it is faster but\nwhen this fails it falls back to a three-way merge. A 'stg status'\ncommand would show the conflicted files and they should be marked as\nresolved before refreshing the patch.\n\nOne of the good parts of the three-way merge is that it detects when a\npatch you sent was fully merged upstream, the local patch becoming\nempty after the merge. If not, you either get a conflict or the merge\nleaves the patch with only the unmerged parts.\n\n--\nCatalin\n"},{"id":"10933","messageId":"b0943d9e0511010918ob2dbcfcv@mail.gmail.com","threadId":"2279","inReplyTo":"20051101153650.GB26847@watt.suse.com","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T17:18:49Z","receivedAt":"2005-11-01T17:18:49Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Chris Mason wrote:\n> On Tue, Nov 01, 2005 at 10:20:29AM -0500, Chuck Lever wrote:\n> [ ... ]\n> > would show pretty-printed commit information for change 45.\n> >\n> > stg revisions --revert=45\n> >\n> > would revert the patch back to the way it was in change 45. notably,\n> > you don't throw away changes 46 through 90 when you do this. a new\n> > change is added which changes the state of the patch to the way it was\n> > in change 45. (well, that's how it's supposed to work, anyway).\n> >\n> > i'm interested to hear what folks on the list think of the idea.\n>\n> I'm probably not familiar enough with stgit, but it\n> looks to me as though you're tracking individual patch history only.\n\nThat's true, but you can use a 'git tag' command to mark the whole\nstack as something useful and this would include the state of all the\npatches on the stack. This would be a whole stack history, not\nindividual patch history. Maybe we should implement this as well (or\nmaybe only this).\n\nAnyway, I wasn't sure that's the right implementation and that's why I\ndidn't include Chuck's patch yet.\n\n--\nCatalin\n"},{"id":"10934","messageId":"b0943d9e0511010929u22b33e4el@mail.gmail.com","threadId":"2279","inReplyTo":"20051101141149.GA26847@watt.suse.com","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T17:29:19Z","receivedAt":"2005-11-01T17:29:19Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Chris Mason wrote:\n> On Tue, Nov 01, 2005 at 10:08:04AM +0100, Petr Baudis wrote:\n> > Did anyone do any current detailed comparison between hg mq and StGIT?\n>\n> I don't think so, but I'll give it a rough try. I have not used stgit\n> extensively, so please correct any mistakes below. Most of the\n> differences center around the ways we store patches.\n\nThanks for this comparison. It is correct.\n\n> mq is closer to quilt. The patches are stored as patches, and hg qpush\n> is very similar to importing a patch. This means metadata must be\n> stored at the top of the patch in some form the import code can\n> understand (it tries to be smart about this).\n\nThe problem with this is allowing people to modify the patch directly\n(with vi). This would make it difficult to do a three-way merge\nwithout either losing the direct changes or simply failing to apply a\nmodified patch to its old base (I thought about using patches as an\noptimisation but after some benchmarking found that \"git-diff-tree |\ngit-apply\" is fast enough and most of the time when pushing is\ncalculating the sha1 hash of the resulting index file).\n\n> hg qrefresh will update the patch file, so the patch is always up to\n> date wrt to the hg repo.\n\nChuck, I think, has a patch to automatically export the patch when\npushing or refreshing. With the latest StGIT snapshot, the tool\nreports if the patch was modified during push and can only be exported\nin this case (the way it detects this is by assuming that if git-apply\nis successful, the patch is unmodified since no fuzzy applying is\naccepted; the fall back to three-way merge just reports the patch as\nmodified).\n\n> You can import/export patches with hg commands, or by copying patches\n> into/from the .hg/patches directory. This also means you can take a\n> quilt patch dir, copy it into .hg/patches and just start using mq.\n\nAs I said, you might have problems with implementing a three-way merge.\n\n> I'm not sure if stgit has some form of annotate, but it's a nice way to\n> find out which patch changed a given loc in hg/mq.\n\nThere is git-whatchanged which also reports the StGIT patches applied\nonto the stack. But there is no command similar to 'quilt patches'\nyet.\n\n--\nCatalin\n"},{"id":"10936","messageId":"b0943d9e0511010934m8d32eb2i@mail.gmail.com","threadId":"2279","inReplyTo":"20051101101004.GD11618@pasky.or.cz","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T17:34:43Z","receivedAt":"2005-11-01T17:34:43Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Petr Baudis wrote:\n> Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter\n> where Catalin Marinas told me that...\n> > That's not too far away. Chuck Lever has a patch (and there were some\n> > other discussions in the past) for tracking the history of a patch.\n> > Basically, there would be another commit object, not reachable from\n> > HEAD but only via an StGIT command, which would chain all the versions\n> > of a patch. You would be able to view them with gitk for example.\n>\n> Perhaps you could emulate the topical branches - one patch == one head.\n> E.g. for patch foo-bar on branch 'master', you would create head\n> master/foo-bar, etc.\n\nThe patches need to be chained so a top patch would also refer to the\npreviously applied patches since they are its base. Anyway, I don't\nlike adding too many files to the refs/heads directory.\n\n> > My main issue was whether we should store every state resulted from a\n> > refresh or use a separate command (somebody suggested 'freeze') to\n> > mark the states that should be preserved in the history. Chuck's patch\n> > implements the first. The drawback is that a future 'stg prune'\n> > command would not be able to remove the history and some states of the\n> > patch might not be useful (there are times when I do a refresh only to\n> > pop the patch and modify a different one, without any logical meaning\n> > for the state of the patch).\n>\n> I'd prefer the snapshotting being done in refresh anyway. Perhaps you\n> would be asked for log message when you refresh by default, but when you\n> refresh -n or something, only a temporary commit would be created and\n> next refresh would mutate it instead of creating another commit.\n\nThe refresh -n should be the default and maybe just specifying an\noption when you want to add a comment to that commit. But, by mutating\nthe temporary commit, wouldn't this mean that you lose the refresh\nhistory?\n\n> Anyway, \"freeze\" is confusing. Perhaps \"snapshot\" if anything...\n\nYou are right.\n\n--\nCatalin\n"},{"id":"10935","messageId":"20051101173502.GA16528@pasky.or.cz","threadId":"2279","inReplyTo":"20051101161730.GV11488@ca-server1.us.oracle.com","subject":"Re: git versus CVS (versus bk)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T17:35:02Z","receivedAt":"2005-11-01T17:35:02Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 01, 2005 at 05:17:30PM CET, I got a letter\nwhere Joel Becker told me that...\n> On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:\n> > Personally, from my POV it is the intended mode of development only if\n> > you keep strictly topical branches (a single logical change and fixes of\n> > it on top of that). Otherwise, this is horrid because it loses the\n> > _precious_ history and bundles us different changes to a single commit,\n> > which is one of the thing that are wrong on CVS/SVN merging.\n> \n> \tHere we have the \"precious\" history vs the \"throwaway\" history\n> argument again. You are correct, this does look like CVS/Subversion\n> merging. But I'm quite capable of keeping my patches single-topic.\n> Anything that requires multiple patches in a logical separation still\n> needs that extra love.\n\nWell, ok, so I assume you are indeed using strictly topical branches.\n.\n\n> > That said, with a big warning, I would be willing to do something like\n> > cg-merge -s and cg-update -s (s as squash), with a big warning that this\n> \n> \tWouldn't it be cg-pull? I guess I'm not conversant enough of\n> all ways to merge branches in cogito.\n\ncg-pull just fetches stuff, no merging done.\n\nOk, in theory you do not actually need to fetch the intermediate history\nin case you are going to squash (unless you are going to default the\nfinal commit message to concatenation of the intermediate ones), but\narranging that would not be easy to arrange with the current git tools,\nI think. And neither feasible. But actually, I would like to do\nsomething like this later, support for CVS/SVN-like tracking by always\nhaving only the latest tree and no intermediate states, so that people\nwho just want to run the latest and want to do no development are not\nforced to download anything useless for them.\n\n> > is suitable only for topical branches. And I think it'd be still much\n> > better to spend the work making StGIT able to track history of changes\n> > to a particular patch.\n> \n> \tI like quilt for certain work, and what I read from you and\n> Caitlin makes me interested in StGIT for those large changes that\n> require split-out patches. But for simple tasks, I just want to use the\n> SCM, you know?\n\nWell, if you are already going to deform the history, StGIT (able to\ntrack patch history) is just the best tool for that.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10938","messageId":"20051101175905.GC26847@watt.suse.com","threadId":"2279","inReplyTo":"b0943d9e0511010929u22b33e4el@mail.gmail.com","subject":"Re: hgmq vs. StGIT","fromName":"Chris Mason","fromEmail":"mason@suse.com","sentAt":"2005-11-01T17:59:05Z","receivedAt":"2005-11-01T17:59:05Z","isPatch":false,"sender":{"key":"mason@suse.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 05:29:19PM +0000, Catalin Marinas wrote:\n> On 01/11/05, Chris Mason wrote:\n> > mq is closer to quilt. The patches are stored as patches, and hg qpush\n> > is very similar to importing a patch. This means metadata must be\n> > stored at the top of the patch in some form the import code can\n> > understand (it tries to be smart about this).\n> \n> The problem with this is allowing people to modify the patch directly\n> (with vi). This would make it difficult to do a three-way merge\n> without either losing the direct changes or simply failing to apply a\n> modified patch to its old base (I thought about using patches as an\n> optimisation but after some benchmarking found that \"git-diff-tree |\n> git-apply\" is fast enough and most of the time when pushing is\n> calculating the sha1 hash of the resulting index file).\n\nThe three way merge is still possible even if someone hand edits the\npatch. For a three way merge, you just need to know the parent revision\nof the change you want to merge. parent can mean the revision in the\nrepository that precedes this patch (mq stores this information, just\nnot in the patch), or it can mean any revision where the patch applies\ncleanly.\n\nBoth approaches (mq vs stgit) have advantages...you can get roughly the same\nfunctionality either way.\n\n-chris\n"},{"id":"10939","messageId":"20051101181352.GD26847@watt.suse.com","threadId":"2279","inReplyTo":"b0943d9e0511010918ob2dbcfcv@mail.gmail.com","subject":"Re: hgmq vs. StGIT","fromName":"Chris Mason","fromEmail":"mason@suse.com","sentAt":"2005-11-01T18:13:52Z","receivedAt":"2005-11-01T18:13:52Z","isPatch":false,"sender":{"key":"mason@suse.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 05:18:49PM +0000, Catalin Marinas wrote:\n> On 01/11/05, Chris Mason wrote:\n> \n> That's true, but you can use a 'git tag' command to mark the whole\n> stack as something useful and this would include the state of all the\n> patches on the stack. This would be a whole stack history, not\n> individual patch history. Maybe we should implement this as well (or\n> maybe only this).\n> \n> Anyway, I wasn't sure that's the right implementation and that's why I\n> didn't include Chuck's patch yet.\n\nI would suggest just putting the .git/patches directory under revision\ncontrol. If you make it a head in git and then add helper functions so\nthat common operations are easy to do, you won't be reimplementing the\nwhole SCM wheel just for patches.\n\nFor example:\n\nstg commit-patch-tree:\n does git-write-tree and git-commit-tree on .git/patches\n\nstg checkout-patches sha1:\n updates .git/patches to a given patch commit\n\nstg diff-patches [-p] [-f]:\n by default this does the same as git-diff-tree\n -p, read the patch commit objects and diff the patch files\n -f, read the patch commit objects and diff the source files\n \nThe command names could be better, but the idea is to make commits that\nchange the state of your patch tree. Later on, you'll be able to find the\none commit where you added 6 patches, or the one commit where you\nadapted the whole tree to some new feature.\n\nMore importantly, you can reuse gitk and all of the other history\nfunctionality in the SCM.\n\n-chris\n"},{"id":"10948","messageId":"b0943d9e0511011322q56812522v@mail.gmail.com","threadId":"2279","inReplyTo":"20051101175905.GC26847@watt.suse.com","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T21:22:44Z","receivedAt":"2005-11-01T21:22:44Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Chris Mason wrote:\n> The three way merge is still possible even if someone hand edits the\n> patch. For a three way merge, you just need to know the parent revision\n> of the change you want to merge. parent can mean the revision in the\n> repository that precedes this patch (mq stores this information, just\n> not in the patch), or it can mean any revision where the patch applies\n> cleanly.\n\nYes, but what I meant is that someone may modify the patch in a way\nthat it is no longer appliable to its parent or to any other revision\nin the tree. A this point, a three-way merge is no longer possible\n(but, well, if someone modifies the patches this way should be able to\ncope with the consequences).\n\n> Both approaches (mq vs stgit) have advantages...you can get roughly the same\n> functionality either way.\n\nYes, you are right. The big difference is the underlying tool (hg or git).\n\n--\nCatalin\n"},{"id":"10949","messageId":"b0943d9e0511011330v7045c568u@mail.gmail.com","threadId":"2279","inReplyTo":"20051101181352.GD26847@watt.suse.com","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-01T21:30:06Z","receivedAt":"2005-11-01T21:30:06Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 01/11/05, Chris Mason wrote:\n> I would suggest just putting the .git/patches directory under revision\n> control.\n\nPutting them under a separate revisions repository, i.e. having a\n.git/patches/,git directory? Otherwise there would be some problems\nwith the modified files automatically included in a patch.\n\n> More importantly, you can reuse gitk and all of the other history\n> functionality in the SCM.\n\nDoing it the above way wouldn't be of much help with gitk. You would\nget files like .git/patches/master/patchX/top etc. under revision\ncontrol which only contain some hash strings, not meaningful. With GIT\nyou have the advantage of being able to specify the DAG structure. It\nis pretty simple to just link the commit objects corresponding to a\npatch into a DAG and using gitk would allow you to navigate through\nthe history and also look at the diff itself.\n\n--\nCatalin\n"},{"id":"11016","messageId":"20051102154108.GM26847@watt.suse.com","threadId":"2279","inReplyTo":"b0943d9e0511011330v7045c568u@mail.gmail.com","subject":"Re: hgmq vs. StGIT","fromName":"Chris Mason","fromEmail":"mason@suse.com","sentAt":"2005-11-02T15:41:08Z","receivedAt":"2005-11-02T15:41:08Z","isPatch":false,"sender":{"key":"mason@suse.com","avatar":null},"body":"On Tue, Nov 01, 2005 at 09:30:06PM +0000, Catalin Marinas wrote:\n> On 01/11/05, Chris Mason wrote:\n> > I would suggest just putting the .git/patches directory under revision\n> > control.\n> \n> Putting them under a separate revisions repository, i.e. having a\n> .git/patches/,git directory? Otherwise there would be some problems\n> with the modified files automatically included in a patch.\n> \n> > More importantly, you can reuse gitk and all of the other history\n> > functionality in the SCM.\n> \n> Doing it the above way wouldn't be of much help with gitk. You would\n> get files like .git/patches/master/patchX/top etc. under revision\n> control which only contain some hash strings, not meaningful. With GIT\n> you have the advantage of being able to specify the DAG structure. It\n> is pretty simple to just link the commit objects corresponding to a\n> patch into a DAG and using gitk would allow you to navigate through\n> the history and also look at the diff itself.\n\nI think we're talking past each other a little, partially because\nI'm not sure exactly what features you want from revision control on the\npatches.\n\nBut, my suggestion is to remember that once you add some sort of\nrevision control, people are going to want all of the features they are\nused to with git/hg/their favorite SCM. You'll probably get better\nresults if you patch git to your needs then if you try to reimplement\nthings all over again. \n\n-chris\n"},{"id":"11174","messageId":"b0943d9e0511051223g74c2be43h@mail.gmail.com","threadId":"2279","inReplyTo":"20051102154108.GM26847@watt.suse.com","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-05T20:23:33Z","receivedAt":"2005-11-05T20:23:33Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Sorry for the delay in replying.\n\nOn 02/11/05, Chris Mason wrote:\n> I think we're talking past each other a little, partially because\n> I'm not sure exactly what features you want from revision control on the\n> patches.\n\nThat's unclear for me too :-). I would like to have a way of checking\nthe changes to individual patches, just to be able to go back if some\nchanges broke it. It's also useful to have some kind of revision\ncontrol for the whole stack, but this can be achieved with tags at the\nmoment. What I usually do is export the series when I'm happy with it\nand keep that directory safe. I could add revision control for the\ndirectory containing the exported series but this would be somehow\noutside StGIT.\n\n> But, my suggestion is to remember that once you add some sort of\n> revision control, people are going to want all of the features they are\n> used to with git/hg/their favorite SCM. You'll probably get better\n> results if you patch git to your needs then if you try to reimplement\n> things all over again.\n\nThat's true. I think that people who want a full revision control of\nthe patches should rather use separate branches instead of stacked\npatches. It's indeed more convenient to be able to add or remove\nfeatures with push/pop but providing yet another SCM layer on top of\nthese would make the tool hard to understand (and maybe make Quilt\nfans run away from it).\n\nThe current StGIT features are enough for my needs but I'll\naccept/implement new features based on others' requirements.\n\nBTW, the latest StGIT snapshot has support for a 'patches' command\nwhich shows the patches modifying a file or set of files (that's\nbecause I needed this feature recently).\n\n--\nCatalin\n"},{"id":"11278","messageId":"20051107225652.GW1431@pasky.or.cz","threadId":"2279","inReplyTo":"20051101091533.GB11618@pasky.or.cz","subject":"Re: git versus CVS (versus bk)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-07T22:56:52Z","receivedAt":"2005-11-07T22:56:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter\nwhere Petr Baudis told me that...\n> That said, with a big warning, I would be willing to do something like\n> cg-merge -s and cg-update -s (s as squash), with a big warning that this\n> is suitable only for topical branches. And I think it'd be still much\n> better to spend the work making StGIT able to track history of changes\n> to a particular patch.\n\nFWIW, cg-merge -s and cg-update -s is supported now.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11316","messageId":"200511081150.10867.Josef.Weidendorfer@gmx.de","threadId":"2279","inReplyTo":"20051107225652.GW1431@pasky.or.cz","subject":"Re: git versus CVS (versus bk)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-08T10:50:10Z","receivedAt":"2005-11-08T10:50:10Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 07 November 2005 23:56, Petr Baudis wrote:\n> Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter\n> where Petr Baudis told me that...\n> > That said, with a big warning, I would be willing to do something like\n> > cg-merge -s and cg-update -s (s as squash)\n> ...\n> FWIW, cg-merge -s and cg-update -s is supported now.\n\nThe -s option of git merge is about choosing a strategy.\nHow can I choose the \"recursive\" strategy with cg-merge?\nSome consistency would be good here.\n\nJosef\n"},{"id":"11321","messageId":"20051108120426.GB1431@pasky.or.cz","threadId":"2279","inReplyTo":"200511081150.10867.Josef.Weidendorfer@gmx.de","subject":"Re: git versus CVS (versus bk)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-08T12:04:26Z","receivedAt":"2005-11-08T12:04:26Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 08, 2005 at 11:50:10AM CET, I got a letter\nwhere Josef Weidendorfer told me that...\n> On Monday 07 November 2005 23:56, Petr Baudis wrote:\n> > Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter\n> > where Petr Baudis told me that...\n> > > That said, with a big warning, I would be willing to do something like\n> > > cg-merge -s and cg-update -s (s as squash)\n> > ...\n> > FWIW, cg-merge -s and cg-update -s is supported now.\n> \n> The -s option of git merge is about choosing a strategy.\n> How can I choose the \"recursive\" strategy with cg-merge?\n> Some consistency would be good here.\n\nGood point. You can't now, but you should be able to in the future.\nI renamed this from -s to --squash.\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11430","messageId":"20051109233255.GI30496@pasky.or.cz","threadId":"2279","inReplyTo":"b0943d9e0511051223g74c2be43h@mail.gmail.com","subject":"Re: hgmq vs. StGIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T23:32:55Z","receivedAt":"2005-11-09T23:32:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter\nwhere Catalin Marinas said that...\n> I would like to have a way of checking the changes to individual\n> patches, just to be able to go back if some changes broke it.\n\nYes, that would be nice to have as well (although in general I lean to\nrecording the whole stack now). Model scenario:\n\nA night city, the snow slowly falling. Approaching the roofs covered in\nwhite and illuminated by the yellow street lighting, dark windows - but\none dimly glowing, a computer screen inside. Close-up on a hacker:\n$EDITOR opened, lost deep in hack mode, fingers dancing over the\nkeyboard. Dreamy-monumental music in the background.\n\nStGIT user, only part of the patches in stack, and the rest depends on\nthe one currently edited, and I want to record my work on this one.\nI can either:\n\n(i) Just keep per-patch history only.\n\n(ii) Keep _both_ per-patch and per-stack history (since I don't want to\nrecord the stack when I have to keep some patches out of it - the\nhistory would look like randomly removing and adding tons of patches,\nand jumping around would be difficult because of this too).\n\n(iii) Keep per-patchlist history - do not actually record only our\ncurrent stack, but all the patches StGIT knows about. The patches\ndepending on the one currently being changed will not be in consistent\nstate, but that's tough. Actually, this seems to be the most viable\nstrategy. One question is whether to record if some patch is actually\napplied right now or not (I'd say don't record it since you again have\nthe \"bouncing problem\" otherwise).\n\nIdeas?\n\n> It's also useful to have some kind of revision control for the whole\n> stack, but this can be achieved with tags at the moment.\n\nYes, now let's sequence the tags... ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11442","messageId":"20051110000804.GL12459@elf.ucw.cz","threadId":"2279","inReplyTo":"20051109233255.GI30496@pasky.or.cz","subject":"Re: hgmq vs. StGIT","fromName":"Pavel Machek","fromEmail":"pavel@suse.cz","sentAt":"2005-11-10T00:08:04Z","receivedAt":"2005-11-10T00:08:04Z","isPatch":false,"sender":{"key":"pavel@suse.cz","avatar":null},"body":"Hi!\n\n> Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter\n> where Catalin Marinas said that...\n...\n> A night city, the snow slowly falling. Approaching the roofs covered in\n> white and illuminated by the yellow street lighting, dark windows - but\n> one dimly glowing, a computer screen inside. Close-up on a hacker:\n> $EDITOR opened, lost deep in hack mode, fingers dancing over the\n> keyboard. Dreamy-monumental music in the background.\n> \n> StGIT user, only part of the patches in stack, and the rest depends on\n> the one currently edited, and I want to record my work on this one.\n> I can either:\n\nAre you sure you are git hacker? Maybe you should have been fiction\nwriter :-).\n\n> (i) Just keep per-patch history only.\n> \n> (ii) Keep _both_ per-patch and per-stack history (since I don't want to\n> record the stack when I have to keep some patches out of it - the\n> history would look like randomly removing and adding tons of patches,\n> and jumping around would be difficult because of this too).\n> \n> (iii) Keep per-patchlist history - do not actually record only our\n> current stack, but all the patches StGIT knows about. The patches\n> depending on the one currently being changed will not be in consistent\n> state, but that's tough. Actually, this seems to be the most viable\n> strategy. One question is whether to record if some patch is actually\n> applied right now or not (I'd say don't record it since you again have\n> the \"bouncing problem\" otherwise).\n\nI do not know if ii or iii is better, but please *do* record what\npatches were applied at what moment. That is useful info. \"I'd like to\ngo back to know working configuration\". If I do not know what patches\nwere applied at what moment, going back to working config is hard to\ndo.\n\t\t\t\t\t\t\t\tPavel\n-- \nThanks, Sharp!\n"},{"id":"11480","messageId":"b0943d9e0511100820h2f10a011g@mail.gmail.com","threadId":"2279","inReplyTo":"20051109233255.GI30496@pasky.or.cz","subject":"Re: hgmq vs. StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-10T16:20:03Z","receivedAt":"2005-11-10T16:20:03Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 09/11/05, Petr Baudis wrote:\n> A night city, the snow slowly falling. Approaching the roofs covered in\n> white and illuminated by the yellow street lighting, dark windows - but\n> one dimly glowing, a computer screen inside. Close-up on a hacker:\n> $EDITOR opened, lost deep in hack mode, fingers dancing over the\n> keyboard. Dreamy-monumental music in the background.\n\nI agree with Pavel here :-)\n\n> StGIT user, only part of the patches in stack, and the rest depends on\n> the one currently edited, and I want to record my work on this one.\n> I can either:\n>\n> (i) Just keep per-patch history only.\n\nThat's probably the simplest.\n\n> (ii) Keep _both_ per-patch and per-stack history (since I don't want to\n> record the stack when I have to keep some patches out of it - the\n> history would look like randomly removing and adding tons of patches,\n> and jumping around would be difficult because of this too).\n\nIt happens to me to keep some patches popped which aren't really part\nof the stack (i.e. splitting a big patch, I still keep it in the\nunapplied patches to push it later and check what was left after\nsplitting). From this point of view, (ii) would be better but with the\ndrawback that you need to have a valid stack with all the patches\npushed.\n\n> (iii) Keep per-patchlist history - do not actually record only our\n> current stack, but all the patches StGIT knows about. The patches\n> depending on the one currently being changed will not be in consistent\n> state, but that's tough. Actually, this seems to be the most viable\n> strategy. One question is whether to record if some patch is actually\n> applied right now or not (I'd say don't record it since you again have\n> the \"bouncing problem\" otherwise).\n\n(iii) is the most comprehensive method and, as Pavel said, we should\nrecord what patches were applied or not and reproduce them exactly\nwhen retrieving a different state.\n\nAnother big problem is the base of the stack, which can change. Would\nretrieving an old state of the stack also restore the old the base? I\nthink it should and its up to the user to rebase it.\n\nA simple way to partially achieve (iii) is to extend the existing\n'branch' command to clone the whole series into a new one, including\nall the patches. The problem with this approach is that there is no\ntemporal relation between branches.\n\nHow would you expect to switch between different states of the stack?\nAs Chris Mason mentioned, once you start doing this people might ask\nfor full SCM features (like diffs between revisions) where the objects\nare stack states. This would complicate StGIT quite a lot.\n\n--\nCatalin\n"}]}