git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* git > 2.10.1 fails to update index on macOS 10.14.5
@ 2020-03-23 14:37 Jonathan Smalls
  2020-03-23 23:13 ` brian m. carlson
  0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Smalls @ 2020-03-23 14:37 UTC (permalink / raw)
  To: git; +Cc: Torey Adler - NOAA Federal

After upgrading my work station, I found in git-2.22 that git would not 
recognize any file changes until I ran  `git reset --hard`. I thought 
that it was a problem with my own settings.
	However I upgraded to git-2.25, and the problem actually got worse. In 
2.25 the index still failed to update, but `git reset --hard` no longer 
had any effect.

I have not looked to find exactly where the breaking change was 
introduced, but I have since downgraded to git-2.10.1 and now get the 
expected behavior.
-- 
http://jon.smalls.rocks
857 301 9231

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git > 2.10.1 fails to update index on macOS 10.14.5
  2020-03-23 14:37 git > 2.10.1 fails to update index on macOS 10.14.5 Jonathan Smalls
@ 2020-03-23 23:13 ` brian m. carlson
  2020-03-24  1:36   ` Jonathan Smalls
  0 siblings, 1 reply; 5+ messages in thread
From: brian m. carlson @ 2020-03-23 23:13 UTC (permalink / raw)
  To: Jonathan Smalls; +Cc: git, Torey Adler - NOAA Federal

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On 2020-03-23 at 14:37:30, Jonathan Smalls wrote:
> After upgrading my work station, I found in git-2.22 that git would not
> recognize any file changes until I ran  `git reset --hard`. I thought that
> it was a problem with my own settings.
> 	However I upgraded to git-2.25, and the problem actually got worse. In 2.25
> the index still failed to update, but `git reset --hard` no longer had any
> effect.

I have a bunch of colleagues who use the latest Git on macOS, so I
expect it does work most of the time.  Let's see if we can figure out
what's going on here.

What exactly do you mean by "doesn't recognize any file changes"?  Can
you tell us what commands you ran and what you expected to see, and what
you actually saw?  That information would be helpful for us to track
down what might be happening.

Also, are you using any specific workflow or tool that might be related?
Are you using an editor integration or GUI, and if so, does this happen
without that editor integration or GUI as well?
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git > 2.10.1 fails to update index on macOS 10.14.5
  2020-03-23 23:13 ` brian m. carlson
@ 2020-03-24  1:36   ` Jonathan Smalls
  2020-03-24 23:59     ` brian m. carlson
  0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Smalls @ 2020-03-24  1:36 UTC (permalink / raw)
  To: brian m. carlson, git, Torey Adler - NOAA Federal



On 3/23/20 19:13, brian m. carlson wrote:
> What exactly do you mean by "doesn't recognize any file changes"?  Can
> you tell us what commands you ran and what you expected to see, and what
> you actually saw?  That information would be helpful for us to track
> down what might be happening.

In git-2.22:

I would write a change to a file. Running `git status` would return that 
the working directory was clean, and `git commit .` would show that 
there were no changes to commit.
	However I could target a specific file like `git commit test.txt`, and 
git would successfully recognize the change, and write the commit. I 
could also run `git reset --hard`, and that would update the index to 
reflect the change that I had just written rather than resetting the 
working directory to match the latest commit. If I ran `git reset 
--hard` a second time, that command would reset the working directory.

In normal operation, I would expect to `git status` to recognize a 
change in a file once it had already been added to the index. I would 
expect `git commit .` to commit all files in the current directory, and 
subdirectories without having to specify their file names. I would 
expect `git reset --hard` to revert the working directory to match the 
latest commit the first time.

In git-2.25

I would write a change to a file. `git status` would continue to show 
that the working directory was clean, but I was not longer able to 
target a particular file to force a commit. `git reset --hard` had no 
effect, and still showed that the working directory was clean without 
resetting the working directory.
	To successfully commit a file I would have to run `git rm --cached 
test.txt` to target a file, and then `git add test.txt` for git to 
update its index, and recognize the change.

I would expect the same normal operation in git-2.25.

