lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wx 'git checkout f741031e69de73d5' aborting


From: Vadim Zeitlin
Subject: Re: [lmi] wx 'git checkout f741031e69de73d5' aborting
Date: Sun, 24 Mar 2019 14:19:30 +0100

On Sun, 24 Mar 2019 11:55:37 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-03-24 00:20, Vadim Zeitlin wrote:
GC> > On Sat, 23 Mar 2019 21:37:32 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> To reproduce on the command line (full output of './install_wx.sh'[0]
GC> > GC> copied as a footnote below):
GC> > 
GC> >  I'm almost certain that I won't be able to reproduce this because I don't
GC> > have the files that Git is complaining about in my working copy.
GC> 
GC> Selecting one of the sixteen files listed in the footnote, which I
GC> seem most unlikely to have added intentionally:
GC>   samples/aui/minimal_iphone.xcodeproj/project.pbxproj
GC> and searching for it on the web, I find:
GC> 
GC> 
https://github.com/wxWidgets/wxWidgets/tree/master/samples/aui/minimal_iphone.xcodeproj
GC> 
GC> so it's actually in the repository...

 Yes, all of these files are, and that's actually what explains the
git-checkout error message.

GC> > And for me the real question is how did they get there?
GC> 
GC> ...but I can't guess how I could have gotten it.

 Copying the working directory over the top of an existing Git repository
could do it, but you don't seem to have done this. Otherwise the only way
that I know of to get into such situation is by using git-reset: e.g. if
you checkout the latest version of this repository and then run this
command (without --hard option) to return to some earlier commit, the new
files would be left in your working tree. But it seems unlikely that you
would have done git-reset accidentally.

GC> > GC> /opt/lmi/src/lmi[1]$pushd /cache_for_lmi/vcs/wxWidgets
GC> > GC> /cache_for_lmi/vcs/wxWidgets /opt/lmi/src/lmi
GC> > GC> 
GC> > GC> /cache_for_lmi/vcs/wxWidgets[0]$git rev-parse --quiet --verify 
f741031e69de73d5816cc56e99c9beba3ac820de^{commit}
GC> > GC> f741031e69de73d5816cc56e99c9beba3ac820de
GC> > GC> 
GC> > GC> /cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
GC> > GC> e38866d3a60 (HEAD) Merge branch 'lzma'
GC> > 
GC> >  I think it's too late for this, but I'd expect "git status" to show 
plenty
GC> > of changes in the working tree at this moment.
GC> 
GC> Well, now, wait...in order to preserve a pristine gcc-7.3.0 production
GC> environment, I created a separate chroot for gcc-8.2.0, and the reported
GC> issue occurred in that new chroot. Let's try that last command in both,
GC> along with 'git status', also echoing the chroot name just to be sure:
GC> 
GC> # old gcc-seven chroot
GC> 
GC> /cache_for_lmi/vcs/wxWidgets[0]$echo $SCHROOT_ALIAS_NAME
GC> lmi-buster
GC> /cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
GC> f741031e69 (HEAD, origin/master, origin/HEAD) Suppress gcc 
-Wfloat-conversion warning in wxFontInfo ctor
GC> /cache_for_lmi/vcs/wxWidgets[0]$git status
GC> HEAD detached at f741031e69
GC> nothing to commit, working tree clean
GC> 
GC> # new gcc-eight chroot [after running 'git checkout --force']
GC> 
GC> /cache_for_lmi/vcs/wxWidgets[0]$echo $SCHROOT_ALIAS_NAME 
GC> lmi-buster2
GC> /cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
GC> f741031e69d (HEAD) Suppress gcc -Wfloat-conversion warning in wxFontInfo 
ctor
GC> /cache_for_lmi/vcs/wxWidgets[0]$git status
GC> HEAD detached at f741031e69d
GC> nothing to commit, working tree clean
GC> 
GC> The only difference I see (for gcc-seven, then gcc-eight) is:
GC> 
GC> f741031e69 (HEAD, origin/master, origin/HEAD) Suppress gcc 
-Wfloat-conversion warning in wxFontInfo ctor
GC> f741031e69d (HEAD) Suppress gcc -Wfloat-conversion warning in wxFontInfo 
ctor

 This means that gcc-eight chroot doesn't have the latest commits from
origin, i.e. you didn't run git-fetch there but did run it in gcc-seven
chroot (after cloning the gcc-eight one from it).

GC> Repeating the commands above on the host shows that its last commit
GC> appears to be the old 'lzma' one, and its HEAD is detached, but at
GC> a different SHA1:
GC> 
GC> /srv/cache_for_lmi/vcs/wxWidgets[0]$ls -di /
GC> 2 /
GC> /srv/cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
GC> e38866d3a6 Merge branch 'lzma'
GC> /srv/cache_for_lmi/vcs/wxWidgets[0]$git status          
GC> HEAD detached at e38866d3a6
GC> nothing to commit, working tree clean
GC> 
GC> Perhaps that's the problem.

 I don't see why would it be a problem, to be honest?

GC> so both chroots must have done a 'git fetch', but I certainly didn't
GC> do that manually, and 'install_wx.sh' shouldn't have done it either:
GC> 
GC> # Fetch desired commit from remote host if missing.
GC> if ! git rev-parse --quiet --verify "$wx_commit_sha^{commit}" >/dev/null
GC> then
GC>     git fetch origin
GC> fi

 Well, something must have done git-fetch, albeit quite some time ago
(f741031e69d dates from 2018-09-18) and this part of the script looks like
the most obvious candidate.

GC> I'm hoping that the information above might help you diagnose the
GC> problem, because I can't really understand it myself.

 Sorry, no, I still have no idea. I suggest that we leave this like this
for now and return to it later, with hopefully more information, if it ever
happens again. It's easy to get confused with multiple working trees in
different chroots, I know it happens to me all the time, so perhaps you've
just really run git-reset accidentally in one of them after all.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]