Hi
----- Original Message -----
From: Christophe de Dinechin <dinechin@xxxxxxxxxx>
By default, subdmodules will be checked out in detached state.
This means that you may lose some work in progress.
Lose is a bit strong here.
If you have uncommitted changes, submodule update will fail.
This to me seems a good reason for a nack. The update will fail asa normal conflict without loosing any work.
Only if you have uncommitted changes. Otherwise, you end up in detached head state. That’s OK if I run git submodule update myself, I know what I’m doing. I’m more concerned about a builds script doing that for me.
IOW, I don’t want to have some work in a submodule in branch “topic”, and just because I ran autogen.sh, end up in detached head state with a detached head that does not even contain my topic.
If it's committed, it's in your reflog, and in which case you should have
created a branch for your work.
Using the --merge option will also ensure that if there
are conflicts between your current submodule and the
version referenced by the parent, you get an opportunity
to resolve the conflicts instead of having your changes
silently wiped out.
Signed-off-by: Christophe de Dinechin <dinechin@xxxxxxxxxx>
---
autogen.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/autogen.sh b/autogen.sh
index cc7bda3..3fbd5b3 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -7,7 +7,7 @@ test -z "$srcdir" && srcdir=.
(
cd "$srcdir"
- git submodule update --init --recursive
+ git submodule update --init --recursive --merge
I would rather use --rebase (to avoid accidental push of those update
merges).
gtkdocize
autoreconf -v --force --install
)
Frediano
|
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel