On 30. mars. 2008, at 19.48, Sam Vilain wrote:
Eyvind Bernhardsen wrote:
I solved that by adding a "submodule push" that pushes the detached
head
of each submodule to its own ref ("refs/submodule-update/commit-
$sha1",
imaginatively). I also made "submodule update" try to fetch that ref
when looking for a sha1.
Hmm, a reasonable decision, but I think it would be better to force
the
user to choose which branch they want to push to. Leaving breadcrumbs
in the refs/ space like that is best avoided.
Well, the point of "submodule push" was to avoid having to push in
each submodule manually; not enforcing the requirement that commits in
submodules must be publicly available before pushing from the main
module is a recipe for disaster, or at least annoyance. And nobody
likes an annoying git.
Pushing to a branch works except that I couldn't figure out what to do
if the push doesn't succeed, ie, the branch has advanced on the remote
end. That's a problem if more than one module references the
submodule or there are multiple branches in the main module.
One solution that occurred to me was to have a branch in each
submodule for every main module and branch. A branch name would be
provided for each submodule in .gitmodules, used by "submodule push"
but not "submodule update". In this case, if the push to the branch
fails, the main module branch is probably behind too.
This seemed like a good idea, but it's racy. If two simultaneous
"submodule push"es try to push to the same branch on a submodule, one
of them will be rejected, but it might already have updated branches
on other submodules. Ick.
I briefly toyed with creating tags named after the main module and its
branch, with the submodule sha1 included for good measure, but that
leaves a _real_ mess in refs/tags. Figuring out that I could use refs/
submodule-push instead seemed like an epiphany at the time.
As an aside, my mental model of what the submodule needs is a
fetchable reflog for every main module and branch that uses it,
containing the history of commits used by that module/branch.
It's a reflog, not a branch, because a submodule can be changed to a
different branch, rewound, etc between commits in the main module;
there's no requirement that the old commit is in the new commit's
history. You actually don't want to fetch the whole thing, but you
have to be able to fetch every sha1 contained in it, by sha1.
...so that's what refs/submodule-push is supposed to look like. You
might need to squint a bit.
Indeed - it can only become "fit for public consumption" if people
submit their usability enhancements!
True :) I still have no idea how to figure out which submodules are
dirty, though. Solving that will enable a safe "submodule update",
which I think is more important than "submodule push".
--
Eyvind Bernhardsen
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
