On 31. mars. 2008, at 01.03, Avery Pennarun wrote:
On Sun, Mar 30, 2008 at 3:50 PM, Eyvind Bernhardsen
<eyvind-git@xxxxxxxxxxxxxx> wrote:
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.
That's easy: just error out in that case. If the current system would
just error out when I screwed up, I'd at least be able to deal with
it. Right now I silently create un-check-outable parent repositories
because I failed silently to upload my latest checkins to the child
repository.
As I tried to explain, all the automatic push solutions I could come
up with were flawed, so I decided not to use submodules at all and
just have the build tool check out every module (that's what we
currently do with CVS, so it's the easy way out anyway).
If I understand you correctly, you want to be forced to create a
branch and push to that? I don't think that works well with many
developers pushing to a shared repository (my situation), and is in
any case not the "automagical push" solution that I want. I agree
that it would be an improvement, but it doesn't scratch my itch :)
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".
What is unsafe about "submodule update"?
If you have local changes committed in a submodule that is updated by
a pull in the main module, "submodule update" will silently overwrite
them. I was wrong, though, because you can fix that just by making
"submodule update" error out when a submodule doesn't have its HEAD
where the main module thinks it should be.
--
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
