[RFC PATCH 0/2] Teach how to discard changes in the working directory

[RFC PATCH 0/2] Teach how to discard changes in the working directory

[Anders Melchiorsen]

Using "git checkout" to undo local changes is a hint that is often
given in #git. This patch (part 2) adds the hint into the status
output. A bit of restructuring appears in the initial patch.

This is merely an RFC, I am not sure whether I like it myself :-).


Anders.

[RFC PATCH 1/2] wt-status: Split header generation into three functions

[Anders Melchiorsen]

Reorganize header generation so that all header text related to each
block is in one place.

This adds a function, but makes it easier to see what is generated in
each case. It also allows for easy tweaking of individual headers.
---
 wt-status.c |   35 ++++++++++++++++++++---------------
 1 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 889e50f..ceb3a1e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -22,12 +22,6 @@ static char wt_status_colors[][COLOR_MAXLEN] = {
 	"\033[31m", /* WT_STATUS_NOBRANCH: red */
 };
 
-static const char use_add_msg[] =
-"use \"git add <file>...\" to update what will be committed";
-static const char use_add_rm_msg[] =
-"use \"git add/rm <file>...\" to update what will be committed";
-static const char use_add_to_include_msg[] =
-"use \"git add <file>...\" to include in what will be committed";
 enum untracked_status_type show_untracked_files = SHOW_NORMAL_UNTRACKED_FILES;
 
 static int parse_status_slot(const char *var, int offset)
@@ -76,12 +70,24 @@ static void wt_status_print_cached_header(struct wt_status *s)
 	color_fprintf_ln(s->fp, c, "#");
 }
 
-static void wt_status_print_header(struct wt_status *s,
-				   const char *main, const char *sub)
+static void wt_status_print_dirty_header(struct wt_status *s,
+					 int has_deleted)
 {
 	const char *c = color(WT_STATUS_HEADER);
-	color_fprintf_ln(s->fp, c, "# %s:", main);
-	color_fprintf_ln(s->fp, c, "#   (%s)", sub);
+	color_fprintf_ln(s->fp, c, "# Changed but not updated:");
+	if (!has_deleted) {
+		color_fprintf_ln(s->fp, c, "#   (use \"git add <file>...\" to update what will be committed)");
+	} else {
+		color_fprintf_ln(s->fp, c, "#   (use \"git add/rm <file>...\" to update what will be committed)");
+	}
+	color_fprintf_ln(s->fp, c, "#");
+}
+
+static void wt_status_print_untracked_header(struct wt_status *s)
+{
+	const char *c = color(WT_STATUS_HEADER);
+	color_fprintf_ln(s->fp, c, "# Untracked files:");
+	color_fprintf_ln(s->fp, c, "#   (use \"git add <file>...\" to include in what will be committed)");
 	color_fprintf_ln(s->fp, c, "#");
 }
 
@@ -166,14 +172,14 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
 	struct wt_status *s = data;
 	int i;
 	if (q->nr) {
-		const char *msg = use_add_msg;
+		int has_deleted = 0;
 		s->workdir_dirty = 1;
 		for (i = 0; i < q->nr; i++)
 			if (q->queue[i]->status == DIFF_STATUS_DELETED) {
-				msg = use_add_rm_msg;
+				has_deleted = 1;
 				break;
 			}
-		wt_status_print_header(s, "Changed but not updated", msg);
+		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]);
@@ -291,8 +297,7 @@ static void wt_status_print_untracked(struct wt_status *s)
 		}
 		if (!shown_header) {
 			s->workdir_untracked = 1;
-			wt_status_print_header(s, "Untracked files",
-					       use_add_to_include_msg);
+			wt_status_print_untracked_header(s);
 			shown_header = 1;
 		}
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
-- 
1.6.0.1.dirty

[RFC PATCH 2/2] wt-status: Teach how to discard changes in the working directory

[Anders Melchiorsen]

This is a question that comes up a lot in #git.
---
 t/t7502-status.sh |   10 ++++++++++
 wt-status.c       |    1 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index ceb3a1e..5bc3e36 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -80,6 +80,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,
 	} else {
 		color_fprintf_ln(s->fp, c, "#   (use \"git add/rm <file>...\" to update what will be committed)");
 	}
