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 01:20:20 +0100

On Sat, 23 Mar 2019 21:37:32 +0000 Greg Chicares <address@hidden> wrote:

GC> To reproduce on the command line (full output of './install_wx.sh'[0]
GC> copied as a footnote below):

 I'm almost certain that I won't be able to reproduce this because I don't
have the files that Git is complaining about in my working copy. And for me
the real question is how did they get there?

GC> /opt/lmi/src/lmi[1]$pushd /cache_for_lmi/vcs/wxWidgets
GC> /cache_for_lmi/vcs/wxWidgets /opt/lmi/src/lmi
GC> 
GC> /cache_for_lmi/vcs/wxWidgets[0]$git rev-parse --quiet --verify 
f741031e69de73d5816cc56e99c9beba3ac820de^{commit}
GC> f741031e69de73d5816cc56e99c9beba3ac820de
GC> 
GC> /cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
GC> e38866d3a60 (HEAD) Merge branch 'lzma'

 I think it's too late for this, but I'd expect "git status" to show plenty
of changes in the working tree at this moment.

GC> All of that is exactly what I expect, but then:
GC> 
GC> /cache_for_lmi/vcs/wxWidgets[0]$git checkout 
f741031e69de73d5816cc56e99c9beba3ac820de
GC> error: The following untracked working tree files would be overwritten by 
checkout:
GC>         docs/doxygen/images/drawing-addarctopoint.png
GC> [...snip fourteen similar lines...]
GC>         tests/html/htmprint.cpp
GC> Please move or remove them before you switch branches.
GC> Aborting

 Neither of the files mentioned above exists in e38866d3a60 commit, which
is the current one, yet somehow they do exist in your working tree.

GC> What's the best way to address this? For now, I've edited
GC> a local copy of 'install_wx.sh' and made this change:
GC>   s/checkout/checkout --force/
GC> which seems far less violent than the more popular suggestions
GC> on stackoverflow.

 In principle, this working tree is not supposed to be modified at all, so
running even "git clean -fdx" on it (which is a very destructive command,
please don't run it lightly and never without using "git clean -ndx" first
to confirm what would it do) could be an option. But then neither it nor
forcing the check out shouldn't be necessary in the first place neither
precisely because the working tree is not supposed to be modified.

GC> (Should such a change be committed to the public repository?)

 I'd prefer not to do it because normally it shouldn't be necessary.

GC> With that change, it seems to work:

 Yes, this is not surprising. The situation in its own is definitely not
catastrophic, but I just have no idea how have we got into it.

 Please let me know if you have any inkling of it,
VZ


reply via email to

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