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

[Greg Chicares]

On 2020-10-16 22:20, Vadim Zeitlin wrote:
> 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).

I wasn't aware, actually. That's in my gwc/develop1.txt "cheat sheet":

  # Update the local source tree (where I make my own changes) when
  # someone else has committed a change to the online master repo.
  git remote -v update
  git pull

which has enabled me to use git while hardly understanding it.

However, I recently tried git-pull on the corporate server (which
blocks savannah.gnu.org), and when it wouldn't retrieve the most
recent commits, I knew to do this:
  git remote -v
(to see whether I had done 'git remote set-url' to use the newer
github repository), and I was struck by the similarity to the
first command above.

And it turns out that the "cheat sheet" commands were just a
translation of svn status and update commands that I used to
use separately, for reasons that no longer matter:
  https://lists.nongnu.org/archive/html/lmi/2017-11/msg00002.html

> 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?

No, the only 'pull' setting I have is:
  git config --list |grep pull
  pull.ff=only

> Without it, git-pull should have complained, but it appears to just have
> done a rebase instead.

Probably I had already run some random commands that caused it
to behave otherwise. That would seem to explain the other
weird things I observed.

>  If you have any future problems/questions like this, running "git
> submodule status third_party/wxpdfdoc" can provide more information.

Now, in the chroot where I had seen weird behavior, and also
on the corporate server:

$git submodule status third_party/wxpdfdoc
 1839b231c5138edd40b752272631e2f1d5311456 third_party/wxpdfdoc 
(v0.9.8-13-g1839b23)

...and in a different chroot on my machine:

$git submodule status third_party/wxpdfdoc
+4bf94ab2a04078fa5858fba4e38c97b9e8963050 third_party/wxpdfdoc 
(v0.9.8-14-g4bf94ab)

That last one, with "+4bf94ab2a", is a throwaway chroot that I
may have updated in some incorrect way. It doesn't really matter
because I'll soon remove and regenerate it, but the leading "+"
shows that the commit checked out in the submodule conflicts with
the parent repository's notion, and your commit b01ffaf88302
indicates that 1839b231c513 is wanted:
  -Subproject commit 974133eebd78a8311bf030cc639619927c152904
  +Subproject commit 1839b231c5138edd40b752272631e2f1d5311456