On 30. mars. 2008, at 22.19, Sam Vilain wrote:
Eyvind Bernhardsen wrote:
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.
ok. so, refuse to push without forcing, don't do something dumb.
I think you misunderstood: what I'm saying is that submodules'
_current_ behaviour is annoying, since you're guaranteed to forget to
push a submodule before pushing the main module at least once. My
attempt to solve that became too complicated, so I dropped it, and
since the current behaviour is annoying, I gave up on submodules
entirely.
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.
It's simple. You just fail and tell the user what happened, and let
them decide what to do.
Sure, that solves the annoyance problem, but I wanted something more
automatic.
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.
If it is a rewind there is no issue, because you don't even need to
push.
But again it comes back to - let the user sort it out, don't try to be
too clever.
Yep, my problem was wanting to be cleverer than my limited git skills
will allow.
--
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
