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
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
> >
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
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.
> >
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> > >>
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
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
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:
> >
> >
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"
Ah, my bad. I missed this patch...
Good luck!
-Santiago.
signature.asc
Description: PGP signature
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
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
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
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,
28 matches
Mail list logo