git status options feature suggestion

git status options feature suggestion

[Caleb Cushing]

I was just doing a git status for a large add and all I really wanted
to see was the untracked files maybe git status could have options
like --new --untracked --modified to only show those.

I'm not on the list.

--
Caleb Cushing

Re: git status options feature suggestion

[Jeff King]

On Thu, Oct 09, 2008 at 01:34:41AM -0400, Caleb Cushing wrote:

> I was just doing a git status for a large add and all I really wanted
> to see was the untracked files maybe git status could have options
> like --new --untracked --modified to only show those.

How about "git ls-files -o"?

-Peff

Fwd: git status options feature suggestion

[Caleb Cushing]

> How about "git ls-files -o"?

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

-- 
Caleb Cushing

Re: Fwd: git status options feature suggestion

[Johannes Schindelin]

Hi,

On Thu, 9 Oct 2008, Caleb Cushing wrote:

> > 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

Re: Fwd: git status options feature suggestion

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 09.10.2008 11:03:
> Hi,
> 
> On Thu, 9 Oct 2008, Caleb Cushing wrote:
> 
>>> 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

Re: Fwd: git status options feature suggestion

[Caleb Cushing]

> 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

Re: Fwd: git status options feature suggestion

[Elijah Newren]

On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber
<git@drmicha.warpmail.net> 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

Re: Fwd: git status options feature suggestion

[Johannes Schindelin]

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

Re: Fwd: git status options feature suggestion

[Jeff King]

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

Re: Fwd: git status options feature suggestion

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> So I think it is probably reasonable to think about a new command (which
> would not be called status) that shows this information.

I was going to suggest the same.  "git st" for people who come from "svn st"
so that "git status" can be kept as traditional "preview of 'git commit'".

And just make it mimic whatever folks accustomed to "svn st" would expect,
modulo we would need two status letters to signal difference between
(HEAD, index), and (index, worktree).  Perhaps three if you want to show
difference between (HEAD, worktree) while at it.

And no, I have not seen any argument good enough to change ls-files nor
diff-$lowlevel output and break people's existing scripts.

Re: Fwd: git status options feature suggestion

[Jeff King]

On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:

> And just make it mimic whatever folks accustomed to "svn st" would expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree).  Perhaps three if you want to show
> difference between (HEAD, worktree) while at it.

I remember a long time ago you started on a parallel diff walker that
could diff the working tree, the index, and a tree at once. Do you
remember the issues with it?

I think that would be the right tool here to show each file only once,
but with multiple status flags. Something like:

  A M foo

to show that "foo" has been added since the last commit, but there are
modifications in the working tree that have not yet been staged.

-Peff

Re: Fwd: git status options feature suggestion

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I remember a long time ago you started on a parallel diff walker that
> could diff the working tree, the index, and a tree at once. Do you
> remember the issues with it?

Sorry, I don't.

> I think that would be the right tool here to show each file only once,
> but with multiple status flags. Something like:
>
>   A M foo
>
> to show that "foo" has been added since the last commit, but there are
> modifications in the working tree that have not yet been staged.

One thing to keep in mind is what to do when you would want to detect
renames.  The parallel walk would be Ok but between HEAD and index there
could be renames involved, and at that point it would get quite tricky.
Once the index is in-core, I think it hurts us much to walk HEAD vs index
and index vs working tree in separate passes.

I think it is perfectly fine to run the diff-index first, and keep the
result from it in a string_list, and then run "diff-files" and annotate
the string_list with the output from it.