+	color_fprintf_ln(s->fp, c, "#   (use \"git checkout -- <file>...\" to discard changes in working directory)");
 	color_fprintf_ln(s->fp, c, "#");
 }
 
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
index 38a48b5..efa1239 100755
--- a/t/t7502-status.sh
+++ b/t/t7502-status.sh
@@ -46,6 +46,7 @@ cat > expect << \EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -76,6 +77,7 @@ cat >expect <<EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -104,6 +106,7 @@ cat >expect <<EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -138,6 +141,7 @@ cat >expect <<EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -174,6 +178,7 @@ cat > expect << \EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   modified
 #
@@ -204,6 +209,7 @@ cat > expect << \EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -267,6 +273,7 @@ cat >expect <<EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -297,6 +304,7 @@ cat >expect <<EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -326,6 +334,7 @@ cat >expect <<EOF
 # On branch master
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
@@ -357,7 +366,7 @@ cat >expect <<EOF
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #	modified:   dir1/modified
 #
-- 
1.6.0.1.dirty

Re: [RFC PATCH 0/2] Teach how to discard changes in the working directory

[Junio C Hamano]

Anders Melchiorsen <mail@cup.kalibalik.dk> writes:

> Using "git checkout" to undo local changes is a hint that is often
> given in #git. This patch (part 2) adds the hint into the status
> output. A bit of restructuring appears in the initial patch.
>
> This is merely an RFC, I am not sure whether I like it myself :-).

While I think the patch means well, I personally think that the output is
already too chatty with these "friendly hints" about add/rm/reset.  After
this series, will we be adding 'use "git checkout HEAD -- <path>" to go
back to the state of the latest commit', and then "if you want to stage
only part of the change, use "git add -i <path>"?  "To temporarily remove
the change use "git stash"?

I would agree that "hint is often given in #git" is an indication that
people do not know "git checkout" to check out the path from the index to
get rid of the change.  I further suspect that "I modified my file and git
status says 'Changed but not updated'; what should I do" may not be asked
often anymore, which might owe the hint we have in status output.  Even
then, I do not necessarily agree that the status output (yes, I am also
questioning the existing hints as well) is the best place to teach these
people.

The approach would lead to insanely long output that reproduces the user
manual, and we should draw the line somewhere.  As I said, I suspect that
what we say is already too chatty.

Re: [RFC PATCH 0/2] Teach how to discard changes in the working directory

[Pieter de Bie]

On 8 sep 2008, at 00:48, Junio C Hamano wrote:

> I would agree that "hint is often given in #git" is an indication that
> people do not know "git checkout" to check out the path from the  
> index to
> get rid of the change.  I further suspect that "I modified my file  
> and git
> status says 'Changed but not updated'; what should I do" may not be  
> asked
> often anymore, which might owe the hint we have in status output.   
> Even
> then, I do not necessarily agree that the status output (yes, I am  
> also
> questioning the existing hints as well) is the best place to teach  
> these
> people.

Yes, this seems unclear to a lot of people. How about a small and  
focused
man-page or similar to help people explain the differences between the
working directory, the index and HEAD? Then we can just add something
like

	If you are unsure what to do, run `git help stage-changes`

or so. This would differ from the git-commit man-page in that there is
less clutter and most likely contains the information the user needs
at the top of the page.

- Pieter

Re: [RFC PATCH 0/2] Teach how to discard changes in the working directory

[Junio C Hamano]

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

> I would agree that "hint is often given in #git" is an indication that
> people do not know "git checkout" to check out the path from the index to
> get rid of the change.  I further suspect that "I modified my file and git
> status says 'Changed but not updated'; what should I do" may not be asked
> often anymore, which might owe the hint we have in status output.  Even
> then, I do not necessarily agree that the status output (yes, I am also
> questioning the existing hints as well) is the best place to teach these
> people.
>
> The approach would lead to insanely long output that reproduces the user
> manual, and we should draw the line somewhere.  As I said, I suspect that
> what we say is already too chatty.

Having said all that, I'll queue them to see what other people think.