{"thread":{"id":"1505","subject":"sending changesets from the middle of a git tree","startedAt":"2005-08-14T03:35:50Z","lastAt":"2005-08-17T00:55:51Z","messageCount":12,"participants":["Steve French","Ryan Anderson","Linus Torvalds","Junio C Hamano","Petr Baudis","Catalin Marinas","Wolfgang Denk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7234","messageId":"42FEBC16.9050309@austin.rr.com","threadId":"1505","inReplyTo":null,"subject":"sending changesets from the middle of a git tree","fromName":"Steve French","fromEmail":"smfrench@austin.rr.com","sentAt":"2005-08-14T03:35:50Z","receivedAt":"2005-08-14T03:35:50Z","isPatch":false,"sender":{"key":"smfrench@austin.rr.com","avatar":null},"body":"Just to confirm a recent answer to questions on lkml ...\n\n1) There is no way to send a particular changeset from the \"middle\" of a \nset from one tree to another, without exporting it as a patch or \nrebuilding a new git tree. I have two changesets that, after testing \nlast week, I now consider more important to send upstream than the few \nearlier and later changesets. If I export those two changesets as \npatches, and send them on. presumably I lose the changset comments etc. \nand then when the upstream tree is merged back, it might look a little \nodd in the changeset history.\n\n2) There is no way to update the comment field of a changeset after it \ngoes in (e.g. to add a bugzilla bug number for a bug that was opened \njust after the fix went in).\n\n3) There is no way to do a test commit of an individual changeset \nagainst a specified tree (to make sure it would still merge cleanly, \nautomatically).\n\nAre there easier ways to do any of these?\n"},{"id":"7235","messageId":"20050814040233.GC6844@mythryan2.michonline.com","threadId":"1505","inReplyTo":"42FEBC16.9050309@austin.rr.com","subject":"Re: sending changesets from the middle of a git tree","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-08-14T04:02:33Z","receivedAt":"2005-08-14T04:02:33Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:\n> Just to confirm a recent answer to questions on lkml ...\n> \n> 1) There is no way to send a particular changeset from the \"middle\" of a \n> set from one tree to another, without exporting it as a patch or \n> rebuilding a new git tree. I have two changesets that, after testing \n> last week, I now consider more important to send upstream than the few \n> earlier and later changesets. If I export those two changesets as \n> patches, and send them on. presumably I lose the changset comments etc. \n> and then when the upstream tree is merged back, it might look a little \n> odd in the changeset history.\n\nYou can keep most of the metadata you want with \"git format-patch\".\n\nExtract the changes you need, mail them off.\n\nWhen you later merge things back together, it should be a trivial merge,\nhopefully.\n\n> 2) There is no way to update the comment field of a changeset after it \n> goes in (e.g. to add a bugzilla bug number for a bug that was opened \n> just after the fix went in).\n\nNo, a commit is immutable. You can use \"git format-patch\" to rebase things if\nyou need. I prefer to use \"git format-patch --mbox\", edit what I need\nto, then use git-applymbox to rebase it all against a clean tree.\n\n> 3) There is no way to do a test commit of an individual changeset \n> against a specified tree (to make sure it would still merge cleanly, \n> automatically).\n\nNot sure on this one - in this case, it almost sounds like you want the\nfeature set of StGit, and/or quilt. (If \"quilt push\" succeeds, clearly\nit still merges cleanly.)\n\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"7236","messageId":"Pine.LNX.4.58.0508132155100.3553@g5.osdl.org","threadId":"1505","inReplyTo":"42FEBC16.9050309@austin.rr.com","subject":"Re: sending changesets from the middle of a git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-14T05:03:48Z","receivedAt":"2005-08-14T05:03:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 13 Aug 2005, Steve French wrote:\n> \n> 1) There is no way to send a particular changeset from the \"middle\" of a \n> set from one tree to another, without exporting it as a patch or \n> rebuilding a new git tree.\n\nCorrect.\n\n> If I export those two changesets as patches, and send them on.\n> presumably I lose the changset comments etc.\n\nWell, you can export them with \"git send-email\" and you won't be losing \nany comments.\n\nAlternatively, use \"git cherry\", which helps re-order the commits in your\ntree. They'll be _new_ commits, but they'll have the contents moved over. \nJunio, maybe you want to talk about how you move patches from your \"pu\" \nbranch to the real branches.\n\n> and then when the upstream tree is merged back, it might look a little\n> odd in the changeset history.\n\nWell, you'll end up having the same change twice. It happens. Or if you \njust redo your tree as a separate branch, you can reorder things so that \nyou don't have them twice at all.\n\n> 2) There is no way to update the comment field of a changeset after it \n> goes in (e.g. to add a bugzilla bug number for a bug that was opened \n> just after the fix went in).\n\nThat's correct. Same things apply: you can move a patch over, and create a \nnew one with a modified comment, but basically the _old_ commit will be \nimmutable.\n\nThe good news is that it means that nobody else can change what you said \nor did either. \n\n> 3) There is no way to do a test commit of an individual changeset \n> against a specified tree (to make sure it would still merge cleanly, \n> automatically).\n\nOh, sure, that's certainly very possible, and the git cherry stuff even\nhelps you do it. Or use \"git-apply --check\" to just see if a patch\napplies and do your own scripts. \n\n\t\tLinus\n"},{"id":"7237","messageId":"Pine.LNX.4.58.0508132204050.3553@g5.osdl.org","threadId":"1505","inReplyTo":"Pine.LNX.4.58.0508132155100.3553@g5.osdl.org","subject":"Re: sending changesets from the middle of a git tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-14T05:16:02Z","receivedAt":"2005-08-14T05:16:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 13 Aug 2005, Linus Torvalds wrote:\n\n> That's correct. Same things apply: you can move a patch over, and create a \n> new one with a modified comment, but basically the _old_ commit will be \n> immutable.\n\nLet me clarify.\n\nYou can entirely _drop_ old branches, so commits may be immutable, but\nnothing forces you to keep them. Of course, when you drop a commit, you'll \nalways end up dropping all the commits that depended on it, and if you \nactually got somebody else to pull that commit you can't drop it from \n_their_ repository, but undoing things is not impossible.\n\nFor example, let's say that you've made a mess of things: you've committed\nthree commits \"old->a->b->c\", and you notice that \"a\" was broken, but you\nwant to save \"b\" and \"c\". What you can do is\n\n\t# Create a branch \"broken\" that is the current code\n\t# for reference\n\tgit branch broken\n\n\t# Reset the main branch to three parents back: this \n\t# effectively undoes the three top commits\n\tgit reset HEAD^^^\n\tgit checkout -f\n\n\t# Check the result visually to make sure you know what's\n\t# going on\n\tgitk --all\n\n\t# Re-apply the two top ones from \"broken\"\n\t#\n\t# First \"parent of broken\" (aka b):\n\tgit-diff-tree -p broken^ | git-apply --index\n\tgit commit --reedit=broken^\n\n\t# Then \"top of broken\" (aka c):\n\tgit-diff-tree -p broken | git-apply --index\n\tgit commit --reedit=broken\n\nand you've now re-applied (and possibly edited the comments) the two\ncommits b/c, and commit \"a\" is basically gone (it still exists in the\n\"broken\" branch, of course).\n\nFinally, check out the end result again:\n\n\t# Look at the new commit history\n\tgitk --all\n\nto see that everything looks sensible.\n\nAnd then, you can just remove the broken branch if you decide you really \ndon't want it:\n\n\t# remove 'broken' branch\n\trm .git/refs/heads/broken\n\n\t# Prune old objects if you're really really sure\n\tgit prune\n\nAnd yeah, I'm sure there are other ways of doing this. And as usual, the \nabove is totally untested, and I just wrote it down in this email, so if \nI've done something wrong, you'll have to figure it out on your own ;)\n\n\t\t\tLinus\n"},{"id":"7239","messageId":"7vhddtdk86.fsf@assigned-by-dhcp.cox.net","threadId":"1505","inReplyTo":"Pine.LNX.4.58.0508132155100.3553@g5.osdl.org","subject":"Re: sending changesets from the middle of a git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-14T07:57:13Z","receivedAt":"2005-08-14T07:57:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> If I export those two changesets as patches, and send them on.\n>> presumably I lose the changset comments etc.\n>\n> Well, you can export them with \"git send-email\" and you won't be losing \n> any comments.\n\nYes, except the command is \"git format-patch\". Not just\ncomments, but \"format-patch --author --date\" generates messages\nthat would help preserving the authorship and original author\ndate information as well.\n\n> Alternatively, use \"git cherry\", which helps re-order the commits in your\n> tree. They'll be _new_ commits, but they'll have the contents moved over. \n\n> Junio, maybe you want to talk about how you move patches from your \"pu\" \n> branch to the real branches.\n\nAs I have mentioned elsewhere, I have been trying not to use\nJIT, my own Porcelain, to make sure that the core-git barebone\nPorcelain is usable.\n\nUnfortunately, this is one area in my workflow that I still\nheavily rely on JIT, because it is so handy. I've kept saying I\ndo not do Porcelain, but I'll make an exception this time, by\ninvitation ;-).\n\nLet's say I have three commits in \"pu\" which are not yet in\n\"master\". I first use \"jit-cherry-snap\" to give myself a ready\naccess to these them:\n\nprompt$ jit-cherry-snap master pu\n* 3: Alternate object pool mechanism updates.\n* 4: Audit rev-parse users.\n* 5: Add cheap local clone '-s' flag to git-clone-script\n\nThis command is a thin wrapper around \"git cherry\". Instead of\ngiving you long SHA1 commit object names, JIT gave a short name\nto them, #3, #4, and #5 (I can say \"git-rev-parse 3\", or even\n\"git-diff-tree 3\", for example). I have to mention that\nx\"alternate object pool\" commit is the oldest (i.e. the one that\nimmediately follows the \"master\" head), #4 is its child, and #5\nis #4's child.\n\nSuppose I have tested the \"pu\" branch to my satisfaction, but\nI would want to hold the commit #3 back (because I promised\nPasky to hold it for a couple of days). But I know #4 and #5\nare good and would like to push them out. Here is what I do:\n\nprompt$ git checkout master\nprompt$ jit-replay 4 5\n*** 4 ***\npatching file git-rebase-script\npatching file git-reset-script\npatching file git-tag-script\n*** 5 ***\npatching file git-clone-script\nprompt$\n\n\"jit-replay\" is essentially this shell scriptlet:\n\n #!/bin/sh\n . git-sh-setup-script || die \"not a git repository\"\n for snap\n do\n snap=$(git-rev-parse --verify \"$snap\") &&\n git-diff-tree -p \"$snap\" | git-apply --index &&\n git commit -C \"$snap\"\n done\n\nThat is, to apply the change in an existing commit, and record\nit with the commit log message, authorship information and\nauthor timestamp from that commit. What I just did is to port\ncommits #4 and #5 on top of the \"master\" branch.\n\nWhat happened so far is this:\n\n * I used to have this commit graph. O is the original \"master\"\n head, P is the original \"pu\" head.\n\n O --> #3 --> #4 --> #5 == P\n\n * I advanced the \"master\" branch, but not along the original\n path that lead to \"pu\" head. Instead, I made a fork:\n\n\n * New \"master\" head\n --> #4'--> #5'\n /\n O --> #3 --> #4 --> #5 == P\n\nAs Linus and Ryan already said, the old history is \"immutable\".\nI did not (actually, could not) touch #3...#5 commits; they are\nstill there. I created two new commit objects #4' and #5'. And\n#5' is now the new \"master\" head.\n\nWhat's left to do is to make sure that I do not lose the change\nin #3. So I rebase the \"pu\" branch to the new \"master\" head.\nThe following sequence does it:\n\nprompt$ git-rev-parse master >.git/refs/heads/pu\nprompt$ git checkout pu\nprompt$ jit-replay 3\n*** 3 ***\npatching file cache.h\npatching file fsck-cache.c\npatching file sha1_file.c\n\nNow, the commit ancestry graph looks like this. \"pu\" head is at\nP', and the original \"pu\" head P is still recorded as the\nsnapshot #5.\n\n new \"master\"\n *head *new \"pu\" head\n --> #4'--> #5'--> #3 == P'\n /\n O --> #3 --> #4 --> #5 == P\n\nAs the last sanity check, I make sure that the resulting \"pu\"\nhead has exactly the same tree as the original \"pu\" head;\nbecause all I did in this example was to shuffle the order of \ncommits, they should exactly match:\n\nprompt$ git diff HEAD..5\nprompt$\n\nAnd they do match. I discard the numbered snapshots, because I\ndo not need them anymore.\n\nprompt$ jit-clean\n\nIt is worth pointing out that this workflow means that \"pu\"\nbranch is just a staging area and if people start pulling from\nand merging with it, things will get messy on the receiving end\n(not my end), so the owner of a frequently rebased branch like\nthis should be very clear about the nature of the branch\nupfront. Saying \"this branch will be frequently rebased\" is\nequivalent of saying \"comments and replacement patches are\nwelcome, but do not merge with it, or you may have hard time\nyourself cleaning _your_ history up later\".\n\nAs I said, I do not do Porcelain, and I would _not_ encourage\npeople to try JIT out at this point. Because I have not had\nenough time to keep it up-to-date and make it take advantage of\nthe recent git-core improvements, some of the parts I did not\ndemonstrate above have still (or have acquired) rough edges that\nI myself know not to touch, but others would by accident and\nburn themselves. What I would eventually do is to take good\npieces and ideas out of JIT and repackage them as part of the\ncore-git barebone Porcelain.\n"},{"id":"7242","messageId":"20050814092757.GP5608@pasky.ji.cz","threadId":"1505","inReplyTo":"7vhddtdk86.fsf@assigned-by-dhcp.cox.net","subject":"Re: sending changesets from the middle of a git tree","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-08-14T09:27:57Z","receivedAt":"2005-08-14T09:27:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> Linus Torvalds writes:\n> > Alternatively, use \"git cherry\", which helps re-order the commits in your\n> > tree. They'll be _new_ commits, but they'll have the contents moved over. \n> \n> > Junio, maybe you want to talk about how you move patches from your \"pu\" \n> > branch to the real branches.\n> \n> As I have mentioned elsewhere, I have been trying not to use\n> JIT, my own Porcelain, to make sure that the core-git barebone\n> Porcelain is usable.\n> \n> Unfortunately, this is one area in my workflow that I still\n> heavily rely on JIT, because it is so handy. I've kept saying I\n> do not do Porcelain, but I'll make an exception this time, by\n> invitation ;-).\n\nActually, wouldn't this be also precisely for what StGIT is intended to?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone. -- Alan Cox\n"},{"id":"7254","messageId":"7vfytc9dzw.fsf@assigned-by-dhcp.cox.net","threadId":"1505","inReplyTo":"20050814092757.GP5608@pasky.ji.cz","subject":"Re: sending changesets from the middle of a git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-15T01:37:39Z","receivedAt":"2005-08-15T01:37:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter\n> where Junio C Hamano told me that...\n>> Linus Torvalds writes:\n>> \n>> > Junio, maybe you want to talk about how you move patches from your \"pu\" \n>> > branch to the real branches.\n>> \n> Actually, wouldn't this be also precisely for what StGIT is intended to?\n\nExactly my feeling. I was sort of waiting for Catalin to speak\nup. With its basing philosophical ancestry on quilt, this is\nthe kind of task StGIT is designed to do.\n\nI just have done a simpler one, this time using only the core\nGIT tools.\n\nI had a handful commits that were ahead of master in pu, and I\nwanted to add some documentation bypassing my usual habit of\nplacing new things in pu first. At the beginning, the commit\nancestry graph looked like this:\n\n *\"pu\" head\n master --> #1 --> #2 --> #3\n\nSo I started from master, made a bunch of edits, and committed:\n\n $ git checkout master\n $ cd Documentation; ed git.txt git-apply-patch-script.txt ...\n $ cd ..; git add Documentation/*.txt\n $ git commit -s -v\n\nNOTE. The -v flag to commit is a handy way to make sure that\nyour additions are not introducing bogusly formatted lines.\n\nAfter the commit, the ancestry graph would look like this:\n\n *\"pu\" head\n master^ --> #1 --> #2 --> #3\n \\\n \\---> master\n\nThe old master is now master^ (the first parent of the master).\nThe new master commit holds my documentation updates.\n\nNow I have to deal with \"pu\" branch.\n\nThis is the kind of situation I used to have all the time when\nLinus was the maintainer and I was a contributor, when you look\nat \"master\" branch being the \"maintainer\" branch, and \"pu\"\nbranch being the \"contributor\" branch. Your work started at the\ntip of the \"maintainer\" branch some time ago, you made a lot of\nprogress in the meantime, and now the maintainer branch has some\nother commits you do not have yet. And \"git rebase\" was written\nwith the explicit purpose of helping to maintain branches like\n\"pu\". You _could_ merge master to pu and keep going, but if you\neventually want to cherrypick and merge some but not necessarily\nall changes back to the master branch, it often makes later\noperations for _you_ easier if you rebase (i.e. carry forward\nyour changes) \"pu\" rather than merge. So I ran \"git rebase\":\n\n $ git checkout pu\n $ git rebase master pu\n\nWhat this does is to pick all the commits since the current\nbranch (note that I now am on \"pu\" branch) forked from the\nmaster branch, and forward port these changes.\n\n master^ --> #1 --> #2 --> #3\n \\ *\"pu\" head\n \\---> master --> #1' --> #2' --> #3'\n\nThe diff between master^ and #1 is applied to master and\ncommitted to create #1' commit with the commit information (log,\nauthor and date) taken from commit #1. On top of that #2' and #3'\ncommits are made similarly out of #2 and #3 commits.\n\nOld #3 is not recorded in any of the .git/refs/heads/ file\nanymore, so after doing this you will have dangling commit if\nyou ran fsck-cache, which is normal. After testing \"pu\", you\ncan run \"git prune\" to get rid of those original three commits.\n\nWhile I am talking about \"git rebase\", I should talk about how\nto do cherrypicking using only the core GIT tools.\n\nLet's go back to the earlier picture, with different labels.\n\nYou, as an individual developer, cloned upstream repository and\namde a couple of commits on top of it.\n\n *your \"master\" head\n upstream --> #1 --> #2 --> #3\n\nYou would want changes #2 and #3 incorporated in the upstream,\nwhile you feel that #1 may need further improvements. So you\nprepare #2 and #3 for e-mail submission.\n\n $ git format-patch master^^ master\n\nThis creates two files, 0001-XXXX.txt and 0002-XXXX.txt. Send\nthem out \"To: \" your project maintainer and \"Cc: \" your mailing\nlist. You could use contributed script git-send-email-script if\nyour host has necessary perl modules for this, but your usual\nMUA would do as long as it does not corrupt whitespaces in the\npatch.\n\nThen you would wait, and you find out that the upstream picked\nup your changes, along with other changes.\n\n where *your \"master\" head\n upstream --> #1 --> #2 --> #3\n used \\ \n to be \\--> #A --> #2' --> #3' --> #B --> #C\n *upstream head\n\nThe two commits #2' and #3' in the above picture record the same\nchanges your e-mail submission for #2 and #3 contained, but\nprobably with the new sign-off line added by the upsteam\nmaintainer and definitely with different committer and ancestry\ninformation, they are different objects from #2 and #3 commits.\n\nYou fetch from upstream, but not merge.\n\n $ git fetch upstream\n\nThis leaves the updated upstream head in .git/FETCH_HEAD but\ndoes not touch your .git/HEAD nor .git/refs/heads/master. \nYou run \"git rebase\" now.\n\n $ git rebase FETCH_HEAD master\n\nEarlier, I said that rebase applies all the commits from your\nbranch on top of the upstream head. Well, I lied. \"git rebase\"\nis a bit smarter than that and notices that #2 and #3 need not\nbe applied, so it only applies #1. The commit ancestry graph\nbecomes something like this:\n\n where *your old \"master\" head\n upstream --> #1 --> #2 --> #3\n used \\ your new \"master\" head*\n to be \\--> #A --> #2' --> #3' --> #B --> #C --> #1'\n *upstream\n head\n\nAgain, \"git prune\" would discard the disused commits #1-#3 and\nyou continue on starting from the new \"master\" head, which is\nthe #1' commit.\n\n-jc\n"},{"id":"7265","messageId":"20050815063502.GD7001@mythryan2.michonline.com","threadId":"1505","inReplyTo":"20050814040233.GC6844@mythryan2.michonline.com","subject":"Re: sending changesets from the middle of a git tree","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-08-15T06:35:02Z","receivedAt":"2005-08-15T06:35:02Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Sun, Aug 14, 2005 at 12:02:33AM -0400, Ryan Anderson wrote:\n> On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:\n>\n> > 2) There is no way to update the comment field of a changeset after it \n> > goes in (e.g. to add a bugzilla bug number for a bug that was opened \n> > just after the fix went in).\n> \n> No, a commit is immutable. You can use \"git format-patch\" to rebase things if\n> you need. I prefer to use \"git format-patch --mbox\", edit what I need\n> to, then use git-applymbox to rebase it all against a clean tree.\n\nNote (and I should have said this at first), doing it this way gives you\nthe opportunity to combine a few changes if you want.\n\nUse git-format-patch-script to pull out what you want, delete the diff\nfrom the bottom of the file, manually diff what you need using\ngit-diff-script, and stick that back at the end of the file\ngit-format-patch-script created.\n\nThis seems to be the easiest way to clean up your change history.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"7285","messageId":"tnxmznj7f6b.fsf@arm.com","threadId":"1505","inReplyTo":"7vfytc9dzw.fsf@assigned-by-dhcp.cox.net","subject":"Re: sending changesets from the middle of a git tree","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-15T08:55:08Z","receivedAt":"2005-08-15T08:55:08Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> Petr Baudis writes:\n>\n>> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter\n>> where Junio C Hamano told me that...\n>>> Linus Torvalds writes:\n>>> \n>>> > Junio, maybe you want to talk about how you move patches from your \"pu\" \n>>> > branch to the real branches.\n>>> \n>> Actually, wouldn't this be also precisely for what StGIT is intended to?\n>\n> Exactly my feeling. I was sort of waiting for Catalin to speak\n> up. With its basing philosophical ancestry on quilt, this is\n> the kind of task StGIT is designed to do.\n\nHave been on holiday and couldn't reply. I will follow up.\n\n-- \nCatalin\n"},{"id":"7289","messageId":"tnxiry77dok.fsf@arm.com","threadId":"1505","inReplyTo":"42FEBC16.9050309@austin.rr.com","subject":"Re: sending changesets from the middle of a git tree","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-15T09:27:23Z","receivedAt":"2005-08-15T09:27:23Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"There are other ways to do these, explained in this thread. I will\nonly show the StGIT way, just choose which one suits you better.\n\nSteve French wrote:\n> 1) There is no way to send a particular changeset from the \"middle\"\n> of a set from one tree to another, without exporting it as a patch\n> or rebuilding a new git tree. I have two changesets that, after\n> testing last week, I now consider more important to send upstream\n> than the few earlier and later changesets.\n\nWith StGIT, you create a new patch ('stg new '), modify and\ncommit the changes with 'stg refresh'. All the modifications to a\npatch are stored as a single GIT commit. If you manage a (contributor)\ntree with StGIT, you shouldn't commit changes directly with GIT but\nuse the StGIT commands instead. You end up with a stack of changesets\non top of the main tree.\n\nYou can send the changesets upstream with the 'stg mail' command or\nexport them with 'stg export'.\n\n> If I export those two changesets as patches, and send them\n> on. presumably I lose the changset comments etc. and then when the\n> upstream tree is merged back, it might look a little odd in the\n> changeset history.\n\nPulling the latest changes from the main tree will keep your changes\non top, much like git cherry/rebase, but StGIT does a diff3 merge\ninstead of simply generating and applying patch. This has the\nadvantage of detecting when a patch (changeset) was not fully merged\nor was modifed. If the upstream merge was complete, StGIT shows your\npatch as empty (since your patch no longer needs to change the\ntree). Otherwise, you can either have some changes in the patch or\neven be notified of a conflict (patch modified before being merged).\n\n> 2) There is no way to update the comment field of a changeset after\n> it goes in (e.g. to add a bugzilla bug number for a bug that was\n> opened just after the fix went in).\n\n'stg refresh --edit' lets you modify the patch text. Since the GIT\ncommits are immutable, a new commit is generated but the parent of the\nnew commit is the same as the parent of the old commit (making this\ncommit unaccessible). Being able to create your own DAG structure with\nGIT is what made StGIT possible.\n\n> 3) There is no way to do a test commit of an individual changeset\n> against a specified tree (to make sure it would still merge cleanly,\n> automatically).\n\nWith StGIT you can pop all the patches from the stack and only push\nthe one you want to test (the push/pop operations also allow patch\nreordering). Note that the push operation is done with a three-way\nmerge and, if successful, the patch might have a sligthly different\nform (different offsets for example, or even chunks removed if they\nare already in the tree).\n\nIf the push fails, it means that it doesn't apply cleanly because it\ndepends on changes made by other patches in your series. You can undo\nthe push operation with 'stg push --undo'.\n\n-- \nCatalin\n"},{"id":"7401","messageId":"20050817001308.ED487353CFD@atlas.denx.de","threadId":"1505","inReplyTo":"7vfytc9dzw.fsf@assigned-by-dhcp.cox.net","subject":"Re: sending changesets from the middle of a git tree","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-08-17T00:13:08Z","receivedAt":"2005-08-17T00:13:08Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"Hello,\n\nin message <7vfytc9dzw.fsf@assigned-by-dhcp.cox.net> you wrote:\n> \n> This is the kind of situation I used to have all the time when\n> Linus was the maintainer and I was a contributor, when you look\n> at \"master\" branch being the \"maintainer\" branch, and \"pu\"\n> branch being the \"contributor\" branch. Your work started at the\n...\n> your changes) \"pu\" rather than merge. So I ran \"git rebase\":\n> \n> $ git checkout pu\n> $ git rebase master pu\n\nHow do you handle conflicts in such a situation?\n\nFor example, I get:\n\n\t-> git rebase master testing-NAND\n\t67a002cbe2b2850d76d797e679bc290a76666df6\n\tpatching file common/cmd_nand.c\n\tHunk #2 FAILED at 18.\n\tHunk #3 succeeded at 335 (offset 1 line).\n\t1 out of 4 hunks FAILED -- saving rejects to file common/cmd_nand.c.rej\n\texternal diff died, stopping at common/cmd_nand.c.\n\tSome commits could not be rebased, check by hand:\n\t67a002cbe2b2850d76d797e679bc290a76666df6\n\nOK, I can edit the file to resolve the conflicts. But what do I do\nthen to continue?\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering: Embedded and Realtime Systems, Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\n...when fits of creativity run strong, more than one programmer or\nwriter has been known to abandon the desktop for the more spacious\nfloor. - Fred Brooks, Jr.\n"},{"id":"7406","messageId":"7v1x4t5qlk.fsf@assigned-by-dhcp.cox.net","threadId":"1505","inReplyTo":"20050817001308.ED487353CFD@atlas.denx.de","subject":"Re: sending changesets from the middle of a git tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-17T00:55:51Z","receivedAt":"2005-08-17T00:55:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wolfgang Denk writes:\n\n> \texternal diff died, stopping at common/cmd_nand.c.\n> \tSome commits could not be rebased, check by hand:\n> \t67a002cbe2b2850d76d797e679bc290a76666df6\n>\n> OK, I can edit the file to resolve the conflicts. But what do I do\n> then to continue?\n\nYour rebase failed while processing 67a002... and fortunately\n(well, if you are really fortunate you would not have seem it)\n\"some commits could not be\" message says that was the only one\nleft. At that point, everything up to that commit should be\nmigrated on top of your head. Run gitk or git show-branches to\nsee where the \"master\" head is. It should be pointing at the\nlast successful commit the rebase process has made. I guess in\nyour example you had one commit between master and testing-NAND,\nin which case the master head does not have moved?\n\nAnyway, you manually resolve conflicts and make an commit from\nthere, which would migrate the failed 67a002... commit on top of\nyour master branch. If \"some commits could not be rebased\"\nmessage says more than one commit, you need to deal with the\nrest of them by hand; sorry there is no automated way currently.\n\nYou have to repeat for each such commit:\n\n (1) Run \"git-diff-tree -p | git-apply --index\" (or\n what is in git-rebase-script which uses git-apply-patch-script);\n (2) Resolve conflict if there is one;\n (3) Run \"git commit -C \".\n"}]}