Something like...

	struct git_st_data {
        	const char *head_path;
                char head_to_index_status;
                char index_to_worktree_status;
	};

	static int cmp_head_path(const void *a_, const void *b_)
        {
		struct git_st_data *a = (struct git_st_data *)a_;
		struct git_st_data *b = (struct git_st_data *)b_;
		return strcmp(a->head_path, b->head_path);
        }

	static void git_st_inspect_index_cb(struct diff_queue_struct *q,
        			struct diff_options *opts, void *data)
	{
		struct string_list *git_st_list = data;
		int i;
		for (i = 0; i < q->nr; i++) {
                	struct git_st_data *d;
                        struct string_list_item *e;
			struct diff_filepair *fp = &q->queue[i];
			d = xcalloc(1, sizeof(*d));
                        d->head_path = xstrdup(fp->one->path);
                        e = string_list_insert(fp->two->path, git_st_list);
			e->util = d;
                        d->head_to_index_status = fp->status;
                }
	}

	static void git_st_inspect_file_cb(struct diff_queue_struct *q,
        			struct diff_options *opts, void *data)
	{
		struct string_list *git_st_list = data;
		int i;
		for (i = 0; i < q->nr; i++) {
                	struct git_st_data *d;
                        struct string_list_item *e;
			struct diff_filepair *fp = &q->queue[i];
			e = string_list_lookup(fp->one->path, git_st_list);
			if (!e)
                        	die("Oops -- shouldn't happen");
			d = e->util;
                        d->index_to_worktree_status = fp->status;
                }
	}

	void git_st_inspect(struct string_list *git_st_list)
        {
        	struct rev_info rev;

		git_st_list->items = NULL;
                git_st_list->nr = git_st_list->alloc = 0;
                git_st_list->strdup_strings = 1;

		/*
                 * run "diff-index -B -M HEAD" and keep the result in a
                 * string list, keyed by the path in the index.
                 */
                init_revisions(&rev, NULL);
                setup_revisions(0, NULL, &rev, "HEAD");
                rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
                rev.diffopt.format_callback = git_st_inspect_index_cb;
                rev.diffopt.format_callback_data = git_st_list;
                rev.diffopt.detect_rename = 1;
                rev.diffopt.rename_limit = 200;
                rev.diffopt.break_opt = 0;
                run_diff_index(&rev, 1);

		/*
                 * run "diff-files" and update the previous with the result.
		 */
		init_revisions(&rev, NULL);
                setup_revisions(0, NULL, &rev, NULL);
                rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
                rev.diffopt.format_callback = git_st_inspect_file_cb;                
                rev.diffopt.format_callback_data = git_st_list;
                run_diff_files(&rev, 0);

		/*
                 * sort the string-list entries in HEAD path order
                 */
		qsort(git_st_list->items, git_st_list->nr,
                      sizeof(struct string_list_item),
                      cmp_head_path);
	}

Then git_st_inspect() can also be called by wt_status_print(), making it
unnecessary to do the equivalent of the above in wt_status_print_updated()
and wt_status_print_changed().

Re: Fwd: git status options feature suggestion

[Jeff King]

On Sun, Oct 12, 2008 at 01:10:01AM -0700, Junio C Hamano wrote:

> One thing to keep in mind is what to do when you would want to detect
> renames.  The parallel walk would be Ok but between HEAD and index there
> could be renames involved, and at that point it would get quite tricky.
> Once the index is in-core, I think it hurts us much to walk HEAD vs index
> and index vs working tree in separate passes.

Assuming you meant "I _don't_ think it hurts us much" then OK, that
makes sense. I was just thinking it would be more elegant than holding
each list in memory and comparing, but really that is not all that
different than what diffcore does with the output queue.

> I think it is perfectly fine to run the diff-index first, and keep the
> result from it in a string_list, and then run "diff-files" and annotate
> the string_list with the output from it.

Thanks, I think that is a sane direction to go in. And I agree that any
solution should be totally split from the actual output format, so we
can reuse it in "git status" if desired.

However, now that Shawn has revealed the existence of his super-secret
status replacement, I am going to wait to see that before moving any
further. :)

-Peff

Re: Fwd: git status options feature suggestion

[Shawn O. Pearce]

Jeff King <peff@peff.net> wrote:
> However, now that Shawn has revealed the existence of his super-secret
> status replacement, I am going to wait to see that before moving any
> further. :)

I'll talk about it more at the GitTogether.  I expect the sources
to be published and available for download between now and then.
I'll post a pointer to it here on the Git ML once the sources
go live.

So you shouldn't have to wait too much longer.

But as I said, it really is just a trivial redisplay of what
diff-files and diff-index produces.  Anyone could probably code up
the same result in 15 minutes in Perl or Python; or slightly longer
in C.

-- 
Shawn.

Re: Fwd: git status options feature suggestion

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> I remember a long time ago you started on a parallel diff walker that
>> could diff the working tree, the index, and a tree at once. Do you
>> remember the issues with it?
>
> Sorry, I don't.
>
>> I think that would be the right tool here to show each file only once,
>> but with multiple status flags. Something like:
>>
>>   A M foo
>>
>> to show that "foo" has been added since the last commit, but there are
>> modifications in the working tree that have not yet been staged.
>
> One thing to keep in mind is what to do when you would want to detect
> renames.  The parallel walk would be Ok but between HEAD and index there
> could be renames involved, and at that point it would get quite tricky.
> Once the index is in-core, I think it hurts us much to walk HEAD vs index
> and index vs working tree in separate passes.
>
> I think it is perfectly fine to run the diff-index first, and keep the
> result from it in a string_list, and then run "diff-files" and annotate
> the string_list with the output from it.
>
> Something like...

Because I was bored thinking about what to talk about in Gittogether and
lacked enough concentration to do anything productive, I did this that:

 (1) introduces the "find and summarize changes in a single string list"
     infrastructure;

 (2) rewrites wt_status_print_{updated,changed} to use it; and

 (3) adds "git shortstatus" that does not take any parameter (so it is not
     about "preview of commit with the same paths arguments" anymore) to
     give the status in:

        XsssY PATH1 -> PATH2

    format, where X is the diff status between HEAD and the index, sss is the
    rename/copy score of the change (if X is rename or copy --- otherwise
    it is blank), Y is the diff status between the index and the worktree.  
    PATH1 is the path in the HEAD, and " -> PATH2" part is shown only when
    PATH1 corresponds to a different path in the index/worktree.

This was done primarily for fun and killing-time, so I won't be committing
it to my tree, but it seems to pass all the existing tests.

If you apply this patch with "git apply" (no --index) and then

        $ git mv COPYING RENAMING

then you would see:

        $ ./git-shortstatus
        M     Makefile
        R100  COPYING -> RENAMING
            M builtin-commit.c
            M builtin-revert.c
            M builtin.h
            M git.c
            M wt-status.c
            M wt-status.h        

It is very much welcomed if somebody wants to build on top of this.  A few
obvious things, aside from bikeshedding to drop the score value (which I
just did as a sanity check measure and for nothing else --- I won't feel
hurt if we lost that field from the output) and such are:

 * We can also rewrite wt_status_print_untracked() using the collected
   data by making the collector pay attention to untracked files quite
   easily;

 * I did not bouther touching wt_status_print_initial() but I think it
   should be straightforward to produce its output from the collected
   data, as the collector already knows how to handle the initial commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 Makefile         |    1 +
 builtin-commit.c |   45 ++++++++++-
 builtin-revert.c |    1 +
 builtin.h        |    1 +
 git.c            |    1 +
 wt-status.c      |  240 +++++++++++++++++++++++++++++++++++++++++-------------
 wt-status.h      |    9 ++
 7 files changed, 239 insertions(+), 59 deletions(-)

diff --git c/Makefile w/Makefile
index d6f3695..36afaa3 100644
--- c/Makefile
+++ w/Makefile
@@ -316,6 +316,7 @@ BUILT_INS += git-merge-subtree$X
 BUILT_INS += git-peek-remote$X
 BUILT_INS += git-repo-config$X
 BUILT_INS += git-show$X
+BUILT_INS += git-shortstatus$X
 BUILT_INS += git-status$X
 BUILT_INS += git-whatchanged$X
 
diff --git c/builtin-commit.c w/builtin-commit.c
index 93ca496..99c6409 100644
--- c/builtin-commit.c
+++ w/builtin-commit.c
@@ -14,6 +14,7 @@
 #include "diffcore.h"
 #include "commit.h"
 #include "revision.h"
+#include "string-list.h"
 #include "wt-status.h"
 #include "run-command.h"
 #include "refs.h"
@@ -21,7 +22,6 @@
 #include "strbuf.h"
 #include "utf8.h"
 #include "parse-options.h"
-#include "string-list.h"
 #include "rerere.h"
 #include "unpack-trees.h"
 
@@ -856,6 +856,49 @@ static int parse_and_validate_options(int argc, const char *argv[],
 	return argc;
 }
 
