{"thread":{"id":"9591","subject":"Splitting up a changeset","startedAt":"2007-08-20T13:32:11Z","lastAt":"2007-08-20T19:53:51Z","messageCount":4,"participants":["Frank Showman","Adam Roben","Alex Riesen","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51088","messageId":"e1bf234c0708200632g3a2282bfr76863555493d513@mail.gmail.com","threadId":"9591","inReplyTo":null,"subject":"Splitting up a changeset","fromName":"Frank Showman","fromEmail":"fshowman@googlemail.com","sentAt":"2007-08-20T13:32:11Z","receivedAt":"2007-08-20T13:32:11Z","isPatch":false,"sender":{"key":"fshowman@googlemail.com","avatar":null},"body":"What I really want to do is merge a couple of files from a changeset\nat a time. Given that GIT doesn't track files, the only sensible way\nto do that seems to split up the changeset (I want GIT to track the\nmerges) and then merge (cherry pick) the split up stuff.\n\nIs there some (reasonably simple) way to do that? What happens to\nremote repositories that already have the big original changeset (and\npossibly changes based on it)?\n\n-- Frank\n"},{"id":"51094","messageId":"F75C083B-2E70-4CD0-8F4B-F207E3333D8E@apple.com","threadId":"9591","inReplyTo":"e1bf234c0708200632g3a2282bfr76863555493d513@mail.gmail.com","subject":"Re: Splitting up a changeset","fromName":"Adam Roben","fromEmail":"aroben@apple.com","sentAt":"2007-08-20T17:11:11Z","receivedAt":"2007-08-20T17:11:11Z","isPatch":false,"sender":{"key":"aroben@apple.com","avatar":"https://gravatar.com/avatar/9d3697e1de53890adf241331f4b970bdd2b18962b2ff0b8028ebb00e085807f8?d=mp&s=160"},"body":"On Aug 20, 2007, at 6:32 AM, Frank Showman wrote:\n\n> What I really want to do is merge a couple of files from a changeset\n> at a time. Given that GIT doesn't track files, the only sensible way\n> to do that seems to split up the changeset (I want GIT to track the\n> merges) and then merge (cherry pick) the split up stuff.\n>\n> Is there some (reasonably simple) way to do that?\n\n    One way I've done this in the past is like this:\n\ngit cherry-pick -n <rev-to-split-up>\ngit reset HEAD\ngit add <first-batch-of-files>\ngit commit\ngit add <next-batch-of-files>\ngit commit\n...\n\n-Adam\n"},{"id":"51113","messageId":"20070820193128.GC5544@steel.home","threadId":"9591","inReplyTo":"e1bf234c0708200632g3a2282bfr76863555493d513@mail.gmail.com","subject":"Re: Splitting up a changeset","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-08-20T19:31:28Z","receivedAt":"2007-08-20T19:31:28Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Frank Showman, Mon, Aug 20, 2007 15:32:11 +0200:\n> What I really want to do is merge a couple of files from a changeset\n> at a time. Given that GIT doesn't track files, the only sensible way\n> to do that seems to split up the changeset (I want GIT to track the\n> merges) and then merge (cherry pick) the split up stuff.\n> \n> Is there some (reasonably simple) way to do that?\n\nyes. This, for example, will make two commits out of one:\n\n    $ git checkout -b split-the-change the-change^\n    $ git checkout the-change -- files-you-want-in-commit1...\n    $ git commit -c the-change\n    $ git checkout the-change -- files-you-want-in-commit2...\n    $ git commit -c the-change\n\nIf you want also split the changes _in_ the files, you'll have to edit\nthem after that \"git checkout the-change -- files...\".\n\nThe result is in branch starting where the-change was at. You can\ndecide now what you want to do with the commits.\n\n> What happens to remote repositories that already have the big\n> original changeset (and possibly changes based on it)?\n\nIf someone (or something) has already fetched, pulled, cloned or\notherwise copied them, you basically can't do anything anymore.\nIt is a thing you fundamentally cannot do, unless you're prepared to\ndeal with consequences. Not hard, but can be unexpected for some.\n"},{"id":"51116","messageId":"20070820195351.GF8542@efreet.light.src","threadId":"9591","inReplyTo":"20070820193128.GC5544@steel.home","subject":"Re: Splitting up a changeset","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-20T19:53:51Z","receivedAt":"2007-08-20T19:53:51Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 20, 2007 at 21:31:28 +0200, Alex Riesen wrote:\n> Frank Showman, Mon, Aug 20, 2007 15:32:11 +0200:\n> > What happens to remote repositories that already have the big\n> > original changeset (and possibly changes based on it)?\n> \n> If someone (or something) has already fetched, pulled, cloned or\n> otherwise copied them, you basically can't do anything anymore.\n> It is a thing you fundamentally cannot do, unless you're prepared to\n> deal with consequences. Not hard, but can be unexpected for some.\n\nIf something might already be based on the unsplit change, you probably want\nto make the last commit of the split be a merge from the unsplit. Merge will\nnotice that the changes on both sides are the same and resolve them cleanly\nand any further merges won't see them as differences.\n\nIf only you or only people you know may have changes based on unsplit, you\ncan rebase those changes to split for slightly simpler history.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"}]}