Fwd: git status options feature suggestion

How about "git ls-files -o"?

doh... hadn't even heard of that command.

-- 
Caleb Cushing

Hi,

On Thu, 9 Oct 2008, Caleb Cushing wrote:

quoted

How about "git ls-files -o"?

doh... hadn't even heard of that command.

Which is good!  As ls-files is listed as plumbing.  Users should not need 
to call ls-files, so I like your idea about adding --new, --untracked etc. 
to "git status" (I do not agree with others that "git status" has to stay 
that non-existant "git commit --dry-run").

Could you list exactly which options you want implemented?

Ciao,
Dscho

Johannes Schindelin venit, vidit, dixit 09.10.2008 11:03:

Hi,

On Thu, 9 Oct 2008, Caleb Cushing wrote:

quoted

quoted

How about "git ls-files -o"?

doh... hadn't even heard of that command.

Which is good!  As ls-files is listed as plumbing.  Users should not need 
to call ls-files, so I like your idea about adding --new, --untracked etc. 
to "git status" (I do not agree with others that "git status" has to stay 
that non-existant "git commit --dry-run").

Could you list exactly which options you want implemented?

Requests for stuff like that keep appearing recently (I'm to blame
partially only ;) ). There are 3 issues at hand:

- people are used to "svn status [-v]" like output which can include
untracked as well as tracked unmodified files; there are other valid
reasons why you would want that info