+int cmd_shortstatus(int argc, const char **argv, const char *prefix)
+{
+	struct wt_status s;
+	int i;
+
+	read_cache();
+	refresh_cache(REFRESH_QUIET);
+	wt_status_prepare(&s);
+	wt_status_collect_changes(&s);
+	for (i = 0; i < s.change.nr; i++) {
+		struct wt_status_change_data *d;
+		struct string_list_item *it;
+		char pfx[1 + 3 + 1 + 1];
+
+		it = &(s.change.items[i]);
+		d = it->util;
+		switch (d->index_status) {
+		case DIFF_STATUS_COPIED:
+		case DIFF_STATUS_RENAMED:
+			sprintf(pfx, "%c%3d",
+				d->index_status,
+				(int)(d->index_score * 100 / MAX_SCORE));
+			break;
+		case 0:
+			memcpy(pfx, "    ", 4);
+			break;
+		default:
+			sprintf(pfx, "%c   ", d->index_status);
+			break;
+		}
+		if (!d->worktree_status)
+			pfx[4] = ' ';
+		else
+			pfx[4] = d->worktree_status;
+		pfx[5] = '\0';
+		printf("%s ", pfx);
+		if (d->head_path)
+			printf("%s -> ", d->head_path);
+		printf("%s\n", it->string);
+	}
+	return 0;
+}
+
 int cmd_status(int argc, const char **argv, const char *prefix)
 {
 	const char *index_file;
diff --git c/builtin-revert.c w/builtin-revert.c
index 4725540..060453f 100644
--- c/builtin-revert.c
+++ w/builtin-revert.c
@@ -3,6 +3,7 @@
 #include "object.h"
 #include "commit.h"
 #include "tag.h"
+#include "string-list.h"
 #include "wt-status.h"
 #include "run-command.h"
 #include "exec_cmd.h"
diff --git c/builtin.h w/builtin.h
index 1495cf6..f054fc7 100644
--- c/builtin.h
+++ w/builtin.h
@@ -94,6 +94,7 @@ extern int cmd_shortlog(int argc, const char **argv, const char *prefix);
 extern int cmd_show(int argc, const char **argv, const char *prefix);
 extern int cmd_show_branch(int argc, const char **argv, const char *prefix);
 extern int cmd_status(int argc, const char **argv, const char *prefix);
+extern int cmd_shortstatus(int argc, const char **argv, const char *prefix);
 extern int cmd_stripspace(int argc, const char **argv, const char *prefix);
 extern int cmd_symbolic_ref(int argc, const char **argv, const char *prefix);
 extern int cmd_tag(int argc, const char **argv, const char *prefix);
diff --git c/git.c w/git.c
index 89feb0b..55e6cc9 100644
--- c/git.c
+++ w/git.c
@@ -342,6 +342,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "rm", cmd_rm, RUN_SETUP },
 		{ "send-pack", cmd_send_pack, RUN_SETUP },
 		{ "shortlog", cmd_shortlog, USE_PAGER },
+		{ "shortstatus", cmd_shortstatus, RUN_SETUP | NEED_WORK_TREE },
 		{ "show-branch", cmd_show_branch, RUN_SETUP },
 		{ "show", cmd_show, RUN_SETUP | USE_PAGER },
 		{ "status", cmd_status, RUN_SETUP | NEED_WORK_TREE },
diff --git c/wt-status.c w/wt-status.c
index c3a9cab..3d2287b 100644
--- c/wt-status.c
+++ w/wt-status.c
@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "string-list.h"
 #include "wt-status.h"
 #include "color.h"
 #include "object.h"
@@ -56,6 +57,7 @@ void wt_status_prepare(struct wt_status *s)
 	s->reference = "HEAD";
 	s->fp = stdout;
 	s->index_file = get_index_file();
+	s->change.strdup_strings = 1;
 }
 
 static void wt_status_print_cached_header(struct wt_status *s)
@@ -98,18 +100,22 @@ static void wt_status_print_trailer(struct wt_status *s)
 
 #define quote_path quote_path_relative
 
