Re: [lmi] PATCH for wxPdfDoc: ignore 'autom4te.cache' artifacts

[Vadim Zeitlin]

On Fri, 16 Oct 2020 15:55:26 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-10-16 12:57, Vadim Zeitlin wrote:
GC> [...]
GC> >  Yes, so I've just pushed your commit to the submodule and updated the 
main
GC> > repository to use the new commit. The CI builds haven't finished yet, but 
I
GC> > think they should pass now and I'll monitor them in case they don't.
GC> 
GC> I believe I've managed to update my production chroot, but let me
GC> say what I did because it seems inelegant at best. I began the
GC> way I always update my local tree when you've pushed to savannah:
GC> 
GC>   $git remote -v update

 I'm almost certain that you're already aware of this, but, just in case:
the command above is purely informative and there is no real need to run it
every time before updating (or ever at all, for that matter).

GC>   $git pull
GC> 
GC> I have one unpushed local commit, so I expected the first part of this:

 Sorry, I don't remember: do you have pull.rebase option set to true?
Without it, git-pull should have complained, but it appears to just have
done a rebase instead.

GC>   Changes not staged for commit:
GC>     (use "git add <file>..." to update what will be committed)
GC>     (use "git restore <file>..." to discard changes in working directory)
GC>           modified:   third_party/wxpdfdoc (new commits)
GC> 
GC> ...but not the second part that mentions new commits in a submodule.
GC> This seemed like a good idea:
GC> 
GC>   $git submodule update --recursive third_party/wxpdfdoc 
GC>   Submodule path 'third_party/wxpdfdoc': checked out 
'1839b231c5138edd40b752272631e2f1d5311456'
GC> 
GC> ...but it didn't resolve the "(new commits)" message from git-status,

 This is really strange. 1839b231c5138edd40b752272631e2f1d5311456 is the
correct submodule commit currently used in master, so it shouldn't be
saying "new commits" if your current branch includes b01ffaf88 (Update
wxpdfdoc submodule to contain the previous commit, 2020-10-16).

GC> so I tried this:
GC> 
GC>   $pushd /opt/lmi/src/lmi/third_party/wxpdfdoc
GC>   $git pull
GC> 
GC>   You are not currently on a branch.
GC>   Please specify which branch you want to merge with.
GC>   See git-pull(1) for details.
GC> 
GC>       git pull <remote> <branch>
GC> 
GC> I'm not on a branch?

 Yes, this is another confusing thing about Git submodules: when you update
them from the parent repository, Git does just the equivalent of "git
reset" to the commit SHA-1 currently recorded in the parent. I.e. it simply
doesn't store the information about the branch containing this commit, so
it can't switch to it. Hence you will always be in a "detached HEAD" state
in the submodule if you update it from the parent.

 OTOH if you check out the branch using the same commit as its tip inside
the submodule itself, you would be on this branch and the submodule would
appear as being unmodified in the parent.

GC> Then it struck me that 'master' might not be the branch I want,
GC> and I thought I remembered something about an "lmi" branch, so:
GC> 
GC>   $git switch lmi
GC>   Branch 'lmi' set up to track remote branch 'lmi' from 'origin'.
GC>   Switched to a new branch 'lmi'
GC> 
GC> Uh-oh: if that branch were supposed to exist, then wouldn't it already have?

 No, it only exists as a remote branch, but not as a local one (this is not
different from any other branch except master, which is created
automatically by git-clone by default).

GC> But now when I navigate back to the topmost git directory, everything's
GC> copacetic:
GC> 
GC>   $git status
GC>   On branch master
GC>   Your branch is ahead of 'origin/master' by 1 commit.
GC>     (use "git push" to publish your local commits)
GC> 
GC>   Untracked files:
GC>   [exactly the local files I expect to see]
GC> 
GC>   nothing added to commit but untracked files present (use "git add" to 
track)
GC> 
GC> So now it looks like the "(new commits)" problem no longer exists,
GC> but I have the distinct feeling that the method by which I got to
GC> that state is not really appropriate. What was I supposed to do
GC> instead?

 I admit I'm confused here. Normally the first "git submodule update"
command should have been enough and the submodule shouldn't have appeared
as being unmodified after it. Moreover, switching to lmi branch in the
submodule shouldn't have changed anything because the tip of this branch is
exactly the same 1839b23 (Add '/autom4te.cache' to '.gitignore',
2020-10-15) commit that "git submodule update" claimed to have checked out.
I must be misunderstanding something here, but I'm not sure what exactly.

 If you have any future problems/questions like this, running "git
submodule status third_party/wxpdfdoc" can provide more information. But
right now I don't have any explanation why your initial submodule update
seems to still have left it in the modified state, even though it shouldn't
have had, sorry.

VZ

pgpcM6Q8njLrU.pgp
Description: PGP signature