Rob Vermaas wrote: > Hi Jim, > >> -Subproject commit 568779402439589832419c90e3f8193496a39613 >> +Subproject commit 680c7ff005a2eb96b0903e5200cc28de273555c7 > > Did you make the same mistake again? or is it me this time? > > fatal: reference is not a tree: 680c7ff005a2eb96b0903e5200cc28de273555c7 > Unable to checkout '680c7ff005a2eb96b0903e5200cc28de273555c7' in > submodule path 'gnulib'
Hmm... I was careful to put my local gnulib repo into the right state, then ran "git syncsub" in coreutils, committed, and pushed. However, I now see that is not always adequate: "git syncsub" did not do what I expected, and I did not rerun "make public-submodule-commit" to verify. It still fails. The problem is that the gnulib submodule under my coreutils build directory had a stray commit, and that was causing each syncsub to do a non-ff update and thus to create a merge commit. Thanks for the quick feedback! I've just confirmed that this does solve the problem, and *then* pushed it. >From e0c6272ac38a8eaba49b31adb4415e31159b6dd4 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[email protected]> Date: Thu, 20 Jan 2011 10:50:11 +0100 Subject: [PATCH] build: update gnulib submodule to latest The previous gnulib submodule reference was *still* to a non-public commit. My submodule had a stray commit, so the reference was always to a local merge commit. Reported by Rob Vermaas. --- gnulib | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gnulib b/gnulib index 680c7ff..ff4bb04 160000 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject commit 680c7ff005a2eb96b0903e5200cc28de273555c7 +Subproject commit ff4bb04bec0c8d7834bfb0590d6de08fa0ceefd0 -- 1.7.3.5
