I did
git config --global core.trustctime false
git config --global core.checkStat minimal
No difference
-rob
On 4/21/19 1:22 PM, Philip Oakley wrote:
On 21/04/2019 18:07, rob wrote:
possibly. What do I do about that?
--rob
see below.
On 4/21/19 9:03 AM, Philip Oakley wrote:
Hi Rob,
On 21/04/2019 13:34, rob wrote:
didn't work. I did not get any error messages, just didn't work.
After I did
git reset --hard
git status
I see the same 3 files that say changes not staged for commit:
modified and it lists the same 3 files.
Could this be that the file timestamps are being changed in the
background and git is detecting those timestamp changes, even when
there is no change to the files.
- Just as thought.
(In-line posting is preferred, so as to see the replies in context)
Philip
If it is that, Try
core.trustctime::
If false, the ctime differences between the index and the
working tree are ignored; useful when the inode change time
is regularly modified by something outside Git (file system
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
Or,
core.checkStat::
When missing or is set to `default`, many fields in the stat
structure are checked to detect if a file has been modified
since Git looked at it. When this configuration variable is
set to `minimal`, sub-second part of mtime and ctime, the
uid and gid of the owner of the file, the inode number (and
the device number, if Git was compiled to use it), are
excluded from the check among these fields, leaving only the
whole-second part of mtime (and ctime, if `core.trustCtime`
is set) and the filesize to be checked.
--rob
On 4/21/19 1:03 AM, Adrian H wrote:
If I understand the commands you are using correctly, you are
referencing the remote repo. You need to reference the local repo.
So try using the following commands:
git checkout -- alecthomas/gometalinter
git checkout -- kisielk/errcheck
git checkout -- rogpeppe/godef
Or if those are the only files that have been modified, then you can
use the following single command:
git reset --hard
and that will reset all files that have not been staged.
HTH
A
On Sat, Apr 20, 2019 at 11:22 PM rob <drrob100@xxxxxxxxxxxx> wrote:
I have my own code at a github repository, using Go. Part of
using Go
libraries not part of the official Go people is by using a system
they
call go get. This essentially uses git to, well, go get source
code.
Mine are at github.com and golang.org. My computer runs
LinuxMint 19.1.
I used goland IDE from jetbrains to run go fmt on my entire project.
Now I am getting this message that I cannot get rid of:
changes not staged for commit:
modified: github.com/alecthomas/gometalinter (modified content)
modified: github.com/kisielk/errcheck (modified content)
modified: github.com/rogpeppe/godef (modified content)
I do not want any changes to central repos to be tracked or
committed,
but I cannot undo this. I tried, for example,
git checkout -- github.com/alecthomas/gometalinter
I don't get an error message but it does not do anything. The
file is
not changes, and git status show me the same information, ie, these
files have changes not staged for commit.
I do not know how to restore these files to the state they were
in in
the repo, and to have my own git tree not to flag this as an
unstaged
alteration. Running rm -rfv on the repos on my computer, then
running
go get to restore them does not change git status. It still sahs
changes
not stated for commit: modified.
This happens for the above 3 tree items.
How do I restore these to the github remote repository condition
and not
have my own git tree mark these as changed?
--rob solomon
