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

[Vadim Zeitlin]

On Sat, 17 Oct 2020 12:20:12 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-10-16 22:20, Vadim Zeitlin wrote:
GC> > On Fri, 16 Oct 2020 15:55:26 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
[...]
GC> > GC>   $git pull
GC> > GC> 
GC> > GC> I have one unpushed local commit, so I expected the first part of 
this:
GC> > 
GC> >  Sorry, I don't remember: do you have pull.rebase option set to true?
GC> 
GC> No, the only 'pull' setting I have is:
GC>   git config --list |grep pull
GC>   pull.ff=only
GC> 
GC> > Without it, git-pull should have complained, but it appears to just have
GC> > done a rebase instead.
GC> 
GC> Probably I had already run some random commands that caused it
GC> to behave otherwise. That would seem to explain the other
GC> weird things I observed.

 Yes, definitely. You just couldn't have got the b01ffaf88 (Update wxpdfdoc
submodule to contain the previous commit, 2020-10-16) commit without
pull.rebase being set in this situation without something else happening
in between.

GC> >  If you have any future problems/questions like this, running "git
GC> > submodule status third_party/wxpdfdoc" can provide more information.
GC> 
GC> Now, in the chroot where I had seen weird behavior, and also
GC> on the corporate server:
GC> 
GC> $git submodule status third_party/wxpdfdoc
GC>  1839b231c5138edd40b752272631e2f1d5311456 third_party/wxpdfdoc 
(v0.9.8-13-g1839b23)
GC> 
GC> ...and in a different chroot on my machine:
GC> 
GC> $git submodule status third_party/wxpdfdoc
GC> +4bf94ab2a04078fa5858fba4e38c97b9e8963050 third_party/wxpdfdoc 
(v0.9.8-14-g4bf94ab)
GC> 
GC> That last one, with "+4bf94ab2a", is a throwaway chroot that I
GC> may have updated in some incorrect way.

 Or just not yet updated at all.

GC> It doesn't really matter because I'll soon remove and regenerate it,
GC> but the leading "+" shows that the commit checked out in the submodule
GC> conflicts with the parent repository's notion,

 Yes, this is unfortunate because "+" would usually carry a positive
connotation, but in "git submodule status" output it rather indicates a
problem (or at least a potential problem).

GC> and your commit b01ffaf88302 indicates that 1839b231c513 is wanted:
GC>   -Subproject commit 974133eebd78a8311bf030cc639619927c152904
GC>   +Subproject commit 1839b231c5138edd40b752272631e2f1d5311456

 Yes, absolutely, my commit replaced the former with the latter (as can be
seen by running git-show on it).

 Please let me know if you have any questions, I do realize that submodules
can be confusing at first -- but I also hope that they don't remain
confusing for long if you ask questions about them rather than letting the
confusion settle.

 Good luck,
VZ

pgpmfY38wX05D.pgp
Description: PGP signature