From: Stijn Souffriau <stijn.souffriau@essensium.com>
To: git@vger.kernel.org
Subject: dangling submodule references after rebase
Date: Thu, 30 Aug 2012 11:56:52 +0200 [thread overview]
Message-ID: <503F38E4.1010108@essensium.com> (raw)
Hi all,
I am using a repository that has a sub module which is being committed
to frequently by myself as well as others. Because of the heavy
concurrent development I need to do a lot of rebasing. Since the sub
module commit hashes referenced by the parent repository can become
dangling as a result of rebasing the sub module I am required to do lots
of manual "fixing" of the references in the parent repository using an
interactive rebase. This is a tedious, error-prone procedure which I
would like to automate.
I was wondering if anyone has thought about solving this problem yet in
the past and what might be a good solution?
I was thinking something along the lines of extending the add and commit
commands so that a parent repository would signal to the sub modules
that it's index or some if it's commits reference certain sub module
commits; and also the rebase command so that it would update the parent
repository commits with new hashes using the information stored by the
add or commit commands. The procedure would have to be made recursive
because changing commits in the parent repository might also require
changing commits in it's parent repository as well.
I'm still no quite sure for which sub module rebase operations the
referencing parent repository commits would actually have to be
"updated". The reason being that the rebased commits might still be
referenced by another branch and so they might continue to exist after
the rebase which raises the question if the parent repository commits
need to be udated or not. I think this question would have to be
answered by the add and commit commands which would also have to specify
a referenced branch in addition to referenced commits so that the parent
repo commits would only have to be updated if the commits on this branch
are rebased. By default this could be the branch checked out in the sub
module at the time the referencing commit was made.
For obvious reasons this should only be done for newly made, unpushed
and unpulled commits in the repository. However, it might be interesting
to also enable people to manually bind a parent repo commits to a
submodule branch so that the commits in this parent repo branch are
updated when the sub module branch is rebased.
I would like see this feature end up in the mainline and so I'm very
interested in your opinions.
Thanks,
Stijn
next reply other threads:[~2012-08-30 9:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 9:56 Stijn Souffriau [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-08-29 9:55 dangling submodule references after rebase Stijn Souffriau
2012-08-29 20:19 ` Jens Lehmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=503F38E4.1010108@essensium.com \
--to=stijn.souffriau@essensium.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).