Re: git status always modifies index?

Jonathan Nieder writes: > I am worried that the project is not learning from what happened here. > ... > Fair enough, though that feels like overengineering. But I *still* > don't see what that has to do with the name "no-optional-locks". When > is a lock *optional*? And

Re: git status always modifies index?

On Mon, Nov 27, 2017 at 12:57:31PM -0800, Jonathan Nieder wrote: > > I actually consider "--no-optional-locks" to be such an aspirational > > feature. I didn't go digging for other cases (though I'm fairly certain > > that "diff" has one), but hoped to leave it for further bug reports ("I > >

Re: git status always modifies index?

Hi, Jeff King wrote: > On Sun, Nov 26, 2017 at 06:35:56PM +0900, Junio C Hamano wrote: >> Having a large picture option like "--read-only" instead of ending >> up with dozens of "we implemented a knob to tweak only this little >> piece, and here is an option to trigger it" would help users in

Re: git status always modifies index?

Hi Junio, On Mon, 27 Nov 2017, Junio C Hamano wrote: > Jeff King writes: > > > Again, maybe the bit above explains my viewpoint a bit more. I'm > > certainly sympathetic to the pain of upstreaming. > > > > I do disagree with the "no good reason" for this particular patch. > > >

Re: git status always modifies index?

Hi, Johannes Schindelin wrote: > On Mon, 27 Nov 2017, Jeff King wrote: >> [...] IMHO it argues for GfW trying to land patches upstream first, and >> then having them trickle in as you merge upstream releases. > > You know that I tried that, and you know why I do not do that anymore: it > simply

Re: git status always modifies index?

Hi Peff, On Mon, 27 Nov 2017, Jeff King wrote: > [...] IMHO it argues for GfW trying to land patches upstream first, and > then having them trickle in as you merge upstream releases. You know that I tried that, and you know why I do not do that anymore: it simply takes too long, and the review

Re: git status always modifies index?

On Mon, Nov 27, 2017 at 09:47:20AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I'm not sure I agree. Lockless writes are actually fine for the original > > use case of --no-optional-locks (which is a process for the same user > > that just happens to run in the

Re: git status always modifies index?

Jeff King writes: > Again, maybe the bit above explains my viewpoint a bit more. I'm > certainly sympathetic to the pain of upstreaming. > > I do disagree with the "no good reason" for this particular patch. > > Certainly you should feel free to present your hunches. I'd expect

Re: git status always modifies index?

On Sun, Nov 26, 2017 at 10:55:01PM +0100, Johannes Schindelin wrote: > > I remain unconvinced that we have actually uncovered a serious problem. > > You did not. A colleague of mine did. And it was a problem in Git for > Windows only, caused by the changes necessitated by yours (which even used

Re: git status always modifies index?

On Mon, Nov 27, 2017 at 01:56:41PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I actually consider "--no-optional-locks" to be such an aspirational > > feature. I didn't go digging for other cases (though I'm fairly certain > > that "diff" has one), but hoped to leave

Re: git status always modifies index?

Jeff King writes: > I actually consider "--no-optional-locks" to be such an aspirational > feature. I didn't go digging for other cases (though I'm fairly certain > that "diff" has one), but hoped to leave it for further bug reports ("I > used the option, ran command X, and saw

Re: git status always modifies index?

On Sun, Nov 26, 2017 at 06:35:56PM +0900, Junio C Hamano wrote: > Having a large picture option like "--read-only" instead of ending > up with dozens of "we implemented a knob to tweak only this little > piece, and here is an option to trigger it" would help users in the > long run, but we

Re: git status always modifies index?

Jeff King writes: > I'm not sure I agree. Lockless writes are actually fine for the original > use case of --no-optional-locks (which is a process for the same user > that just happens to run in the background). The phrase "lockless write" scares me---it sounds as if you

Re: git status always modifies index?

Hi Peff, On Sun, 26 Nov 2017, Jeff King wrote: > On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote: > > > > Right, I went a little off track of your original point. > > > > > > What I was trying to get at is that naming it "status --no-lock-index" > > > would not be the same

Re: git status always modifies index?

On Sun, Nov 26, 2017 at 12:32:13PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > What I was trying to get at is that naming it "status --no-lock-index" > > would not be the same thing (even though with the current implementation > > it would behave the same). IOW, can we

Re: git status always modifies index?

On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote: > > Right, I went a little off track of your original point. > > > > What I was trying to get at is that naming it "status --no-lock-index" > > would not be the same thing (even though with the current implementation > > it

Re: git status always modifies index?

Junio C Hamano writes: > Jeff King writes: > >> What I was trying to get at is that naming it "status --no-lock-index" >> would not be the same thing (even though with the current implementation >> it would behave the same). IOW, can we improve the

Re: git status always modifies index?

Jeff King writes: > What I was trying to get at is that naming it "status --no-lock-index" > would not be the same thing (even though with the current implementation > it would behave the same). IOW, can we improve the documentation of > "status" to point to make it easier to

Re: git status always modifies index?

Hi Peff, On Wed, 22 Nov 2017, Jeff King wrote: > On Wed, Nov 22, 2017 at 01:56:35PM -0800, Jonathan Nieder wrote: > > > Jeff King wrote: > > > On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: > > > > >> That said, I wonder if this use case is an illustration that a name > > >>

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 01:56:35PM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: > > >> That said, I wonder if this use case is an illustration that a name > >> like --no-lock-index (as was used in Git for Windows when this

Re: git status always modifies index?

Jeff King wrote: > On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: >> That said, I wonder if this use case is an illustration that a name >> like --no-lock-index (as was used in Git for Windows when this feature >> first appeared) or --no-refresh-on-disk-index (sorry, I am

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: > Nathan Neulinger wrote[1]: > > > I just got an answer to my stackoverflow question on this, > > apparently it's already implemented: > > > >

Re: git status always modifies index?

Hi, Nathan Neulinger wrote[1]: > I just got an answer to my stackoverflow question on this, > apparently it's already implemented: > > https://stackoverflow.com/questions/47436939/how-to-run-git-status-without-modifying-git-index-such-as-in-a-prompt-command > > There is a "--no-optional-locks"

Re: git status always modifies index?

Ah, my bad. I missed this patch... Good luck! -Santiago. signature.asc Description: PGP signature

Re: git status always modifies index?

I just got an answer to my stackoverflow question on this, apparently it's already implemented: https://stackoverflow.com/questions/47436939/how-to-run-git-status-without-modifying-git-index-such-as-in-a-prompt-command There is a "--no-optional-locks" command in 2.15 that looks like it does

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 09:37:09AM -0600, Nathan Neulinger wrote: > What I'm meaning is - why does it need to write the index back out to disk? > > From looking at the code in builtin/commit.c it looks like it takes a lock > on the index, collects the status, and then unconditionally rewrites the

Re: git status always modifies index?

What I'm meaning is - why does it need to write the index back out to disk? From looking at the code in builtin/commit.c it looks like it takes a lock on the index, collects the status, and then unconditionally rewrites the index file. I'm proposing that the update_index_if_able call not

Re: git status always modifies index?

Hi Nathan. Do you mean git-status writing an index file? What would you suggest for git-status to compute which files have changed without modifying an index-file? Or are you suggesting git-status to fail if the index file doesn't belong to the user-id who invoked the command... Thanks,

git status always modifies index?

Current code appears to always attempt an index refresh, which results in file permission changes if you run a 'git status' as a privileged account. Would be nice if there were an option available to ask git status to NOT update the index. Even better would be if it was smart about the