threads / patch / 22295

patchgit status: do not require write permission

Subject: [PATCH] git status: do not require write permission

## tl;dr

8 messages between Jan 20, 2010 and Jan 20, 2010. Diffs are folded; open one to read it.

replies: 7people: 3as markdown or json

Johannes Schindelin· Jan 20, 2010, 00:06 UTC · lore

Today, git status played violin on my nerves for the very last time. There is no good reason, really none, for git status to require write permissions. If the index is not up-to-date, so be it, I cannot commit anyway.

But in most cases, the index _is_ up-to-date, and now I can tell my fellow former users that their repository XYZ.git does not have any uncommitted changes, so can they please delete it to free up some disk space, thank you very much.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin-commit.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)
Show changes to builtin-commit.c +7 −5
diff --git a/builtin-commit.c b/builtin-commit.c
index 55676fd..9eccc51 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -325,11 +325,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
 	 * We still need to refresh the index here.
 	 */
 	if (!pathspec || !*pathspec) {
-		fd = hold_locked_index(&index_lock, 1);
-		refresh_cache_or_die(refresh_flags);
-		if (write_cache(fd, active_cache, active_nr) ||
-		    commit_locked_index(&index_lock))
-			die("unable to write new_index file");
+		fd = hold_locked_index(&index_lock, 0);
+		if (fd >= 0) {
+			refresh_cache_or_die(refresh_flags);
+			if (write_cache(fd, active_cache, active_nr) ||
+			    commit_locked_index(&index_lock))
+				die("unable to write new_index file");
+		}
 		commit_style = COMMIT_AS_IS;
 		return get_index_file();
 	}

-- 
1.6.4.297.gcb4cc
Jeff King· Jan 20, 2010, 00:28 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git status: do not require write permission

On Wed, Jan 20, 2010 at 01:06:17AM +0100, Johannes Schindelin wrote:
> Today, git status played violin on my nerves for the very last time.
> There is no good reason, really none, for git status to require
> write permissions.  If the index is not up-to-date, so be it, I
> cannot commit anyway.

I agree it is annoying, but this patch does not apply (and is no longer needed) on master since the status-is-no-longer-commit-dry-run series has been merged.

I don't know if it is worth putting your fix onto maint.
-Peff
Johannes Schindelin· Jan 20, 2010, 00:35 UTC · re: Jeff King · lore

Re: [PATCH] git status: do not require write permission

Hi,
On Tue, 19 Jan 2010, Jeff King wrote:
Show 10 quoted lines
> On Wed, Jan 20, 2010 at 01:06:17AM +0100, Johannes Schindelin wrote:
> 
> > Today, git status played violin on my nerves for the very last time.
> > There is no good reason, really none, for git status to require
> > write permissions.  If the index is not up-to-date, so be it, I
> > cannot commit anyway.
> 
> I agree it is annoying, but this patch does not apply (and is no longer
> needed) on master since the status-is-no-longer-commit-dry-run series
> has been merged.

I was working on top of 'next'. And only after I fetched afresh from git://repo.or.cz/git.git/.

So for me and my nerves, the patch series came way too late.

Ciao, Dscho

Johannes Schindelin· Jan 20, 2010, 00:38 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git status: do not require write permission

Hi,
On Wed, 20 Jan 2010, Johannes Schindelin wrote:
Show 15 quoted lines
> On Tue, 19 Jan 2010, Jeff King wrote:
> 
> > On Wed, Jan 20, 2010 at 01:06:17AM +0100, Johannes Schindelin wrote:
> > 
> > > Today, git status played violin on my nerves for the very last time.
> > > There is no good reason, really none, for git status to require
> > > write permissions.  If the index is not up-to-date, so be it, I
> > > cannot commit anyway.
> > 
> > I agree it is annoying, but this patch does not apply (and is no longer
> > needed) on master since the status-is-no-longer-commit-dry-run series
> > has been merged.
> 
> I was working on top of 'next'.  And only after I fetched afresh from 
> git://repo.or.cz/git.git/.

To be precise, the commit I based mine on is 2cd0ddca4b6f2ff24fcd7b24030c97ec20ead85c which was done on Mon Jan 18 18:34:16 2010 -0800 according to Git.

Ciao, Dscho "who will think 3 times before making a patch next time"

Junio C Hamano· Jan 20, 2010, 00:39 UTC · re: Jeff King · lore

Re: [PATCH] git status: do not require write permission

Jeff King <peff@peff.net> writes:
Show 12 quoted lines
> On Wed, Jan 20, 2010 at 01:06:17AM +0100, Johannes Schindelin wrote:
>
>> Today, git status played violin on my nerves for the very last time.
>> There is no good reason, really none, for git status to require
>> write permissions.  If the index is not up-to-date, so be it, I
>> cannot commit anyway.
>
> I agree it is annoying, but this patch does not apply (and is no longer
> needed) on master since the status-is-no-longer-commit-dry-run series
> has been merged.
>
> I don't know if it is worth putting your fix onto maint.

I think the patch itself makes sense, even though the log message seems to be with more noise and frustrationthan with useful information.