- porc can't do it: git status can't show ignored files, doesn't use
status letters, can't show files with specific status; git diff
--name-status can't show ignored nor untracked files
[In fact, the description of "git diff" says "files which you could
add", which should include untracked files, but doesn't.]

- plumb uses conflicting letters: git ls-files output conflicts with git
diff --name-status output

So I guess it's time for a usability effort in this area. A few
questions before going about that:

- I think change of existing behaviour is unavoidable (make ls-files and
diff --name-status consistent). Is that something to do now or rather
before 1.7? Is porc (diff) supposed to be changed or plumb (ls-files)?

- How strong should the tie between git status and git commit be?
Current git status is basically git commit -n, with the usual meaning of
"-n" (such as for prune etc."), not with the current meaning of git
commit -n, sigh...

A few radical suggestions might be:

1. make ls-files and diff --name-status use compatible letters

2. rename git commit -n to git commit -b (as in bypass), make git commit
-n do what's expected ("--dry-run", n as in duNNo yet)

3. rename git status to git commit -n

4. make git status generate git diff --name-status like output

(3+4)'. make git status -l generate git diff --name-status like output
(l as in status Letter) as an alternative to 3+4

Michael

Could you list exactly which options you want implemented?

--new --untracked --modified

I believe there are other states as well that I'm not thinking of off
the top of my head. Those should probably be included as well. another
option could be to have an option --filter=modified for example.

Requests for stuff like that keep appearing recently
...
 Michael

all way over my head


-- 
Caleb Cushing

On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber
[off-list ref] wrote:
<snip>

A few radical suggestions might be:

1. make ls-files and diff --name-status use compatible letters

2. rename git commit -n to git commit -b (as in bypass), make git commit
-n do what's expected ("--dry-run", n as in duNNo yet)

Ouch.  Please not -b.  I guess I need to get my other suggestions
upstream if I want to avoid option conflicts like this...

3. rename git status to git commit -n

4. make git status generate git diff --name-status like output

I'd really prefer to be able to get staged vs. unstaged information
out of status.  And the single-letter output, like what cvs/svn/hg
have, is less descriptive here.  (Sure, git status could use some
cleanup IMO, but a word instead of a letter for modification status is
a usability improvement in git over those other systems for new VCS
users.)

(3+4)'. make git status -l generate git diff --name-status like output
(l as in status Letter) as an alternative to 3+4

That seems nicer.


And another radical suggestion (wasn't this brought up before too?):

5. Allow limiting the status output to a set of paths.  diff, log,
add, grep, etc. can all take a subdirectory name and limit their
operation to files recursively underneath that path, but git status
doesn't do so when you run 'git status DIR'.  I know why it currently
behaves as it does, but it sure seems like unnecessary UI
inconsistency.


Just my $0.02,
Elijah

Hi,

On Thu, 9 Oct 2008, Michael J Gruber wrote:

1. make ls-files and diff --name-status use compatible letters

ls-files and diff (at least partially) are plumbing.  Breaking backwards 
compatibility in these is out of the question.

Ciao,
Dscho

On Thu, Oct 09, 2008 at 05:12:24PM +0200, Michael J Gruber wrote:

- people are used to "svn status [-v]" like output which can include
untracked as well as tracked unmodified files; there are other valid
reasons why you would want that info

- porc can't do it: git status can't show ignored files, doesn't use
status letters, can't show files with specific status; git diff
--name-status can't show ignored nor untracked files
[In fact, the description of "git diff" says "files which you could
add", which should include untracked files, but doesn't.]

- plumb uses conflicting letters: git ls-files output conflicts with git
diff --name-status output

So I guess it's time for a usability effort in this area. A few
questions before going about that:

A week or two ago I came across yet another git-status annoyance: it
needs write access to the repository to run (I was helping somebody with
a task on a shared box, and I wanted to run status in their repository
using my account).

I considered submitting a patch to fix this, but I think it is really
more fundamental. I use status to get an overview of what's going on in
a repo, but it is intimately related to a potential commit.

And this bleeds into other areas, too. Why should the "what's going on
in this repo" command prefix all lines with "#"? We would have more
freedom to change the format if it weren't required to be a comment
line in a commit message.

So I think it is probably reasonable to think about a new command (which
would not be called status) that shows this information. What do people
want to see? And in what format? Some things I would want or have seen
requested are:

 - staged and unstaged changes in --name-status format

 - files without changes (with a -v flag).

 - untracked files

 - current branch / detached HEAD (with relationship to tracked branch,
   if any)

And maybe after hashing it out, it turns out it's not that different
from "git status" and we should just stick with that. But I would be
curious to hear proposals.

- I think change of existing behaviour is unavoidable (make ls-files and
diff --name-status consistent). Is that something to do now or rather
before 1.7? Is porc (diff) supposed to be changed or plumb (ls-files)?

I don't think you would want to just change the default; you would
probably add a new option to ls-files to use the --name-status letters,
and then use that in your new porcelain.

- How strong should the tie between git status and git commit be?
Current git status is basically git commit -n, with the usual meaning of
"-n" (such as for prune etc."), not with the current meaning of git
commit -n, sigh...

I think the theoretical tool I mentioned would benefit from breaking
this connection. But I don't know whether it is prudent to take the
"status" name in doing so. Even if we decided to do so, it would
probably happen something like:

  1. Introduce git-wtf, a new status-like tool. Deprecate git-status in
     its current form.

  2. Wait a really long time.

  3. Rename git-wtf to git-status.

So either way, the first step is an alternative replacement command.

-Peff

On Sun, Oct 12, 2008 at 12:49:00AM -0400, Jeff King wrote:

A week or two ago I came across yet another git-status annoyance: it
needs write access to the repository to run (I was helping somebody with
a task on a shared box, and I wanted to run status in their repository
using my account).

I considered submitting a patch to fix this, but I think it is really
more fundamental. I use status to get an overview of what's going on in
a repo, but it is intimately related to a potential commit.

BTW, in case anybody is interested, here is the patch. Like I said, I
think we are better off with an alternative to "status", but maybe this
is useful to somebody anyway.

---

diff --git a/builtin-commit.c b/builtin-commit.c
index b01ad9f..8951364 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c

@@ -217,7 +217,8 @@ static void create_base_index(void)
 		exit(128); /* We've already reported the error, finish dying */
 }
 
-static char *prepare_index(int argc, const char **argv, const char *prefix)
+static char *prepare_index(int argc, const char **argv, const char *prefix,
+		int status_only)
 {
 	int fd;
 	struct string_list partial;

@@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
 	 * We still need to refresh the index here.
 	 */
 	if (!pathspec || !*pathspec) {
-		fd = hold_locked_index(&index_lock, 1);
+		fd = hold_locked_index(&index_lock, 0);
+		if (fd < 0) {
+			if (!status_only)
+				die("unable to lock index: %s",
+						strerror(errno));
+			return get_index_file();
+		}
 		refresh_cache(REFRESH_QUIET);
 		if (write_cache(fd, active_cache, active_nr) ||
 		    commit_locked_index(&index_lock))

@@ -869,7 +876,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 
 	argc = parse_and_validate_options(argc, argv, builtin_status_usage, prefix);
 
-	index_file = prepare_index(argc, argv, prefix);
+	index_file = prepare_index(argc, argv, prefix, 1);
 
 	commitable = run_status(stdout, index_file, prefix, 0);
 

@@ -953,7 +960,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 
 	argc = parse_and_validate_options(argc, argv, builtin_commit_usage, prefix);
 
-	index_file = prepare_index(argc, argv, prefix);
+	index_file = prepare_index(argc, argv, prefix, 0);
 
 	/* Set up everything for writing the commit object.  This includes
 	   running hooks, writing the trees, and interacting with the user.  */