-static void wt_status_print_filepair(struct wt_status *s,
-				     int t, struct diff_filepair *p)
+static void wt_status_print_change_data(struct wt_status *s,
+					int t,
+					int status,
+					char *one_name,
+					char *two_name,
+					int score)
 {
 	const char *c = color(t);
 	const char *one, *two;
 	struct strbuf onebuf = STRBUF_INIT, twobuf = STRBUF_INIT;
 
-	one = quote_path(p->one->path, -1, &onebuf, s->prefix);
-	two = quote_path(p->two->path, -1, &twobuf, s->prefix);
+	one = quote_path(one_name, -1, &onebuf, s->prefix);
+	two = quote_path(two_name, -1, &twobuf, s->prefix);
 
 	color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
-	switch (p->status) {
+	switch (status) {
 	case DIFF_STATUS_ADDED:
 		color_fprintf(s->fp, c, "new file:   %s", one);
 		break;
@@ -135,56 +141,13 @@ static void wt_status_print_filepair(struct wt_status *s,
 		color_fprintf(s->fp, c, "unmerged:   %s", one);
 		break;
 	default:
-		die("bug: unhandled diff status %c", p->status);
+		die("bug: unhandled diff status %c", status);
 	}
 	fprintf(s->fp, "\n");
 	strbuf_release(&onebuf);
 	strbuf_release(&twobuf);
 }
 
-static void wt_status_print_updated_cb(struct diff_queue_struct *q,
-		struct diff_options *options,
-		void *data)
-{
-	struct wt_status *s = data;
-	int shown_header = 0;
-	int i;
-	for (i = 0; i < q->nr; i++) {
-		if (q->queue[i]->status == 'U')
-			continue;
-		if (!shown_header) {
-			wt_status_print_cached_header(s);
-			s->commitable = 1;
-			shown_header = 1;
-		}
-		wt_status_print_filepair(s, WT_STATUS_UPDATED, q->queue[i]);
-	}
-	if (shown_header)
-		wt_status_print_trailer(s);
-}
-
-static void wt_status_print_changed_cb(struct diff_queue_struct *q,
-                        struct diff_options *options,
-                        void *data)
-{
-	struct wt_status *s = data;
-	int i;
-	if (q->nr) {
-		int has_deleted = 0;
-		s->workdir_dirty = 1;
-		for (i = 0; i < q->nr; i++)
-			if (q->queue[i]->status == DIFF_STATUS_DELETED) {
-				has_deleted = 1;
-				break;
-			}
-		wt_status_print_dirty_header(s, has_deleted);
-	}
-	for (i = 0; i < q->nr; i++)
-		wt_status_print_filepair(s, WT_STATUS_CHANGED, q->queue[i]);
-	if (q->nr)
-		wt_status_print_trailer(s);
-}
-
 static void wt_status_print_initial(struct wt_status *s)
 {
 	int i;
@@ -205,13 +168,80 @@ static void wt_status_print_initial(struct wt_status *s)
 	strbuf_release(&buf);
 }
 
-static void wt_status_print_updated(struct wt_status *s)
+static void wt_status_collect_changed_cb(struct diff_queue_struct *q,
+					 struct diff_options *options,
+					 void *data)
+{
+	struct wt_status *s = data;
+	int i;
+
+	if (!q->nr)
+		return;
+	s->workdir_dirty = 1;
+	for (i = 0; i < q->nr; i++) {
+		struct diff_filepair *p;
+		struct string_list_item *it;
+		struct wt_status_change_data *d;
+
+		p = q->queue[i];
+
+		d = xcalloc(1, sizeof(*d));
+		d->worktree_status = p->status;
+		it = string_list_insert(p->one->path, &s->change);
+		it->util = d;
+	}
+}
+
+static void wt_status_collect_updated_cb(struct diff_queue_struct *q,
+					 struct diff_options *options,
+					 void *data)
+{
+	struct wt_status *s = data;
+	int i;
+
+	for (i = 0; i < q->nr; i++) {
+		struct diff_filepair *p;
+		struct string_list_item *it;
+		struct wt_status_change_data *d;
+
+		p = q->queue[i];
+		it = string_list_insert(p->two->path, &s->change);
+		d = it->util;
+		if (!d) {
+			d = xcalloc(1, sizeof(*d));
+			it->util = d;
+		}
+		d->index_status = p->status;
+		switch (p->status) {
+		case DIFF_STATUS_COPIED:
+		case DIFF_STATUS_RENAMED:
+			d->head_path = xstrdup(p->one->path);
+			d->index_score = p->score;
+			break;
+		}
+	}
+}
+
+static void wt_status_collect_changes_worktree(struct wt_status *s)
+{
+	struct rev_info rev;
+
+	init_revisions(&rev, NULL);
+	setup_revisions(0, NULL, &rev, NULL);
+	rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
+	rev.diffopt.format_callback = wt_status_collect_changed_cb;
+	rev.diffopt.format_callback_data = s;
+	run_diff_files(&rev, 0);
+}
+
+static void wt_status_collect_changes_index(struct wt_status *s)
 {
 	struct rev_info rev;
+
 	init_revisions(&rev, NULL);
 	setup_revisions(0, NULL, &rev, s->reference);
 	rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
-	rev.diffopt.format_callback = wt_status_print_updated_cb;
+	rev.diffopt.format_callback = wt_status_collect_updated_cb;
 	rev.diffopt.format_callback_data = s;
 	rev.diffopt.detect_rename = 1;
 	rev.diffopt.rename_limit = 200;
@@ -219,15 +249,107 @@ static void wt_status_print_updated(struct wt_status *s)
 	run_diff_index(&rev, 1);
 }
 
+static void wt_status_collect_changes_initial(struct wt_status *s)
+{
+	int i;
+
+	for (i = 0; i < active_nr; i++) {
+		struct string_list_item *it;
+		struct wt_status_change_data *d;
+
+		it = string_list_insert(active_cache[i]->name, &s->change);
+		d = it->util;
+		if (!d) {
+			d = xcalloc(1, sizeof(*d));
+			it->util = d;
+		}
+		d->index_status = DIFF_STATUS_ADDED;
+	}
+}
+
+void wt_status_collect_changes(struct wt_status *s)
+{
+	wt_status_collect_changes_worktree(s);
+
+	if (s->is_initial)
+		wt_status_collect_changes_initial(s);
+	else
+		wt_status_collect_changes_index(s);
+}
+
+static void wt_status_print_updated(struct wt_status *s)
+{
+	int shown_header = 0;
+	int i;
+
+	for (i = 0; i < s->change.nr; i++) {
+		struct wt_status_change_data *d;
+		struct string_list_item *it;
+		it = &(s->change.items[i]);
+		d = it->util;
+		if (!d->index_status)
+			continue;
+		if (!shown_header) {
+			wt_status_print_cached_header(s);
+			s->commitable = 1;
+			shown_header = 1;
+		}
+		wt_status_print_change_data(s, WT_STATUS_UPDATED,
+					    d->index_status,
+					    d->head_path ? d->head_path : it->string,
+					    it->string,
+					    d->index_score);
+	}
+	if (shown_header)
+		wt_status_print_trailer(s);
+}
+
+/*
+ * -1 : has delete
+ *  0 : no change
+ *  1 : some change but no delete
+ */
+static int wt_status_check_worktree_changes(struct wt_status *s)
+{
+	int i;
+	int changes = 0;
+
+	for (i = 0; i < s->change.nr; i++) {
+		struct wt_status_change_data *d;
+		d = s->change.items[i].util;
+		if (!d->worktree_status)
+			continue;
+		changes = 1;
+		if (d->worktree_status == DIFF_STATUS_DELETED)
+			return -1;
+	}
+	return changes;
+}
+
 static void wt_status_print_changed(struct wt_status *s)
 {
-	struct rev_info rev;
-	init_revisions(&rev, "");
-	setup_revisions(0, NULL, &rev, NULL);
-	rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
-	rev.diffopt.format_callback = wt_status_print_changed_cb;
-	rev.diffopt.format_callback_data = s;
-	run_diff_files(&rev, 0);
+	int i;
+	int worktree_changes = wt_status_check_worktree_changes(s);
+
+	if (!worktree_changes)
+		return;
+
+	wt_status_print_dirty_header(s, worktree_changes < 0);
+	
+	for (i = 0; i < s->change.nr; i++) {
+		struct wt_status_change_data *d;
+		struct string_list_item *it;
+		it = &(s->change.items[i]);
+		d = it->util;
+		if (!d->worktree_status)
+			continue;
+		wt_status_print_change_data(s, WT_STATUS_CHANGED,
+					    d->worktree_status,
+					    it->string,
+					    it->string,
+					    0);
+	}
+	wt_status_print_trailer(s);
 }
 
 static void wt_status_print_submodule_summary(struct wt_status *s)
@@ -347,6 +469,8 @@ void wt_status_print(struct wt_status *s)
 			wt_status_print_tracking(s);
 	}
 
+	wt_status_collect_changes(s);
+
 	if (s->is_initial) {
 		color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
 		color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "# Initial commit");
diff --git c/wt-status.h w/wt-status.h
index 78add09..00508c3 100644
--- c/wt-status.h
+++ w/wt-status.h
@@ -18,6 +18,13 @@ enum untracked_status_type {
 };
 extern enum untracked_status_type show_untracked_files;
 
+struct wt_status_change_data {
+	int worktree_status;
+	int index_status;
+	int index_score;
+	char *head_path;
+};
+
 struct wt_status {
 	int is_initial;
 	char *branch;
@@ -33,6 +40,7 @@ struct wt_status {
 	const char *index_file;
 	FILE *fp;
 	const char *prefix;
+	struct string_list change;
 };
 
 int git_status_config(const char *var, const char *value, void *cb);
@@ -40,5 +48,6 @@ extern int wt_status_use_color;
 extern int wt_status_relative_paths;
 void wt_status_prepare(struct wt_status *s);
 void wt_status_print(struct wt_status *s);
+void wt_status_collect_changes(struct wt_status *s);
 
 #endif /* STATUS_H */

Re: Fwd: git status options feature suggestion

[Jeff King]

On Sat, Oct 25, 2008 at 06:47:27PM -0700, Junio C Hamano wrote:

> This was done primarily for fun and killing-time, so I won't be committing
> it to my tree, but it seems to pass all the existing tests.

I just skimmed the code, but it looks reasonably done. I don't have time
to work on this at the moment, but I think you have done most of the
work that requires a lot of git knowledge. Maybe somebody new can pick
this up as a nice starter project to get more involved in git.

-Peff

Re: Fwd: git status options feature suggestion

[Shawn O. Pearce]

Jeff King <peff@peff.net> wrote:
> On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:
> 
> > And just make it mimic whatever folks accustomed to "svn st" would expect,
> > modulo we would need two status letters to signal difference between
> > (HEAD, index), and (index, worktree).  Perhaps three if you want to show
> > difference between (HEAD, worktree) while at it.
> 
> I remember a long time ago you started on a parallel diff walker that
> could diff the working tree, the index, and a tree at once. Do you
> remember the issues with it?
> 
> I think that would be the right tool here to show each file only once,
> but with multiple status flags. Something like:
> 
>   A M foo

I have a tool that I'll be open-sourcing later this year, but it does
something like that:

  project foo/                        branch master
   Am   foo
   M-   bar
   R-   orig => dest ( 95%)

Line coloring is red on lines with unstaged stuff in the working
directory (3rd column, lower case letters) and green on lines that
are fully staged (3rd column is a '-').

The tool is in Python, but I'm just scraping the output of
`diff-index -M --cached HEAD` and diff-files to get that
display.  The status letters are exactly those given out by
diff-index/diff-files, but the diff-files output is lowercased.

Scott Chacon has seen the tool output and likes it; there's a tech
talk that will be posted on YouTube soon where he and I are sort
of talking about it.

Sorry I can't say too much more about it yet.  But I'm trying to
say that both Scott and I like a denser display like this.

-- 
Shawn.

Re: Fwd: git status options feature suggestion

[Jeff King]

On Sun, Oct 12, 2008 at 11:05:04AM -0700, Shawn O. Pearce wrote:

> I have a tool that I'll be open-sourcing later this year, but it does
> [...]
> Sorry I can't say too much more about it yet.  But I'm trying to
> say that both Scott and I like a denser display like this.

I like what I saw, and I think a "denser" format is what I was trying to
suggest in my earlier message (I just didn't think of nearly as clear a
word). So count me in for your list of people who would like to see this
thing (and would even work on doing a pure-C version).

-Peff

Re: Fwd: git status options feature suggestion

[Jakub Narebski]

Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
>> So I think it is probably reasonable to think about a new command (which
>> would not be called status) that shows this information.
> 
> I was going to suggest the same.  "git st" for people who come from "svn st"
> so that "git status" can be kept as traditional "preview of 'git commit'".

Or "git inspect". Or "git info".

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git status options feature suggestion

[Wincent Colaiuta]

El 12/10/2008, a las 8:41, Junio C Hamano escribió:

> Jeff King <peff@peff.net> writes:
>
>> So I think it is probably reasonable to think about a new command  
>> (which
>> would not be called status) that shows this information.
>
> I was going to suggest the same.  "git st" for people who come from  
> "svn st"
> so that "git status" can be kept as traditional "preview of 'git  
> commit'".
>
> And just make it mimic whatever folks accustomed to "svn st" would  
> expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree).  Perhaps three if you want to  
> show
> difference between (HEAD, worktree) while at it.

One of the first aliases I set up when I started using git was "st"  
for status, and I'd imagine that's a pretty common thing for people  
coming from other SCMs like svn and cvs. But I very quickly became  
used to git's notion of what "status" means and I wouldn't want "git  
st" to start giving me a different behaviour.

I think if you're introducing a different command then you should make  
sure it doesn't happen to be an abbreviation of an existing one. It  
would be better to give it some other name (info, foo, whatever). If  
svn people then want to make an "st" alias pointing to it they're free  
to do so.

Just my 2c.

Cheers,
Wincent

Re: git status options feature suggestion

[Teemu Likonen]

Wincent Colaiuta <win@wincent.com> writes:

> I think if you're introducing a different command then you should make
> sure it doesn't happen to be an abbreviation of an existing one. It
> would be better to give it some other name (info, foo, whatever). If
> svn people then want to make an "st" alias pointing to it they're free
> to do so.

In Subversion and Bazaar "info" command gives mostly information about
the repository itself. They don't talk about individual files at all.
"status" is the command (also in Mercurial) for getting information
about the current state of files in the tree.

I think it would be really sad if "git status" can't be extended to
match people's needs. I don't like the idea of a new name for such
status command. It's a kind of "why git people always invent new names
for familiar commands?" thing.

Re: git status options feature suggestion

[Andreas Ericsson]

Teemu Likonen wrote:
> Wincent Colaiuta <win@wincent.com> writes:
> 
>> I think if you're introducing a different command then you should make
>> sure it doesn't happen to be an abbreviation of an existing one. It
>> would be better to give it some other name (info, foo, whatever). If
>> svn people then want to make an "st" alias pointing to it they're free
>> to do so.
> 
> In Subversion and Bazaar "info" command gives mostly information about
> the repository itself. They don't talk about individual files at all.
> "status" is the command (also in Mercurial) for getting information
> about the current state of files in the tree.
> 
> I think it would be really sad if "git status" can't be extended to
> match people's needs. I don't like the idea of a new name for such
> status command. It's a kind of "why git people always invent new names
> for familiar commands?" thing.

Well, the solution is fairly simple then. Just make it configurable and
set it in your ~/.gitconfig. It's not my itch to scratch though. I
loathe the sparse output from cvs/svn/whatnot and would be just as happy
if I never had to look at it again. I can understand its usefulness for
scripting, but 'git status' is porcelain so for that purpose it really
belongs somewhere else.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Fwd: git status options feature suggestion

[Jeff King]

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.  */

Re: Fwd: git status options feature suggestion

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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);

