threads / discuss / 46750

Rebase & submodules

Subject: Rebase & submodules

## tl;dr

3 messages between Sep 14, 2017 and Sep 14, 2017.

replies: 2people: 2as markdown or json

Robert Dailey· Sep 14, 2017, 15:39 UTC · lore

So I often will have a submodule that points to one of my own forks, because I will have work done on a feature branch that hasn't been merged upstream yet. Assuming this merge takes a long time to get approved, I will occasionally rebase my topic branch to keep things up to date and clean.

However, any previous commits in my parent repository that refer to a SHA1 prior to the rebase will now be pointing to dangling/orphaned commits, which means I wouldn't be able to go back to that commit in history and do `git submodule update` since that checkout will fail.

One obvious solution to this is: Don't rebase. But, this could result in a lot of merging between the upstream and my fork which would make things not only ugly, but prevent me from making a pull request that makes sense to the upstream repository (They'd likely request a rebase in order to accept the PR, which I wouldn't be able to do for the reasons outlined above).

Are there any other workflows that would support this kind of model better?

Nicolas Morey-Chaisemartin· Sep 14, 2017, 15:57 UTC · re: Robert Dailey · lore

Re: Rebase & submodules

Le 14/09/2017 à 17:39, Robert Dailey a écrit :

Show 19 quoted lines

> So I often will have a submodule that points to one of my own forks,
> because I will have work done on a feature branch that hasn't been
> merged upstream yet. Assuming this merge takes a long time to get
> approved, I will occasionally rebase my topic branch to keep things up
> to date and clean.
>
> However, any previous commits in my parent repository that refer to a
> SHA1 prior to the rebase will now be pointing to dangling/orphaned
> commits, which means I wouldn't be able to go back to that commit in
> history and do `git submodule update` since that checkout will fail.
>
> One obvious solution to this is: Don't rebase. But, this could result
> in a lot of merging between the upstream and my fork which would make
> things not only ugly, but prevent me from making a pull request that
> makes sense to the upstream repository (They'd likely request a rebase
> in order to accept the PR, which I wouldn't be able to do for the
> reasons outlined above).
>
> Are there any other workflows that would support this kind of model better?

Without changing your workflow too much, simply add an annotated tag to your branch before your rebase. 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.

Nicolas

Robert Dailey· Sep 14, 2017, 17:46 UTC · re: Nicolas Morey-Chaisemartin · lore

Re: Rebase & submodules

On Thu, Sep 14, 2017 at 10:57 AM, Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.de> wrote:

> Without changing your workflow too much,

If you mean to imply that you have other recommendations if I'm willing to change my workflow, then please by all means share them. I'm very interested. I'm not too hooked on my workflow.

> simply add an annotated tag to your branch before your rebase.
> 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.

This definitely the best idea so far; although the maintenance overhead of this could be high for long-lived branches with frequent rebases. Maybe with bigger workflow changes there are other solutions?