And "for the very last time" is probably a good characterization, as status will no longer be "commit --dry-run" in the coming release ;-)

Junio C Hamano· Jan 20, 2010, 01:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] git status: do not require write permission

Junio C Hamano <gitster@pobox.com> writes:
Show 16 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> On Wed, Jan 20, 2010 at 01:06:17AM +0100, Johannes Schindelin wrote:
>>
>>> Today, git status played violin on my nerves for the very last time.
>>> There is no good reason, really none, for git status to require
>>> write permissions.  If the index is not up-to-date, so be it, I
>>> cannot commit anyway.
>>
>> I agree it is annoying, but this patch does not apply (and is no longer
>> needed) on master since the status-is-no-longer-commit-dry-run series
>> has been merged.
>>
>> I don't know if it is worth putting your fix onto maint.
>
> I think the patch itself makes sense,...

Actually, I think it was somewhat a selfish patch and forgot that the codepath is shared with a mode of operation where we should guarantee that the index is updated, namely "git commit".

I think this would be a good addition to 'maint'. I am not sure if it is worth forward-porting to "commit --dry-run", though. On one hand, it might show what would happen if you ran "commit" better (i.e. you will be told that you cannot write into it), but it is debatable if that is the reason why people may want to run "commit --dry-run".

-- >8 --
Subject: status: don't require the repository to be writable

We need to update the index before hooks run when actually making a commit, but we shouldn't have to write the index when running "status". If we can, then we have already spent cycles to refresh the index and it is a waste not to write it out, but it is not a disaster if we cannot write it out. The main reason the user is running "git status" is to get the "status", and refreshing the index is a mere side effect that we can do without.

Discovery and initial attempted fix by Dscho.
---
 builtin-commit.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)
Show changes to builtin-commit.c +6 −4
diff --git a/builtin-commit.c b/builtin-commit.c
index 33aa593..83b7c35 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -278,11 +278,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
 	 * We still need to refresh the index here.
 	 */
 	if (!pathspec || !*pathspec) {
-		fd = hold_locked_index(&index_lock, 1);
+		fd = hold_locked_index(&index_lock, !is_status);
 		refresh_cache(refresh_flags);
-		if (write_cache(fd, active_cache, active_nr) ||
-		    commit_locked_index(&index_lock))
-			die("unable to write new_index file");
+		if (0 <= fd) {
+			if (write_cache(fd, active_cache, active_nr) ||
+			    commit_locked_index(&index_lock))
+				die("unable to write new_index file");
+		}
 		commit_style = COMMIT_AS_IS;
 		return get_index_file();
 	}
Johannes Schindelin· Jan 20, 2010, 01:23 UTC · re: Junio C Hamano · lore

Re: [PATCH] git status: do not require write permission

Hi,
On Tue, 19 Jan 2010, Junio C Hamano wrote:
Show 17 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > On Wed, Jan 20, 2010 at 01:06:17AM +0100, Johannes Schindelin wrote:
> >
> >> Today, git status played violin on my nerves for the very last time.
> >> There is no good reason, really none, for git status to require
> >> write permissions.  If the index is not up-to-date, so be it, I
> >> cannot commit anyway.
> >
> > I agree it is annoying, but this patch does not apply (and is no longer
> > needed) on master since the status-is-no-longer-commit-dry-run series
> > has been merged.
> >
> > I don't know if it is worth putting your fix onto maint.
> 
> I think the patch itself makes sense, even though the log message seems to
> be with more noise and frustrationthan with useful information.
If you think so.
> And "for the very last time" is probably a good characterization, as
> status will no longer be "commit --dry-run" in the coming release ;-)

This comment was because I was fully prepared to do the same as with so many patches: keep them in my personal repository until time finally tells that that patch should go into 'next'.

And as you realized, I managed to forget a commit --amend, which would have replaced 1 with !is_status.

BTW you can tell me directly that you do not want any patches from me anymore, rather than dancing around the issue. I kind of figured that already anyway.

Ciao, Dscho

Junio C Hamano· Jan 20, 2010, 01:38 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git status: do not require write permission

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> BTW you can tell me directly that you do not want any patches from me 
> anymore, rather than dancing around the issue.  I kind of figured that 
> already anyway.
Oh, what gave you that impression?

I don't like getting patches that go only halfway, making things work better for some people but at the same time breaking things for others, without following thorough for a long time, and that is regardless of where the patches came from.

They linger on 'pu' forever and forces me to choose one of the three outcome:

 (1) discard it, even if it is promising;
 (2) make myself a janitor and filling the gap;
 (3) keep it on 'pu' even longer, while occassionally suffering merge
     conflicts with topics that touch the same textual area from more
     responsive people.

I try to avoid (1) but I obviously don't want to do (2), especially when I know the topic originally came from a capable hand.

If anything, the more promising the patch series that the original author didn't follow through, the worse it will make me feel to discard it. If you feel that I get grumpy about many of your patches not followed through than about other people's patches, perhaps it is a sign that I consider that the aim (not necessarily the execution) of your topics are better than the topics from others.

So don't take it personally.

← back to recent threads