{"thread":{"id":"46750","subject":"Rebase & submodules","startedAt":"2017-09-14T15:40:00Z","lastAt":"2017-09-14T17:46:20Z","messageCount":3,"participants":["Robert Dailey","Nicolas Morey-Chaisemartin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"328062","messageId":"CAHd499ApnHpt0CmcQMx+qVQ60NV6auFKkuvikCq2Zut4p4rzaQ@mail.gmail.com","threadId":"46750","inReplyTo":null,"subject":"Rebase & submodules","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2017-09-14T15:39:53Z","receivedAt":"2017-09-14T15:40:00Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"So I often will have a submodule that points to one of my own forks,\nbecause I will have work done on a feature branch that hasn't been\nmerged upstream yet. Assuming this merge takes a long time to get\napproved, I will occasionally rebase my topic branch to keep things up\nto date and clean.\n\nHowever, any previous commits in my parent repository that refer to a\nSHA1 prior to the rebase will now be pointing to dangling/orphaned\ncommits, which means I wouldn't be able to go back to that commit in\nhistory and do `git submodule update` since that checkout will fail.\n\nOne obvious solution to this is: Don't rebase. But, this could result\nin a lot of merging between the upstream and my fork which would make\nthings not only ugly, but prevent me from making a pull request that\nmakes sense to the upstream repository (They'd likely request a rebase\nin order to accept the PR, which I wouldn't be able to do for the\nreasons outlined above).\n\nAre there any other workflows that would support this kind of model better?\n"},{"id":"328064","messageId":"bf4275e5-ad96-4b71-e6a0-52c198cd541e@suse.de","threadId":"46750","inReplyTo":"CAHd499ApnHpt0CmcQMx+qVQ60NV6auFKkuvikCq2Zut4p4rzaQ@mail.gmail.com","subject":"Re: Rebase & submodules","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nmoreychaisemartin@suse.de","sentAt":"2017-09-14T15:57:51Z","receivedAt":"2017-09-14T15:57:59Z","isPatch":false,"sender":{"key":"nmoreychaisemartin@suse.de","avatar":"https://gravatar.com/avatar/5546322ccb9067f56b6939d9d5c758a40cab5b978b1379fd6ec8ab9b8a6a12b1?d=mp&s=160"},"body":"\n\nLe 14/09/2017 à 17:39, Robert Dailey a écrit :\n> So I often will have a submodule that points to one of my own forks,\n> because I will have work done on a feature branch that hasn't been\n> merged upstream yet. Assuming this merge takes a long time to get\n> approved, I will occasionally rebase my topic branch to keep things up\n> to date and clean.\n>\n> However, any previous commits in my parent repository that refer to a\n> SHA1 prior to the rebase will now be pointing to dangling/orphaned\n> commits, which means I wouldn't be able to go back to that commit in\n> history and do `git submodule update` since that checkout will fail.\n>\n> One obvious solution to this is: Don't rebase. But, this could result\n> in a lot of merging between the upstream and my fork which would make\n> things not only ugly, but prevent me from making a pull request that\n> makes sense to the upstream repository (They'd likely request a rebase\n> in order to accept the PR, which I wouldn't be able to do for the\n> reasons outlined above).\n>\n> Are there any other workflows that would support this kind of model better?\n\nWithout changing your workflow too much, simply add an annotated tag to your branch before your rebase.\nThis way the SHA1 will always exists. Unless you want to cleanup at some point (branch merged ?) and then you can simply delete all those old tags.\n\nNicolas\n\n\n"},{"id":"328070","messageId":"CAHd499BeANJBryo3sOoD2vT-A0M-R00GTa5-wTOumyj0EkSHkQ@mail.gmail.com","threadId":"46750","inReplyTo":"bf4275e5-ad96-4b71-e6a0-52c198cd541e@suse.de","subject":"Re: Rebase & submodules","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2017-09-14T17:46:15Z","receivedAt":"2017-09-14T17:46:20Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Thu, Sep 14, 2017 at 10:57 AM, Nicolas Morey-Chaisemartin\n<NMoreyChaisemartin@suse.de> wrote:\n> Without changing your workflow too much,\n\nIf you mean to imply that you have other recommendations if I'm\nwilling to change my workflow, then please by all means share them.\nI'm very interested. I'm not too hooked on my workflow.\n\n> simply add an annotated tag to your branch before your rebase.\n> This way the SHA1 will always exists. Unless you want to cleanup at some point (branch merged ?) and then you can simply delete all those old tags.\n\nThis definitely the best idea so far; although the maintenance\noverhead of this could be high for long-lived branches with frequent\nrebases. Maybe with bigger workflow changes there are other solutions?\n"}]}