{"thread":{"id":"25682","subject":"making stgit handle being rebased by git rebase","startedAt":"2010-11-08T22:39:32Z","lastAt":"2010-11-11T11:34:11Z","messageCount":4,"participants":["Chris Packham","Catalin Marinas","Karl Wiberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155447","messageId":"AANLkTik3MVNW0svJEo5gWq3+qGo6dKeqAUz9NPcJnYNN@mail.gmail.com","threadId":"25682","inReplyTo":null,"subject":"making stgit handle being rebased by git rebase","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-11-08T22:39:32Z","receivedAt":"2010-11-08T22:39:32Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi Catalin, Karl,\n\nHas anyone looked at making stgit interact with git-rebase more gracefully?\n\nI've been playing with some of the recent git submodule improvements,\nin particular the submodule..update=rebase option. When I have a\nsubmodule which I've been using stgit on it gets a bit upset when the\nbranch gets rebased by git. I don't loose any work but all my stgit\npatches get turned into git commits. I can get them back with stg\nrepair and/or stg uncommit but I was wondering if there was any way of\nmaking stgit play nicely with git rebase.\n\nAs a workaround I could have something remember the applied patches,\nrun stg pop -a and re-apply the patches after the fact. All of which\nis doable but maybe there is a better way.\n\nThanks,\nChris\n"},{"id":"155663","messageId":"AANLkTik_dFsaiDkugrpBp8T31zNWVMRNC=hQBj0RmV+o@mail.gmail.com","threadId":"25682","inReplyTo":"AANLkTik3MVNW0svJEo5gWq3+qGo6dKeqAUz9NPcJnYNN@mail.gmail.com","subject":"Re: making stgit handle being rebased by git rebase","fromName":"Karl Wiberg","fromEmail":"kha@treskal.com","sentAt":"2010-11-11T10:29:48Z","receivedAt":"2010-11-11T10:29:48Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On Mon, Nov 8, 2010 at 11:39 PM, Chris Packham wrote:\n> Has anyone looked at making stgit interact with git-rebase more gracefully?\n\nThe problem is that StGit's metadata gets out of date when you do a\ngit rebase. A solution would either have to change StGit's metadata\nrepresentation so that it can't get out of date, or be a fancy version\nof repair/uncommit that can actually figure out what git did.\n\nI've thought a bit about this in the past, and the best solution I\ncould come up with is of the first kind, and would change the\nrepresentation of applied patches to use just two refs: the branch\nitself, and the stack base ref. I think git rebase wouldn't wreck\nthings for that representation.\n\nThis kind of change is a lot of work, though, more than I have time\nfor at the moment. And it's not like I have the details worked out or\nanything... Making stg repair more intelligent would be a lot less\ninvolved.\n\n-- \nKarl Wiberg, kha@treskal.com\n   subrabbit.wordpress.com\n   www.treskal.com/kalle\n"},{"id":"155661","messageId":"AANLkTimjO0yMJvf_fF3g7qypAuhPyiHCeF-sUv5toM_S@mail.gmail.com","threadId":"25682","inReplyTo":"AANLkTik_dFsaiDkugrpBp8T31zNWVMRNC=hQBj0RmV+o@mail.gmail.com","subject":"Re: making stgit handle being rebased by git rebase","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2010-11-11T10:41:55Z","receivedAt":"2010-11-11T10:41:55Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 11 November 2010 10:29, Karl Wiberg wrote:\n> On Mon, Nov 8, 2010 at 11:39 PM, Chris Packham wrote:\n>> Has anyone looked at making stgit interact with git-rebase more gracefully?\n>\n> The problem is that StGit's metadata gets out of date when you do a\n> git rebase. A solution would either have to change StGit's metadata\n> representation so that it can't get out of date, or be a fancy version\n> of repair/uncommit that can actually figure out what git did.\n>\n> I've thought a bit about this in the past, and the best solution I\n> could come up with is of the first kind, and would change the\n> representation of applied patches to use just two refs: the branch\n> itself, and the stack base ref. I think git rebase wouldn't wreck\n> things for that representation.\n\ngit rebase would most likely change the base of the stack so stgit can\nno longer track its patches. If git rebase just moves the stack base\nforward, stgit could generate additional patches that have been\nbrought in by git, though sometimes this would include merges etc.\n\nMaybe a better option for stgit is to just remember the branch and the\nnumber of patches (probably including the patch names unless we always\ngenerate them automatically, not that bad but you lose the possibility\nof renaming patches).\n\nThe above would work well if people use git commit on top of an stgit\nbranch. The patch names maybe be wrongly associated or (if we\nautomatically generate patch names) we may miss the first patch in the\nseries because of the number of commits. The latter is not that bad\nsince we can always use stg uncommit, though a stg rebase could\noverride the committed patch.\n\n-- \nCatalin\n"},{"id":"155664","messageId":"AANLkTimfJZ5q+fg0qhr6o2y7SGWKKNP4-kVFiL8DS1Sd@mail.gmail.com","threadId":"25682","inReplyTo":"AANLkTimjO0yMJvf_fF3g7qypAuhPyiHCeF-sUv5toM_S@mail.gmail.com","subject":"Re: making stgit handle being rebased by git rebase","fromName":"Karl Wiberg","fromEmail":"kha@treskal.com","sentAt":"2010-11-11T11:34:11Z","receivedAt":"2010-11-11T11:34:11Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On Thu, Nov 11, 2010 at 11:41 AM, Catalin Marinas\n wrote:\n\n> On 11 November 2010 10:29, Karl Wiberg wrote:\n>\n>> I've thought a bit about this in the past, and the best solution I\n>> could come up with is of the first kind, and would change the\n>> representation of applied patches to use just two refs: the branch\n>> itself, and the stack base ref. I think git rebase wouldn't wreck\n>> things for that representation.\n>\n> git rebase would most likely change the base of the stack so stgit\n> can no longer track its patches.\n\nI was thinking we could use another git branch as stack\nbase---specifically, use origin/master as stack base for master, etc.\nThe stack of applied patches would then be defined as\norigin/master..master. That way, git rebase really wouldn't do any\nharm.\n\nOf course, if git rebase was used to rebase onto a different branch,\nthen StGit would have to be told about it; but git already stores\ninformation of this sort, used by e.g. git pull with no arguments.\n(No, I haven't researched this part properly. )\n\n> Maybe a better option for stgit is to just remember the branch and\n> the number of patches (probably including the patch names unless we\n> always generate them automatically, not that bad but you lose the\n> possibility of renaming patches).\n\nYes, that's another way to do it. I think I like my proposal better,\nbut as I said, I haven't worked it out in detail, and I'm not about to\ndo so any time soon.\n\n> The above would work well if people use git commit on top of an\n> stgit branch.\n\nThat goes for my proposal as well.\n\n> The patch names maybe be wrongly associated or (if we automatically\n> generate patch names) we may miss the first patch in the series\n> because of the number of commits. The latter is not that bad since\n> we can always use stg uncommit, though a stg rebase could override\n> the committed patch.\n\nPatch names are a problem in all these \"minimal metadata for applied\npatches\" ideas. They could possibly be preserved by guessing the best\nmatch if the stack is modified outside StGit.\n\n-- \nKarl Wiberg, kha@treskal.com\n   subrabbit.wordpress.com\n   www.treskal.com/kalle\n"}]}