You would probably want to refresh_cache() here even if you are not going
to write the resulting index out, so that you won't show the stat-only
differences to the end user.  Other than that, I think this is a good
change.

Re: Fwd: git status options feature suggestion

[Jeff King]

On Sun, Oct 12, 2008 at 02:58:20AM -0700, Junio C Hamano wrote:

> > +		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);
> 
> You would probably want to refresh_cache() here even if you are not going
> to write the resulting index out, so that you won't show the stat-only
> differences to the end user.  Other than that, I think this is a good
> change.

That is a good point. However, I think this change is still not a good
one, because it is only halfway there. It makes "git status" work, but
not "git status path", which wants to write out the resulting cache. I
don't know what complications are involved with making that work.
Probably there is a way, but I haven't looked too closely, as I think a
better path forward is a new tool that is not so closely tied to commit.

-Peff

ls-files [Was: Re: Fwd: git status options feature suggestion]

[James Cloos]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > How about "git ls-files -o"?
>> 
>> doh... hadn't even heard of that command.

Johannes> Which is good!  As ls-files is listed as plumbing.
Johannes> Users should not need to call ls-files,

That is a bug, then.  ls-files is one of the more important user-level
commands in git.

It is vastly more efficient than find(1) or a --recursive call to
grep(1).

Searching through a repository to find which file(s) define or use some
function, struct, class or similar is a common occurance.  Or to find
which dir(s) contain(s) file(s) matching a given regexp.  Or a number
of other uses.  (Tags might be useful if one does a lot of searching
in a given repo, but grep is quicker for infrequent searches and the
tags utils do not support all file types.)

ls-files is definitely dual-use.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: ls-files [Was: Re: Fwd: git status options feature suggestion]

[Shawn O. Pearce]

James Cloos <cloos@jhcloos.com> wrote:
> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> > How about "git ls-files -o"?
> >> 
> >> doh... hadn't even heard of that command.
> 
> Johannes> Which is good!  As ls-files is listed as plumbing.
> Johannes> Users should not need to call ls-files,
> 
> That is a bug, then.  ls-files is one of the more important user-level
> commands in git.
> 
> It is vastly more efficient than find(1) or a --recursive call to
> grep(1).

How about using "git grep" then?  No need for ls-files...

-- 
Shawn.

Re: ls-files [Was: Re: Fwd: git status options feature suggestion]

[Jeremy Ramer]

On Thu, Oct 9, 2008 at 3:41 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> James Cloos <cloos@jhcloos.com> wrote:
>> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> >> > How about "git ls-files -o"?
>> >>
>> >> doh... hadn't even heard of that command.
>>
>> Johannes> Which is good!  As ls-files is listed as plumbing.
>> Johannes> Users should not need to call ls-files,
>>
>> That is a bug, then.  ls-files is one of the more important user-level
>> commands in git.
>>
>> It is vastly more efficient than find(1) or a --recursive call to
>> grep(1).
>
> How about using "git grep" then?  No need for ls-files...

I use git-grep for searching the contents of files in the repo, but it
seems to me that git ls-files is necessary for quickly parsing the
file names themselves.

>
> --
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ls-files

[James Cloos]

>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:

>> [ls-files] is vastly more efficient than find(1) or a --recursive
>> call to grep(1).

Shawn> How about using "git grep" then?  No need for ls-files...

I often filter the list of files before passing them to xargs, so git
grep helps for some use cases, but not all.

Also, (at least as of 1.6.0.2.307.gc427), git grep does not support -P
(Perl compatible regexps) or --color.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6