> 
> Also, are you using any specific workflow or tool that might be related?
> Are you using an editor integration or GUI, and if so, does this happen
> without that editor integration or GUI as well?

I use git on the command line, so there should be no external 
interference with its normal function.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git > 2.10.1 fails to update index on macOS 10.14.5
  2020-03-24  1:36   ` Jonathan Smalls
@ 2020-03-24 23:59     ` brian m. carlson
  2020-03-30 11:20       ` Jonathan Smalls
  0 siblings, 1 reply; 5+ messages in thread
From: brian m. carlson @ 2020-03-24 23:59 UTC (permalink / raw)
  To: Jonathan Smalls; +Cc: git, Torey Adler - NOAA Federal

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On 2020-03-24 at 01:36:18, Jonathan Smalls wrote:
> 
> 
> On 3/23/20 19:13, brian m. carlson wrote:
> > What exactly do you mean by "doesn't recognize any file changes"?  Can
> > you tell us what commands you ran and what you expected to see, and what
> > you actually saw?  That information would be helpful for us to track
> > down what might be happening.
> 
> In git-2.22:
> 
> I would write a change to a file. Running `git status` would return that the
> working directory was clean, and `git commit .` would show that there were
> no changes to commit.
> 	However I could target a specific file like `git commit test.txt`, and git
> would successfully recognize the change, and write the commit. I could also
> run `git reset --hard`, and that would update the index to reflect the
> change that I had just written rather than resetting the working directory
> to match the latest commit. If I ran `git reset --hard` a second time, that
> command would reset the working directory.

Does running "ls -l" on the file before and after show different
timestamps and file sizes?  Does "git config -l | grep -iE 'checkstat|ctime'"
show anything?  Can you use the stat(1) command to tell us whether the
change results in a device or inode number change (if that's possible
using the macOS version)?
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git > 2.10.1 fails to update index on macOS 10.14.5
  2020-03-24 23:59     ` brian m. carlson
@ 2020-03-30 11:20       ` Jonathan Smalls
  0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Smalls @ 2020-03-30 11:20 UTC (permalink / raw)
  To: brian m. carlson, git, Torey Adler - NOAA Federal

I also need to specify, it looks like I was on git version 2.21.0, not 
2.22.0.

On 3/24/20 19:59, brian m. carlson wrote:
> Does running "ls -l" on the file before and after show different
> timestamps and file sizes? 

Changing the index file updated the file modification time appropriately.

--

Mar30 0715.19 [jsmalls:~/Documents … c310/lorenzCurve] master+
     >> vim index.py

     Mar30 0715.31 [jsmalls:~/Documents … c310/lorenzCurve] master+ 8s
     >> ls -l
total 56
-rw-r--r--  1 jsmalls  staff   1650 Mar 30 07:15 index.py
-rw-r--r--@ 1 jsmalls  staff  16878 Mar 29 20:10 lorenzCurve.png
-rw-r--r--@ 1 jsmalls  staff   1800 Mar 26 09:05 pop2010.npy

Does "git config -l | grep -iE 'checkstat|ctime'"
> show anything? Can you use the stat(1) command to tell us whether the
> change results in a device or inode number change (if that's possible
> using the macOS version)?

The git config command returns an empty result. I am not sure what I 
should see in the stat command, but I have included the result here.

--

Mar30 0715.40 [jsmalls:~/Documents … c310/lorenzCurve] master+
     >> git config -l | grep -iE 'checkstat|ctime'

     Mar30 0716.19 [jsmalls:~/Documents … c310/lorenzCurve] master+ 1
     >> stat
1054203952 723 crw--w---- 1 jsmalls tty 268435456 0 "Mar 30 07:16:43 
2020" "Mar 30 07:16:43 2020" "Mar 30 07:16:43 2020" "Dec 31 19:00:00 
1969" 131072 0 0 (stdin)


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-23 14:37 git > 2.10.1 fails to update index on macOS 10.14.5 Jonathan Smalls
2020-03-23 23:13 ` brian m. carlson
2020-03-24  1:36   ` Jonathan Smalls
2020-03-24 23:59     ` brian m. carlson
2020-03-30 11:20       ` Jonathan Smalls

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git