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. > 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. > 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. Sam. -- 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
