{"thread":{"id":"14197","subject":"Re: An alternate model for preparing partial commits","startedAt":"2008-06-28T01:23:06Z","lastAt":"2008-06-28T01:23:06Z","messageCount":1,"participants":["Theodore Tso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81526","messageId":"20080628012305.GC15463@mit.edu","threadId":"14197","inReplyTo":null,"subject":"Re: An alternate model for preparing partial commits","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-06-28T01:23:06Z","receivedAt":"2008-06-28T01:23:06Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Jun 27, 2008 at 08:51:41PM -0000, David Jeske wrote:\n> -- Jakub Narebski wrote:\n> > git rebase --interactive?\n> > Any patch management interface (StGIT, Guilt)?\n> \n> Yes, as I said, that set of operations can be performed with git today.\n> \n> What git can't do, is let me \"supercede\" the old DAG-subset, so\n> people I shared them with can get my new changes without hurting\n> their world. Currently git seems to rely on the idea that \"if you\n> accept changes into your tree that will be later rebased, it's up to\n> you to figure it out\". I don't see why that is the case\n\nBecause it's fundamentally hard and fraught with danger --- especially\nsince with git-rebase --interactive you actually can *edit* an\nintervening patch, so commits that are based off of a rebased branch\nhave absolutely no guarantee of correctly applying against the rebased\nbranch.\n\nIf they do apply cleanly, you can use git rebase --onto, but the\npossibility of merge conflicts are endless.\n\nThe general workflow here is that you simply don't share your git\nstate until it's been refactored and you're positive that it you've\ngotten it right.  Or if you do share, it you do so in a branch where\nyou tell people --- don't base work off of this!  (i.e., a \"pu\" branch\nlike git has.)\n\nAs I said earlier, premature sharing is highly over-rated.  And having\npeople develop against an unstable branch is just extra work for them\nanyway.  So commit frequently, and if you want to backup your local\nhard drive, push regularly to your own private git repository located\noff-machine.  Just don't ask people base any branches off your private\nbranch until you're ready to publish it in a form after which you\ndon't do rebase operations.  This works quite well for many projects\nand many developers.\n\n\t\t\t\t\t\t- Ted\n"}]}