Rebase & submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux