unmerged files listed in the beginning of git-status

unmerged files listed in the beginning of git-status

[bill lam]

I noticed in the new git 1.6.4.2 . git-status show unmerged files
with a clause of explanation.  This is very helpful. However these
unmerged files are listed in the beginning and followed by modified
files,  I imagined the normal case will be there is only a few
unmerged files but a much large number of other files.  Thus it needs
to shift pageup or redirect to less in order view these unmerges
files.  Previously these unmerge files are listed after modified files
and easily seen or copy-and-paste using mouse.  Is there any specific
reason to change the order of sequence?

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Re: unmerged files listed in the beginning of git-status

[Junio C Hamano]

bill lam <cbill.lam@gmail.com> writes:

> I noticed in the new git 1.6.4.2 .

I hope you didn't.  This is only in 'master' and will appear first in the
upcoming 1.6.5; it is never meant for 1.6.4.X maintenance series and
1.6.4.2 does not have this change.

> git-status show unmerged files
> with a clause of explanation.  This is very helpful. However these
> unmerged files are listed in the beginning and followed by modified
> files,

"git status" is preview of what git commit does.  The "Changes to be
committed" section is given at the beginning of the output because it is
the most important one.  But while reviewing the conflicts, you would want
to notice conflicted paths more than what are already resolved and staged.

It used to be that unmerged paths were mixed together with locally
modified paths in the "Changed but not updated" list, after the "Changes
to be committed" list.  This made the unmerged paths harder to spot than
necessary.

To remedy this, unmerged ones are now:

 (1) placed in a new, separate section that appears only when there are
     unmerged paths, to make the fact that there is something unusual
     going on (i.e. conflicts) stand out; and

 (2) the new section is given at the top of the status output to give
     these unmerged paths more prominence.

Having said all that, the relative importance of the pieces of information
given in "git status" output is fairly subjective.

If you are a confident, know-what-I-am-doing type, you would see the
"Changes to be committed" list the most important, because that is where
you make sure you have added all the changes you want to include in the
commit.  If you are a forgetful type, on the other hand, you would see
"Changed but not updated" and "Untracked files" more important, because
that is where you make sure there isn't any files you modified and new
files you created that you want to include in the commit but may have
forgotten.  If you are into flipping many branches and often commit your
changes on a wrong branch, you may value the "On branch foo" information
at the top the most.  So in that sense, there cannot be a single right
order of these sections.

But unmerged entries are something you need to deal with _first_ before
being able to go further, so in that sense it is more important than
anything else in the traditional output.

In the output, "the most important part first" rule is unlikely to change,
if only because this is what you are shown when committing in the editor,
and even in 1.7.0 when "git status" stops being "git commit --dry-run"
because we would still keep consistency of the two outputs,

By the way, please do not deflect responses to your message away from
yourself using Mail-Followup-To.

Re: unmerged files listed in the beginning of git-status

[Johannes Sixt]

On Dienstag, 1. September 2009, Junio C Hamano wrote:
> bill lam <cbill.lam@gmail.com> writes:
> > git-status show unmerged files
> > with a clause of explanation.  This is very helpful. However these
> > unmerged files are listed in the beginning and followed by modified
> > files,
>
> "git status" is preview of what git commit does.  The "Changes to be
> committed" section is given at the beginning of the output because it is
> the most important one.  But while reviewing the conflicts, you would want
> to notice conflicted paths more than what are already resolved and staged.
>
> It used to be that unmerged paths were mixed together with locally
> modified paths in the "Changed but not updated" list, after the "Changes
> to be committed" list.  This made the unmerged paths harder to spot than
> necessary.
>
> To remedy this, unmerged ones are now:
>
>  (1) placed in a new, separate section that appears only when there are
>      unmerged paths, to make the fact that there is something unusual
>      going on (i.e. conflicts) stand out; and
>
>  (2) the new section is given at the top of the status output to give
>      these unmerged paths more prominence.

But this is very inconvenient if you merge a branch that touched many files, 
of which only a few have conflicts. In this case, the unmerged entries are 
scrolled out of view. If you want to copy-paste them into a 'git add' command 
then (at least my) xterm (and Windows's CMD, BTW) keeps scrolling down to the 
command line, and since I cannot bulk-select all of them at once, I have to 
scroll up in order select any individual of them.

Note that I do not complain about the "out of view" part (because if a list is 
long there is inevitably something that becomes invisible), but about 
the "must scroll around" part.

> But unmerged entries are something you need to deal with _first_ before
> being able to go further, so in that sense it is more important than
> anything else in the traditional output.

This is actually an argument to place the unmerged entries *last* because this 
is what will be visible after 'git status' finished. Remember that we don't 
pass its output through the pager.

> In the output, "the most important part first" rule is unlikely to change,
> if only because this is what you are shown when committing in the editor,
> and even in 1.7.0 when "git status" stops being "git commit --dry-run"
> because we would still keep consistency of the two outputs,

Of course, this argument is irrelevant for the placement of the list of 
unmerged entries because by the time you enter the commit message editor, 
this list is empty.

-- Hannes

[PATCH] status: list unmerged files after staged files

[Johannes Sixt]

The list of unmerged files is considered rather important because after
a conflicted merge they need attention. Since the output of git status does
not go through the pager, the end of the output remains immediately visible
in the terminal window. By placing unmerge entries after staged entries,
the user can see them immediately.

Moreover, keeping the unmerge entries at the top is inconvenient if a merge
touched many files, but only a few conflicted: After the conflicts were
resolved, the user will conduct a 'git add' command. In order to do that
with copy-and-paste, the user must scroll the terminal window up, and must
do so for each individual entry (because terminal windows commonly scroll
down automatically on the paste operation to make the cursor visible).

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
 wt-status.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 3395456..85f3fcb 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)
 		color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
 	}
 
-	wt_status_print_unmerged(s);
 	wt_status_print_updated(s);
+	wt_status_print_unmerged(s);
 	wt_status_print_changed(s);
 	if (s->submodule_summary)
 		wt_status_print_submodule_summary(s);
-- 
1.6.4.2.280.gb16ab

Re: [PATCH] status: list unmerged files after staged files

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Moreover, keeping the unmerge entries at the top is inconvenient if a merge
> touched many files, but only a few conflicted: After the conflicts were
> resolved, the user will conduct a 'git add' command. In order to do that
> with copy-and-paste, the user must scroll the terminal window up, and must
> do so for each individual entry (because terminal windows commonly scroll
> down automatically on the paste operation to make the cursor visible).

I actually was expecting that you would move this at the very bottom after
untracked list for the above reason, and also because this part is only
shown while running status (that was a good point you made in the previous
message) and never in commit.

>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  wt-status.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 3395456..85f3fcb 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)
>  		color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
>  	}
>  
> -	wt_status_print_unmerged(s);
>  	wt_status_print_updated(s);
> +	wt_status_print_unmerged(s);
>  	wt_status_print_changed(s);
>  	if (s->submodule_summary)
>  		wt_status_print_submodule_summary(s);
> -- 
> 1.6.4.2.280.gb16ab

[PATCH v2] status: list unmerged files last

[Johannes Sixt]

The list of unmerged files is considered rather important because after
a conflicted merge they need attention. Since the output of git status does
not go through the pager, the end of the output remains immediately visible
in the terminal window. By placing unmerge entries at the end of the list,
the user can see them immediately.

Moreover, keeping the unmerge entries at the top is inconvenient if a merge
touched many files, but only a few conflicted: After the conflicts were
resolved, the user will conduct a 'git add' command. In order to do that
with copy-and-paste, the user must scroll the terminal window up, and must
do so for each individual entry (because terminal windows commonly scroll
down automatically on the paste operation to make the cursor visible).

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
On Dienstag, 1. September 2009, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > Moreover, keeping the unmerge entries at the top is inconvenient if a
> > merge touched many files, but only a few conflicted: After the conflicts
> > were resolved, the user will conduct a 'git add' command. In order to do
> > that with copy-and-paste, the user must scroll the terminal window up,
> > and must do so for each individual entry (because terminal windows
> > commonly scroll down automatically on the paste operation to make the
> > cursor visible).
>
> I actually was expecting that you would move this at the very bottom after
> untracked list for the above reason, and also because this part is only
> shown while running status (that was a good point you made in the previous
> message) and never in commit.

So you would not mind a more "drastic" change?

This version 2 can be regarded as a real improvement with the argument
above, whereas version 1 would only correct something of some
sort of regression, compared to v1.6.4.

(Originally I didn't dare to change too much and thought keeping staged
files together would make sense.)

-- Hannes

 wt-status.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 3395456..60d8425 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -561,7 +561,6 @@ void wt_status_print(struct wt_status *s)
 		color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
 	}
 
-	wt_status_print_unmerged(s);
 	wt_status_print_updated(s);
 	wt_status_print_changed(s);
 	if (s->submodule_summary)
@@ -570,6 +569,7 @@ void wt_status_print(struct wt_status *s)
 		wt_status_print_untracked(s);
 	else if (s->commitable)
 		 fprintf(s->fp, "# Untracked files not listed (use -u option to show untracked 
files)\n");
+	wt_status_print_unmerged(s);
 
 	if (s->verbose)
 		wt_status_print_verbose(s);
-- 
1.6.4.2.280.gb16ab

Re: [PATCH v2] status: list unmerged files last

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> The list of unmerged files is considered rather important because after
> a conflicted merge they need attention. Since the output of git status does
> not go through the pager, the end of the output remains immediately visible
> in the terminal window. By placing unmerge entries at the end of the list,
> the user can see them immediately.
>
> Moreover, keeping the unmerge entries at the top is inconvenient if a merge
> touched many files, but only a few conflicted: After the conflicts were
> resolved, the user will conduct a 'git add' command. In order to do that
> with copy-and-paste, the user must scroll the terminal window up, and must
> do so for each individual entry (because terminal windows commonly scroll
> down automatically on the paste operation to make the cursor visible).
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>

> On Dienstag, 1. September 2009, Junio C Hamano wrote:
>
>> I actually was expecting that you would move this at the very bottom after
>> untracked list for the above reason, and also because this part is only
>> shown while running status (that was a good point you made in the previous
>> message) and never in commit.
>
> So you would not mind a more "drastic" change?

Well, it's not really about what _I_ like or mind.  It is primarily about
what the list collectively thinks.  I'd like to let other eyeballs and
brains to weigh in, as I am known to pick the worst layout from the UI
point of view as you saw in this thread already ;-).

> (Originally I didn't dare to change too much and thought keeping staged
> files together would make sense.)

Yes, unmerged ones are modified and the index knows about them, but you
haven't told git what you want to commit yet, so they are in the same
category as "changed but not updated" in that sense, but unlike "changed
but not updated", you cannot leave them as they are before proceeding, so
they are worse.

The "keeping related things together" argument does mean your v1 is better
than this patch, as you had "unmerged" next to "changed but not updated".
I personally think the "keep related things together" argument makes much
more sense than the "close to the bottom is easier to cut and paste"
argument, as I tend to focus at the top of the output when looking at the
status output and almost never cut & paste using mouse (screen for
rectangular cutting and pasting works wonderfully), but it probably is
just me.  And remember that I am only just one of the users, nothing more.

Sadly, "keep related things together" and "as close to the bottom as
possible" are not quite compatible, and we can pick one or the other, but
not both.

If I were to pick the middle ground, I would probably move it immediately
after the call to wt_status_print_changed(), with "keeping related things
together" as the primary justification.  It would be an incidental benefit
that it moves the part slightly closer to the bottom and gives it a better
chance of staying on the screen.

But I am not a great UI designer ;-)

Re: [PATCH v2] status: list unmerged files last

[bill lam]

On Tue, 01 Sep 2009, Junio C Hamano wrote:
> Sadly, "keep related things together" and "as close to the bottom as
> possible" are not quite compatible, and we can pick one or the other, but
> not both.
> 
> If I were to pick the middle ground, I would probably move it immediately
> after the call to wt_status_print_changed(), with "keeping related things
> together" as the primary justification.  It would be an incidental benefit
> that it moves the part slightly closer to the bottom and gives it a better
> chance of staying on the screen.

I can only speak of my personal experience that during rebase -i,
there is no (or very few) untracked files in the list so that the
sequence  "modified, unmerged, untracked" is also a good alternative.

(I hope the mail-followup-to is correct this time)

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Tue, Sep 01, 2009 at 05:18:40PM -0700, Junio C Hamano wrote:

> The "keeping related things together" argument does mean your v1 is better
> than this patch, as you had "unmerged" next to "changed but not updated".
> I personally think the "keep related things together" argument makes much
> more sense than the "close to the bottom is easier to cut and paste"
> argument, as I tend to focus at the top of the output when looking at the
> status output and almost never cut & paste using mouse (screen for
> rectangular cutting and pasting works wonderfully), but it probably is
> just me.  And remember that I am only just one of the users, nothing more.
> 
> Sadly, "keep related things together" and "as close to the bottom as
> possible" are not quite compatible, and we can pick one or the other, but
> not both.

Just my two cents (and I think I have as good a track record at UI
design as Junio... ;) ):

I think "related things together" trumps "close to the bottom". Because
the former is something that _always_ applies to your output, while the
latter is catering to a particular use case and a particular screen
setup.

In other words, why is the _bottom_ reserved for more important things
instead of the _top_? If I have a tall terminal that is long enough to
see the output, are you potentially making the important thing less
obvious (because I tend to read the the output from top to bottom)? If I
use a pager (either manually, because I have seen that the output is too
long, or automatically via the pager.status config variable)? What about
reading status output into an interface wrapper like "tig status"?

So while you may be helping some users, I tend to think you may be
hurting others.

-Peff

PS I am also not entirely convinced that unmerged entries are somehow
more important to call attention to in the list than other entries. But
the above argues that even _if_ you think they are more important, it is
still not necessarily a good thing to move them to the bottom.

Re: [PATCH v2] status: list unmerged files last

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I think "related things together" trumps "close to the bottom". Because
> the former is something that _always_ applies to your output, while the
> latter is catering to a particular use case and a particular screen
> setup.
>
> In other words, why is the _bottom_ reserved for more important things
> instead of the _top_? If I have a tall terminal that is long enough to
> see the output, are you potentially making the important thing less
> obvious (because I tend to read the the output from top to bottom)? If I
> use a pager (either manually, because I have seen that the output is too
> long, or automatically via the pager.status config variable)? What about
> reading status output into an interface wrapper like "tig status"?

Yes and no.

Sure, I always work in a 92x70 screen session with 10k lines of scrollback
buffer, and when I cut and paste I do not use a mouse but use screen's cut
buffer, so I would have no problem with the list at the top.

Not that I would use "git status" while resolving merges---I would use
"ls-files -u" myself, and I may perhaps start using "status -suno", so my
personal preference does not really count on this topic.

But not everybody is used to such a set-up.  If you rely on terminal's
scrollback buffer with mouse and a short terminal, I can see cutting and
pasting would be an issue.  I do not have a good answer to "tig status",
but the design principle of supporting the lowest denominator is
important.

J6t made a good point that this new section won't appear when committing,
which I didn't take account when I was first explained how the ordering
was chosen.  After thinking about this a bit more, I think "untracked" and
"modified but not updated" sections, unlike when recording your own
commit, is mostly uninteresting while resolving a merge.  You never add
files that you forgot to add to a merge; nor you would add your local
modifications to a merge.  So the only sections that are interesting are
this new "unmerged" section and "updated" section to see the extent of
damage the merge causes to your history by introducing the crap other
people dumped on you ;-) [*1*].

The above suggests me that (1) we would want to have the new "unmerged"
section next to "updated" section, (2) we would want to have it later in
the output rather than earlier, and (3) in the traditional output, people
are used to see unmerged paths in "changed" section, so it would be easier
for them to transition if "unmerged" section were near "changed" section.

That makes the ideal place between updated and changed, no?

Incidentally that is where J6t's first patch was.  So I would agree with
the patch (but not necessarily with its justification).

[1] It might even make sense to omit other sections and show only
"updated" and "unmerged" in this order when the index is unmerged, but
that is a lot more drastic change for 1.7.0.

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:

> But not everybody is used to such a set-up.  If you rely on terminal's
> scrollback buffer with mouse and a short terminal, I can see cutting and
> pasting would be an issue.  I do not have a good answer to "tig status",
> but the design principle of supporting the lowest denominator is
> important.

But I'm not sure it is about "lowest common denominator". I think it is
about different people having different preferences (as a matter of
fact, I use an 80x25 terminal most of the time, and I think I prefer the
content at the top. Perhaps it is simply habit, but I do think having it
right next to "staged for commit" items makes the most sense).

> The above suggests me that (1) we would want to have the new "unmerged"
> section next to "updated" section, (2) we would want to have it later in
> the output rather than earlier, and (3) in the traditional output, people
> are used to see unmerged paths in "changed" section, so it would be easier
> for them to transition if "unmerged" section were near "changed" section.
> 
> That makes the ideal place between updated and changed, no?

Yes, I think that is fine, and makes more sense than where we have it
now. I mainly wanted to argue against sticking it at the very bottom.

> [1] It might even make sense to omit other sections and show only
> "updated" and "unmerged" in this order when the index is unmerged, but
> that is a lot more drastic change for 1.7.0.

I think that is a really bad idea. The mental model of "git status"
(versus individual diff or ls-files commands) is to see _everything_
going on in the repo. Showing a subset breaks that model and gives a
false sense of what is actually happening.

I don't know that it would matter much most of the time anyway. If you
have unmerged entries, you probably don't have any (or many) "changed
but not updated" files, too (since you are not working on a new commit
but rather a merge, they would have to be dirty state you are carrying
permanently, but not related to the merge). If you do, you probably want
to see them to be aware of what is going on.

You probably also don't have a lot of untracked files. If you have a
few, you might want to be reminded of them to make sure they were not
something you were preparing to help with a tricky merge. And if you are
the sort of person who carries around a lot of untracked files, and for
some reason you refuse to put them in your .gitignore, then you probably
have status.untracked set to "no" already (or you should consider
setting it), as they will be bugging you in other situations, as well.

-Peff

Re: [PATCH v2] status: list unmerged files last

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:
>
>> But not everybody is used to such a set-up.  If you rely on terminal's
>> scrollback buffer with mouse and a short terminal, I can see cutting and
>> pasting would be an issue.  I do not have a good answer to "tig status",
>> but the design principle of supporting the lowest denominator is
>> important.
>
> But I'm not sure it is about "lowest common denominator". I think it is
> about different people having different preferences (as a matter of
> fact, I use an 80x25 terminal most of the time, and I think I prefer the
> content at the top. Perhaps it is simply habit, but I do think having it
> right next to "staged for commit" items makes the most sense).
> ...

Here is how I would justify the change (the patch is the same as Hannes's
first version.

From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 1 Sep 2009 22:13:53 +0200
Subject: [PATCH] status: list unmerged files much later

When resolving a conflicted merge, two lists in the status output need
more attention from the user than other parts.

 - the list of updated paths is useful to review the amount of changes the
   merge brings in (the user cannot do much about them other than
   reviewing, though); and

 - the list of unmerged paths needs the most attention from the user; the
   user needs to resolve them in order to proceed.

Since the output of git status does not by default go through the pager,
the early parts of the output can scroll away at the top. It is better to
put the more important information near the bottom.  During a merge, local
changes that are not in the index are minimum, and you should keep the
untracked list small in any case, so moving the unmerged list from the top
of the output to immediately after the list of updated paths would give us
the optimum layout..

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 wt-status.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Tue, Sep 01, 2009 at 10:26:26PM -0700, Junio C Hamano wrote:

> Here is how I would justify the change (the patch is the same as Hannes's
> first version.

Makes sense to me.

Acked-by: Jeff King <peff@peff.net>

> the optimum layout..

Double period. :)

-Peff

Re: [PATCH v2] status: list unmerged files last

[David Aguilar]

On Tue, Sep 01, 2009 at 10:26:26PM -0700, Junio C Hamano wrote:
> 
> Here is how I would justify the change (the patch is the same as Hannes's
> first version.
> 
> From: Johannes Sixt <j6t@kdbg.org>
> Date: Tue, 1 Sep 2009 22:13:53 +0200
> Subject: [PATCH] status: list unmerged files much later
> 
> When resolving a conflicted merge, two lists in the status output need
> more attention from the user than other parts.
> 
>  - the list of updated paths is useful to review the amount of changes the
>    merge brings in (the user cannot do much about them other than
>    reviewing, though); and
> 
>  - the list of unmerged paths needs the most attention from the user; the
>    user needs to resolve them in order to proceed.
> 
> Since the output of git status does not by default go through the pager,
> the early parts of the output can scroll away at the top. It is better to
> put the more important information near the bottom.  During a merge, local
> changes that are not in the index are minimum, and you should keep the
> untracked list small in any case, so moving the unmerged list from the top
> of the output to immediately after the list of updated paths would give us
> the optimum layout..

I agree with all of this but would also add that we can have
our cake and eat it too with respect to wanting to "keep
similar things together" and having "unmerged near bottom".

No one has suggested this, so I figured I would.
What do you think about this layout?

- untracked
- staged
- modified
- unmerged

This isn't the first thing someone would think of, but here's
why it is intuitive:

- untracked entries come first because in the git world they
  are weird.  We don't like to see these things and we tend to
  .gitignore them away.

- staged entries come next, though we know that in practice
  staged is often shown first since we tend to not care about
  untracked files.  This often contains entries when merging
  but we do not often do much with these besides review them.

- modified entries come next because they need our attention.
  When merging this list is often small or non-existant,
  thus unmerged often follows immediately after staged.

- unmerged comes last for all of the reasons listed above.
  We give these special treatment because they often
  require even more attention than modified files.

What do you guys think?


While I've got you guys.. I have a patch for the new 1.7
status that makes it:

	git status [<tree-ish>] [--] [pathspec]
	(it adds support for tree-ish)


I added that because I thought that the porcelain-ish short
status output could be useful for "what does commit --amend
do" from a script-writers' pov, and thus adding <tree-ish>
enables git status -s HEAD^.

Is this a good idea?  I'll send the patch if others are
interested.  It seemed useful to me; my rationale was that
right now git-status is hardcoded to HEAD and thus exposing
that variable seemed useful.

BTW is status -s intended to be something plumbing-like;
something we can build upon and expect to be stable?
I'm just curious because other commands have a --porcelain
option and I wasn't sure if this was the intent.


Thanks,

-- 

	David

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:

> I agree with all of this but would also add that we can have
> our cake and eat it too with respect to wanting to "keep
> similar things together" and having "unmerged near bottom".

Well, my point was that the "bottom" is not really cake, but I am not
sure anyone else agrees.

> No one has suggested this, so I figured I would.
> What do you think about this layout?
> 
> - untracked
> - staged
> - modified
> - unmerged

What about the current branch? Alternate author info? Tracking branch
relationship? Should those be at the top or bottom?

I dunno. Maybe it is just me being crotchety and hating change, but I
like the current order (though swapping it below "updated" is fine with
me).

> While I've got you guys.. I have a patch for the new 1.7
> status that makes it:
> 
> 	git status [<tree-ish>] [--] [pathspec]
> 	(it adds support for tree-ish)
> 
> I added that because I thought that the porcelain-ish short
> status output could be useful for "what does commit --amend
> do" from a script-writers' pov, and thus adding <tree-ish>
> enables git status -s HEAD^.

If you want to know "what does commit --amend do", then shouldn't you be
using "git commit --amend --dry-run" (which is what "git status" is now,
but will not be in v1.7.0)?

Are there other uses cases for arbitrary tree-ish's?

> BTW is status -s intended to be something plumbing-like;
> something we can build upon and expect to be stable?
> I'm just curious because other commands have a --porcelain
> option and I wasn't sure if this was the intent.

We mentioned a --porcelain option in other discussion, but I don't think
there is a patch. I would be in favor of --porcelain, even if it is
currently identical to --short, because then it gives us freedom to
diverge later (and in particular it gives us the freedom to let user
configuration affect what is shown).

-Peff

Re: [PATCH v2] status: list unmerged files last

[David Aguilar]

On Wed, Sep 02, 2009 at 01:59:08PM -0400, Jeff King wrote:
> On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:
> 
> > I agree with all of this but would also add that we can have
> > our cake and eat it too with respect to wanting to "keep
> > similar things together" and having "unmerged near bottom".
> 
> Well, my point was that the "bottom" is not really cake, but I am not
> sure anyone else agrees.
> 
> > No one has suggested this, so I figured I would.
> > What do you think about this layout?
> > 
> > - untracked
> > - staged
> > - modified
> > - unmerged
> 
> What about the current branch? Alternate author info? Tracking branch
> relationship? Should those be at the top or bottom?
> 
> I dunno. Maybe it is just me being crotchety and hating change, but I
> like the current order (though swapping it below "updated" is fine with
> me).


Nah, you're right.
Being crotchety and hating change is a good thing here.



> If you want to know "what does commit --amend do", then shouldn't you be
> using "git commit --amend --dry-run" (which is what "git status" is now,
> but will not be in v1.7.0)?
> 
> Are there other uses cases for arbitrary tree-ish's?
> 
> > BTW is status -s intended to be something plumbing-like;
> > something we can build upon and expect to be stable?
> > I'm just curious because other commands have a --porcelain
> > option and I wasn't sure if this was the intent.
> 
> We mentioned a --porcelain option in other discussion, but I don't think
> there is a patch. I would be in favor of --porcelain, even if it is
> currently identical to --short, because then it gives us freedom to
> diverge later (and in particular it gives us the freedom to let user
> configuration affect what is shown).
> 
> -Peff

The only use case would be for --amend.
Which is why I asked about --porcelain; really what I want is
something like

	git status --porcelain HEAD^

Rolling a patch to make --porcelain an alias for --short seems
like a good idea.  If we want to support HEAD^ and HEAD^ only
then perhaps an --amend flag is useful.

The real crux of my question was about being able to script
it, which is why commit --dry-run is not enough.

-- 

	David

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Wed, Sep 02, 2009 at 06:12:36PM -0700, David Aguilar wrote:

> The only use case would be for --amend.
> Which is why I asked about --porcelain; really what I want is
> something like
> 
> 	git status --porcelain HEAD^
> 
> Rolling a patch to make --porcelain an alias for --short seems
> like a good idea.  If we want to support HEAD^ and HEAD^ only
> then perhaps an --amend flag is useful.
> 
> The real crux of my question was about being able to script
> it, which is why commit --dry-run is not enough.

I see. I still think you may want to improve "commit --dry-run" with a
plumbing format, though, instead of "git status". Then it would
automagically support "--amend", as well as other dry-run things (e.g.,
"git commit --dry-run --porcelain --amend foo.c"). And not having looked
at the code, I would guess it is a one-liner patch to switch the "output
format" flag that commit passes to the wt-status.c code.

-Peff

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:

> I see. I still think you may want to improve "commit --dry-run" with a
> plumbing format, though, instead of "git status". Then it would
> automagically support "--amend", as well as other dry-run things (e.g.,
> "git commit --dry-run --porcelain --amend foo.c"). And not having looked
> at the code, I would guess it is a one-liner patch to switch the "output
> format" flag that commit passes to the wt-status.c code.

OK, it was a bit more complex than that. But here is a series which does
a few things. It is still missing a few bits, so is RFC.

  These first two are unrelated fixups that I noticed while working.

  [1/6]: status: typo fix in usage
  [2/6]: docs: note that status configuration affects only long format

  These are the --porcelain patches we discussed. The first two are
  obviously cleanup.

  [3/6]: status: refactor short-mode printing to its own function
  [4/6]: status: refactor format option parsing
  [5/6]: status: add --porcelain output format

  This brings the new formats to "commit --dry-run" to handle your case.
  Conceptually, it could come before (or instead) of 4/6 and 5/6, but as
  it adds both --short and --porcelain, there is an obvious dependency.

  [6/6]: commit: support alternate status formats

-Peff

[PATCH/RFC 1/6] status: typo fix in usage

[Jeff King]

Signed-off-by: Jeff King <peff@peff.net>
---
 builtin-commit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index 6cb0e40..812470e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -975,7 +975,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	static struct option builtin_status_options[] = {
 		OPT__VERBOSE(&verbose),
 		OPT_BOOLEAN('s', "short", &shortstatus,
-			    "show status concicely"),
+			    "show status concisely"),
 		OPT_BOOLEAN('z', "null", &null_termination,
 			    "terminate entries with NUL"),
 		{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
-- 
1.6.4.2.418.g1a1d3.dirty

[PATCH/RFC 2/6] docs: note that status configuration affects only long format

[Jeff King]

The short format does not respect any of the usual status.*
configuration.

Signed-off-by: Jeff King <peff@peff.net>
---
Combined with the --short/--porcelain distinction introduced later in
the series, should short perhaps respect status.relativePaths and
status.submoduleSummary? Which would mean replacing this patch with ones
to make those things work. :)

 Documentation/git-status.txt |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b5939d6..fd71a7a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -109,13 +109,13 @@ compatibility) and `color.status.<slot>` configuration variables
 to colorize its output.
 
 If the config variable `status.relativePaths` is set to false, then all
-paths shown are relative to the repository root, not to the current
-directory.
+paths shown in the long format are relative to the repository root, not
+to the current directory.
 
 If `status.submodulesummary` is set to a non zero number or true (identical
-to -1 or an unlimited number), the submodule summary will be enabled and a
-summary of commits for modified submodules will be shown (see --summary-limit
-option of linkgit:git-submodule[1]).
+to -1 or an unlimited number), the submodule summary will be enabled for
+the long format and a summary of commits for modified submodules will be
+shown (see --summary-limit option of linkgit:git-submodule[1]).
 
 SEE ALSO
 --------
-- 
1.6.4.2.418.g1a1d3.dirty

Re: [PATCH/RFC 2/6] docs: note that status configuration affects only long format

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Combined with the --short/--porcelain distinction introduced later in
> the series, should short perhaps respect status.relativePaths and
> status.submoduleSummary?

I think that makes sense. 

[PATCH/RFC 3/6] status: refactor short-mode printing to its own function

[Jeff King]

We want to be able to call it from multiple places.

Signed-off-by: Jeff King <peff@peff.net>
---
I am tempted to move all of the short-printing code to its own file, and
move "cmd_status" to its own builtin-status.c, as well. I don't know if
that is a cleanup that makes sense to others, as well, or if it is too
much churn for too little good.

 builtin-commit.c |   45 +++++++++++++++++++++++++--------------------
 1 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index 812470e..5b42179 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -966,11 +966,32 @@ static void short_untracked(int null_termination, struct string_list_item *it,
 	}
 }
 
+static void short_print(struct wt_status *s, int null_termination)
+{
+	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->stagemask)
+			short_unmerged(null_termination, it, s);
+		else
+			short_status(null_termination, it, s);
+	}
+	for (i = 0; i < s->untracked.nr; i++) {
+		struct string_list_item *it;
+
+		it = &(s->untracked.items[i]);
+		short_untracked(null_termination, it, s);
+	}
+}
+
 int cmd_status(int argc, const char **argv, const char *prefix)
 {
 	struct wt_status s;
 	static int null_termination, shortstatus;
-	int i;
 	unsigned char sha1[20];
 	static struct option builtin_status_options[] = {
 		OPT__VERBOSE(&verbose),
@@ -1003,25 +1024,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
 	wt_status_collect(&s);
 
-	if (shortstatus) {
-		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->stagemask)
-				short_unmerged(null_termination, it, &s);
-			else
-				short_status(null_termination, it, &s);
-		}
-		for (i = 0; i < s.untracked.nr; i++) {
-			struct string_list_item *it;
-
-			it = &(s.untracked.items[i]);
-			short_untracked(null_termination, it, &s);
-		}
-	} else {
+	if (shortstatus)
+		short_print(&s, null_termination);
+	else {
 		s.verbose = verbose;
 		if (s.relative_paths)
 			s.prefix = prefix;
-- 
1.6.4.2.418.g1a1d3.dirty

Re: [PATCH/RFC 3/6] status: refactor short-mode printing to its own function

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I am tempted to move all of the short-printing code to its own file, and
> move "cmd_status" to its own builtin-status.c, as well. I don't know if
> that is a cleanup that makes sense to others, as well, or if it is too
> much churn for too little good.

Earlier in the series when "git commit --dry-run" and "git status" still
were the same thing, I checked if the above was feasible and then decided
against it, because they needed to share the option parsing and the index
preparation, and exporting these functions inherently internal to "git
commit" only to use them in "git status" did not make much sense.

But once "git status" does not have anything to do with "git commit", I
think such a separation would become much more sensible.

[PATCH/RFC 4/6] status: refactor format option parsing

[Jeff King]

This makes it possible to have more than two formats.

Signed-off-by: Jeff King <peff@peff.net>
---
This would make a "--long" option trivial, but I'm not sure there is
much point.

 builtin-commit.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index 5b42179..aa4a358 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -991,12 +991,16 @@ static void short_print(struct wt_status *s, int null_termination)
 int cmd_status(int argc, const char **argv, const char *prefix)
 {
 	struct wt_status s;
-	static int null_termination, shortstatus;
+	static int null_termination;
+	static enum {
+		STATUS_FORMAT_LONG,
+		STATUS_FORMAT_SHORT,
+	} status_format = STATUS_FORMAT_LONG;
 	unsigned char sha1[20];
 	static struct option builtin_status_options[] = {
 		OPT__VERBOSE(&verbose),
-		OPT_BOOLEAN('s', "short", &shortstatus,
-			    "show status concisely"),
+		OPT_SET_INT('s', "short", &status_format,
+			    "show status concisely", STATUS_FORMAT_SHORT),
 		OPT_BOOLEAN('z', "null", &null_termination,
 			    "terminate entries with NUL"),
 		{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
@@ -1006,8 +1010,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 		OPT_END(),
 	};
 
-	if (null_termination)
-		shortstatus = 1;
+	if (null_termination && status_format == STATUS_FORMAT_LONG)
+		status_format = STATUS_FORMAT_SHORT;
 
 	wt_status_prepare(&s);
 	git_config(git_status_config, &s);
@@ -1024,9 +1028,11 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
 	wt_status_collect(&s);
 
-	if (shortstatus)
+	switch (status_format) {
+	case STATUS_FORMAT_SHORT:
 		short_print(&s, null_termination);
-	else {
+		break;
+	case STATUS_FORMAT_LONG:
 		s.verbose = verbose;
 		if (s.relative_paths)
 			s.prefix = prefix;
@@ -1035,6 +1041,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 		if (diff_use_color_default == -1)
 			diff_use_color_default = git_use_color_default;
 		wt_status_print(&s);
+		break;
 	}
 	return 0;
 }
-- 
1.6.4.2.418.g1a1d3.dirty

[PATCH/RFC 5/6] status: add --porcelain output format

[Jeff King]

The "short" format was added to "git status" recently to
provide a less verbose way of looking at the same
information. This has two practical uses:

  1. Users who want a more dense display of the information.

  2. Scripts which want to parse the information and need a
     stable, easy-to-parse interface.

For now, the "--short" format covers both of those uses.
However, as time goes on, users of (1) may want additional
format tweaks, or for "git status" to change its behavior
based on configuration variables. Those wishes will be at
odds with (2), which wants to stability for scripts.

This patch introduces a separate --porcelain option early to
avoid problems later on.  Right now the --short and
--porcelain outputs are identical. However, as time goes on,
we will have the freedom to customize --short for human
consumption while keeping --porcelain stable.

Signed-off-by: Jeff King <peff@peff.net>
---
No tests. Does this really need them? At this point, it would be pure
duplication of the --short tests; I am inclined to leave such tests
until later when there is actually a difference between the two formats
(and then we will know _what_ to test).

 Documentation/git-status.txt |    9 +++++++--
 builtin-commit.c             |    9 ++++++++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index fd71a7a..58d35fb 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -27,6 +27,11 @@ OPTIONS
 --short::
 	Give the output in the short-format.
 
+--porcelain::
+	Give the output in a stable, easy-to-parse format for scripts.
+	Currently this is identical to --short output, but is guaranteed
+	not to change in the future, making it safe for scripts.
+
 -u[<mode>]::
 --untracked-files[=<mode>]::
 	Show untracked files (Default: 'all').
@@ -45,8 +50,8 @@ used to change the default for when the option is not
 specified.
 
 -z::
-	Terminate entries with NUL, instead of LF.  This implies `-s`
-	(short status) output format.
+	Terminate entries with NUL, instead of LF.  This implies
+	the `--porcelain` output format if no other format is given.
 
 
 OUTPUT
diff --git a/builtin-commit.c b/builtin-commit.c
index aa4a358..ffdee31 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -995,12 +995,16 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	static enum {
 		STATUS_FORMAT_LONG,
 		STATUS_FORMAT_SHORT,
+		STATUS_FORMAT_PORCELAIN,
 	} status_format = STATUS_FORMAT_LONG;
 	unsigned char sha1[20];
 	static struct option builtin_status_options[] = {
 		OPT__VERBOSE(&verbose),
 		OPT_SET_INT('s', "short", &status_format,
 			    "show status concisely", STATUS_FORMAT_SHORT),
+		OPT_SET_INT(0, "porcelain", &status_format,
+			    "show porcelain output format",
+			    STATUS_FORMAT_PORCELAIN),
 		OPT_BOOLEAN('z', "null", &null_termination,
 			    "terminate entries with NUL"),
 		{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
@@ -1011,7 +1015,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	};
 
 	if (null_termination && status_format == STATUS_FORMAT_LONG)
-		status_format = STATUS_FORMAT_SHORT;
+		status_format = STATUS_FORMAT_PORCELAIN;
 
 	wt_status_prepare(&s);
 	git_config(git_status_config, &s);
@@ -1032,6 +1036,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	case STATUS_FORMAT_SHORT:
 		short_print(&s, null_termination);
 		break;
+	case STATUS_FORMAT_PORCELAIN:
+		short_print(&s, null_termination);
+		break;
 	case STATUS_FORMAT_LONG:
 		s.verbose = verbose;
 		if (s.relative_paths)
-- 
1.6.4.2.418.g1a1d3.dirty

[PATCH/RFC 6/6] commit: support alternate status formats

[Jeff King]

The status command recently grew "short" and "porcelain"
options for alternate output formats. Since status is no
longer "commit --dry-run", these formats are inaccessible to
people who do want to see a dry-run in a parseable form.

This patch makes those formats available to "git commit",
implying the "dry-run" option when they are used.

Signed-off-by: Jeff King <peff@peff.net>
---
This one is very RFC, as it has a few problems/questions:

 - no tests yet, and it definitely should have some

 - should alternate formats imply dry-run? It makes no sense to _not_ do
   dry-run, since you would be putting cruft into the editor for the
   user to see. But the other option would be barfing and complaining
   about mismatched options.

 - the "committable" flag is set in wt_status_print, which means it will
   not be set correctly for short output. I can hack it into the short
   output format, but I think it is probably a mistake for it to be
   stuck with the printing routines in the first place (it is a
   historical artifact, I suspect, from before we always had a "collect"
   phase). So I think it should probably just be part of the "collect"
   phase.

 Documentation/git-commit.txt |   14 ++++++++++++++
 builtin-commit.c             |   39 ++++++++++++++++++++++++++++++++-------
 2 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64f94cf..c45fbe4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -75,6 +75,20 @@ OPTIONS
 	and paths that are untracked, similar to the one that is given
 	in the commit log editor.
 
+--short::
+	When doing a dry-run, give the output in the short-format. See
+	linkgit:git-status[1] for details. Implies `--dry-run`.
+
+--porcelain::
+	When doing a dry-run, give the output in a porcelain-ready
+	format. See linkgit:git-status[1] for details. Implies
+	`--dry-run`.
+
+-z::
+	When showing `short` or `porcelain` status output, terminate
+	entries in the status output with NUL, instead of LF. If no
+	format is given, implies the `--porcelain` output format.
+
 -F <file>::
 --file=<file>::
 	Take the commit message from the given file.  Use '-' to
diff --git a/builtin-commit.c b/builtin-commit.c
index ffdee31..f2fd0a4 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -72,6 +72,15 @@ static int use_editor = 1, initial_commit, in_merge;
 static const char *only_include_assumed;
 static struct strbuf message;
 
+static int null_termination;
+static enum {
+	STATUS_FORMAT_LONG,
+	STATUS_FORMAT_SHORT,
+	STATUS_FORMAT_PORCELAIN,
+} status_format = STATUS_FORMAT_LONG;
+
+static void short_print(struct wt_status *s, int null_termination);
+
 static int opt_parse_m(const struct option *opt, const char *arg, int unset)
 {
 	struct strbuf *buf = opt->value;
@@ -105,6 +114,12 @@ static struct option builtin_commit_options[] = {
 	OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
 	OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
 	OPT_BOOLEAN(0, "dry-run", &dry_run, "show what would be committed"),
+	OPT_SET_INT(0, "short", &status_format, "show status concisely",
+		    STATUS_FORMAT_SHORT),
+	OPT_SET_INT(0, "porcelain", &status_format,
+		    "show porcelain output format", STATUS_FORMAT_PORCELAIN),
+	OPT_BOOLEAN('z', "null", &null_termination,
+		    "terminate entries with NUL"),
 	OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
 	{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
 	OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
@@ -363,7 +378,18 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
 	s->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;
 
 	wt_status_collect(s);
-	wt_status_print(s);
+
+	switch (status_format) {
+	case STATUS_FORMAT_SHORT:
+		short_print(s, null_termination);
+		break;
+	case STATUS_FORMAT_PORCELAIN:
+		short_print(s, null_termination);
+		break;
+	case STATUS_FORMAT_LONG:
+		wt_status_print(s);
+		break;
+	}
 
 	return s->commitable;
 }
@@ -821,6 +847,11 @@ static int parse_and_validate_options(int argc, const char *argv[],
 	else if (interactive && argc > 0)
 		die("Paths with --interactive does not make sense.");
 
+	if (null_termination && status_format == STATUS_FORMAT_LONG)
+		status_format = STATUS_FORMAT_PORCELAIN;
+	if (status_format != STATUS_FORMAT_LONG)
+		dry_run = 1;
+
 	return argc;
 }
 
@@ -991,12 +1022,6 @@ static void short_print(struct wt_status *s, int null_termination)
 int cmd_status(int argc, const char **argv, const char *prefix)
 {
 	struct wt_status s;
-	static int null_termination;
-	static enum {
-		STATUS_FORMAT_LONG,
-		STATUS_FORMAT_SHORT,
-		STATUS_FORMAT_PORCELAIN,
-	} status_format = STATUS_FORMAT_LONG;
 	unsigned char sha1[20];
 	static struct option builtin_status_options[] = {
 		OPT__VERBOSE(&verbose),
-- 
1.6.4.2.418.g1a1d3.dirty

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Sat, Sep 05, 2009 at 04:48:09AM -0400, Jeff King wrote:

> On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:
> 
> > I see. I still think you may want to improve "commit --dry-run" with a
> > plumbing format, though, instead of "git status". Then it would
> > automagically support "--amend", as well as other dry-run things (e.g.,
> > "git commit --dry-run --porcelain --amend foo.c"). And not having looked
> > at the code, I would guess it is a one-liner patch to switch the "output
> > format" flag that commit passes to the wt-status.c code.
> 
> OK, it was a bit more complex than that. But here is a series which does
> a few things. It is still missing a few bits, so is RFC.

BTW, in case it was not obvious from the context, these are built on top
of jc/1.7.0-status.

-Peff

Re: [PATCH v2] status: list unmerged files last

[Johannes Sixt]

On Mittwoch, 2. September 2009, David Aguilar wrote:
> No one has suggested this, so I figured I would.
> What do you think about this layout?
>
> - untracked
> - staged
> - modified
> - unmerged

You forget that these things also appear in the commit message editor. In that 
location, the important things must be at the *top*.

We can freely move the list of unmerged files because it will not appear in 
the commit message editor. The current order of the other lists is sane, IMO.

-- Hannes

Re: [PATCH v2] status: list unmerged files last

[Mark Brown]

On Wed, Sep 02, 2009 at 01:12:48AM -0400, Jeff King wrote:
> On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:

> > [1] It might even make sense to omit other sections and show only
> > "updated" and "unmerged" in this order when the index is unmerged, but
> > that is a lot more drastic change for 1.7.0.

> I think that is a really bad idea. The mental model of "git status"
> (versus individual diff or ls-files commands) is to see _everything_
> going on in the repo. Showing a subset breaks that model and gives a
> false sense of what is actually happening.

It would be nice to be able to explicitly ask to suppress some of the
output for cases where there's a lot of it and only a small part is
interesting (like when resolving a large merge as mentioned earlier) - I
often end up doing this by hand in those situations.  I do agree that
doing this by default would be surprising.

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Wed, Sep 02, 2009 at 01:48:32PM +0100, Mark Brown wrote:

> It would be nice to be able to explicitly ask to suppress some of the
> output for cases where there's a lot of it and only a small part is
> interesting (like when resolving a large merge as mentioned earlier) - I
> often end up doing this by hand in those situations.  I do agree that
> doing this by default would be surprising.

Yeah, we already have --untracked-files=<no|normal|all> and a matching
config variable. If there are cases people find useful, I don't see a
reason why we can't make other sections configurable, too. I think it
just somebody to write a patch for the behavior they think makes sense
(or at the very least a concrete proposal).

-Peff

Re: [PATCH v2] status: list unmerged files last

[Mark Brown]

On Wed, Sep 02, 2009 at 02:00:50PM -0400, Jeff King wrote:

> Yeah, we already have --untracked-files=<no|normal|all> and a matching
> config variable. If there are cases people find useful, I don't see a
> reason why we can't make other sections configurable, too. I think it
> just somebody to write a patch for the behavior they think makes sense
> (or at the very least a concrete proposal).

My main wishlist would be to have the same control for the changes to be
committed for the big merge case, the use case being while resolving
merges where those changes are those that have been dealt with and the
remaining (hopefully much fewer) changes are those that still need
attention.

Re: [PATCH v2] status: list unmerged files last

[Jeff King]

On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:

> My main wishlist would be to have the same control for the changes to be
> committed for the big merge case, the use case being while resolving
> merges where those changes are those that have been dealt with and the
> remaining (hopefully much fewer) changes are those that still need
> attention.

I think we need to be more concrete than that. What is the "big merge
case"? If there are any unmerged paths?

What exactly should be cut out, and how can it be configured? Should you
have "status.unmerged" to cut out certain things? Which things (of
staged, unstaged, and untracked)? Or should it go the other way, with a
status.showStaged variable which can be set to "always", "never", or
"unmerged" (and probably adding an "unmerged" option to
"status.showUntrackedFiles).

-Peff

Re: [PATCH v2] status: list unmerged files last

[Mark Brown]

On Sat, Sep 05, 2009 at 05:04:22AM -0400, Jeff King wrote:
> On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:

> > My main wishlist would be to have the same control for the changes to be
> > committed for the big merge case, the use case being while resolving

> I think we need to be more concrete than that. What is the "big merge
> case"? If there are any unmerged paths?

The context was that this was done when explictly requested by the user
so all the time when enabled.  In the context I'm thinking of this would
be used via the command line more than via the config file.

> What exactly should be cut out, and how can it be configured? Should you
> have "status.unmerged" to cut out certain things? Which things (of
> staged, unstaged, and untracked)? Or should it go the other way, with a
> status.showStaged variable which can be set to "always", "never", or
> "unmerged" (and probably adding an "unmerged" option to
> "status.showUntrackedFiles).

I'd been thinking of not showing anything in the index but keeping
everything else.  In terms of a configuration variable I'd go with
specifying the things not to show rather than the things to show - 
the noise to cut out.

Re: unmerged files listed in the beginning of git-status

[bill lam]

On Tue, 01 Sep 2009, Johannes Sixt wrote:
> > But unmerged entries are something you need to deal with _first_ before
> > being able to go further, so in that sense it is more important than
> > anything else in the traditional output.
> 
> This is actually an argument to place the unmerged entries *last* because this 
> is what will be visible after 'git status' finished. Remember that we don't 
> pass its output through the pager.

If output of git-status is read indirectly such as by gui client, then
it usually shows the top portion, in such cases, it might be desirable
to put unmerged file (the most important port) immediately visible.
But I don't have that experience.

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3