Re: Rebase & submodules

From: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.de>
Date: Sep 14, 2017, 15:57 UTC
Message-ID: <bf4275e5-ad96-4b71-e6a0-52c198cd541e@suse.de>
In-Reply-To: <CAHd499ApnHpt0CmcQMx+qVQ60NV6auFKkuvikCq2Zut4p4rzaQ@mail.gmail.com>

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