Trouble testing out a patch on a branch new scratch git.git repository

Trouble testing out a patch on a branch new scratch git.git repository

[Brent Goodrick]

Hi,

I have a patch ready for my new --progress switch, and am trying to
prepare the PATCH/RFC email.  I am having problems testing out the
patch with get-am.  I suspect if my patch is going to have any hope at
being applied, I have to figure out what is causing git am to fail to
apply the change.

So, here is what I think happened in my repo:

1. A while ago, I made some changes and began testing them out.
2. I committed the change into the first commit (see
e802880bb89524b1f70132f1ca0716624788db3f below)
3. Unfortunately, I then stumbled across the coding guidelines, and
then discovered that my if statements had too many curly braces, and
fixed that with another commit (but I doubt that is the problem here)
4. I did a git pull origin and found a conflict in a file I had
changed in the first commit above into cache.h (I had inserted a line
right where someone else had inserted a line). I probably should have
stopped right then and there and not gone ahead with the merge, but do
something different (but if so, then what should I have done instead?)
:)
5. I manually edited cache.h to resolve the conflict, and then
executed "git add cache.h"
6. Committed the merge with git commit
(78f968776048d6dace68e6367fbd4e7d81041fef below)
7. Ran "git format-patch -M --stdout origin/master" and dumped it to a file.
8. Created a new scratch repository and tried to apply the patch with
this script:

#!/bin/sh
set -x
set -e
cd /tmp
rm -rf checkout_test
mkdir checkout_test
cd checkout_test
git clone git://git.kernel.org/pub/scm/git/git.git
cd git
git am /tmp/patch

And the git am command failed on the cache.h file that had the
conflict I manually fixed. But note also a failure to apply the change
to git.c too (which, BTW, did not require any man-handling during the
merge). The output of that git am command is:

git am /tmp/patch
Applying: Add progress options
error: patch failed: cache.h:371
error: cache.h: patch does not apply
error: patch failed: git.c:4
error: git.c: patch does not apply
Patch failed at 0001 Add progress options
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

Here is a trimmed down git log output showing where my commits stand
w.r.t. the merge and the other commits in between (see <snip> line):


git log -100
commit 78f968776048d6dace68e6367fbd4e7d81041fef
Merge: 44b1f2e... 621f1b4...
Author: Brent Goodrick <brentg@hungover.brentg.com>
Date:   Sun Feb 8 11:03:13 2009 -0800

    Merge branch 'master' of git://git.kernel.org/pub/scm/git/git

    Conflicts:
    	cache.h

commit 44b1f2ecd2dc19ccb04660a730814c7b07b6d838
Author: Brent Goodrick <brentg@hungover.brentg.com>
Date:   Sun Feb 8 10:53:33 2009 -0800

    Conform to git coding standards

    This is a cosmetic change to remove curly braces used if statements
    that have only one statement in the true or false clauses.

<snip>... many other commits here </snip>

commit e802880bb89524b1f70132f1ca0716624788db3f
Author: Brent Goodrick <brentg@hungover.brentg.com>
Date:   Mon Feb 2 19:34:56 2009 -0800

    Add progress options

    Add --progress, --no-progress, and --progress-verbose options, which
    correspond to the GIT_PROGRESS environment variable setting of "1",
    "0", and "verbose", respectively.

    Signed-off-by: Brent Goodrick <bgoodr@gmail.com>


Any ideas as to what I need to do next here?  Even if this patch gets
rejected from being put into git.git, I still would like to know what
I did wrong.

Thanks,
bgoodr

P.S., For everyone's reference, the rest of this message contains a
raw dump of the "git format-patch -M --stdout origin/master" command
showing my work in progress that I would like to somehow reform into
an eventual PATCH/RFC email.

P.S.S. Please also reply while CCing me as I have hence had to take
myself off of the mailing list (I can't process 100+ messages per
day). 8)





--- cut here ---
From e802880bb89524b1f70132f1ca0716624788db3f Mon Sep 17 00:00:00 2001
From: Brent Goodrick <brentg@hungover.brentg.com>
Date: Mon, 2 Feb 2009 19:34:56 -0800
Subject: [PATCH 1/2] Add progress options

Add --progress, --no-progress, and --progress-verbose options, which
correspond to the GIT_PROGRESS environment variable setting of "1",
"0", and "verbose", respectively.

Signed-off-by: Brent Goodrick <bgoodr@gmail.com>
---
 Documentation/git.txt                  |   15 +++++++++++++
 builtin-pack-objects.c                 |    2 +-
 cache.h                                |    1 +
 contrib/completion/git-completion.bash |    3 ++
 git.c                                  |    8 ++++++-
 progress.c                             |   33 ++++++++++++++++++++++++----
 sideband.c                             |   36 ++++++++++++++++++++++++++++---
 7 files changed, 87 insertions(+), 11 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index 17dc8b2..158b313 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -11,6 +11,7 @@ SYNOPSIS
 [verse]
 'git' [--version] [--exec-path[=GIT_EXEC_PATH]]
     [-p|--paginate|--no-pager]
+    [--progress|--no-progress|--progress-verbose]
     [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
     [--help] COMMAND [ARGS]

@@ -176,6 +177,20 @@ help ...`.
 --no-pager::
 	Do not pipe git output into a pager.

+--progress::
+	Show progress for long-running processing. This corresponds to
+	setting the GIT_PROGRESS environment variable to 1. This is
+	the default.
+
+--no-progress::
+	Instead of showing intermediate progress, just show
+	completion of major steps in processing. This corresponds to
+	setting the GIT_PROGRESS environment variable to 0.
+
+--progress-verbose::
+	Enable progress and show intermediate progress results as one
+	per line.
+
 --git-dir=<path>::
 	Set the path to the repository. This can also be controlled by
 	setting the GIT_DIR environment variable. It can be an absolute
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index cb51916..7ba5268 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -81,7 +81,7 @@ static int depth = 50;
 static int delta_search_threads;
 static int pack_to_stdout;
 static int num_preferred_base;
-static struct progress *progress_state;
+static struct progress *progress_state = NULL;
 static int pack_compression_level = Z_DEFAULT_COMPRESSION;
 static int pack_compression_seen;

diff --git a/cache.h b/cache.h
index 8d965b8..ecfda5a 100644
--- a/cache.h
+++ b/cache.h
@@ -371,6 +371,7 @@ static inline enum object_type
object_type(unsigned int mode)
 #define GITATTRIBUTES_FILE ".gitattributes"
 #define INFOATTRIBUTES_FILE "info/attributes"
 #define ATTRIBUTE_MACRO_PREFIX "[attr]"
+#define GIT_PROGRESS_ENVIRONMENT "GIT_PROGRESS"

 extern int is_bare_repository_cfg;
 extern int is_bare_repository(void);
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 81f70ec..a555241 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1701,6 +1701,9 @@ _git ()
 		--*)   __gitcomp "
 			--paginate
 			--no-pager
+			--progress
+			--no-progress
+			--progress-verbose
 			--git-dir=
 			--bare
 			--version
diff --git a/git.c b/git.c
index ecc8fad..166a201 100644
--- a/git.c
+++ b/git.c
@@ -4,7 +4,7 @@
 #include "quote.h"

 const char git_usage_string[] =
-	"git [--version] [--exec-path[=GIT_EXEC_PATH]]
[-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR]
[--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
+	"git [--version] [--exec-path[=GIT_EXEC_PATH]]
[-p|--paginate|--no-pager]
[--progress|--no-progress|--progress-verbose] [--bare]
[--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND
[ARGS]";

 const char git_more_info_string[] =
 	"See 'git help COMMAND' for more information on a specific command.";
@@ -115,6 +115,12 @@ static int handle_options(const char*** argv,
int* argc, int* envchanged)
 			setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);
 			if (envchanged)
 				*envchanged = 1;
+		} else if (!strcmp(cmd, "--progress")) {
+			setenv(GIT_PROGRESS_ENVIRONMENT, "1", 1);
+		} else if (!strcmp(cmd, "--no-progress")) {
+			setenv(GIT_PROGRESS_ENVIRONMENT, "0", 1);
+		} else if (!strcmp(cmd, "--progress-verbose")) {
+			setenv(GIT_PROGRESS_ENVIRONMENT, "verbose", 1);
 		} else {
 			fprintf(stderr, "Unknown option: %s\n", cmd);
 			usage(git_usage_string);
diff --git a/progress.c b/progress.c
index 55a8687..f92eaaa 100644
--- a/progress.c
+++ b/progress.c
@@ -10,6 +10,7 @@

 #include "git-compat-util.h"
 #include "progress.h"
+#include "cache.h"

 #define TP_IDX_MAX      8

@@ -36,6 +37,8 @@ struct progress {
 };

 static volatile sig_atomic_t progress_update;
+static int show_progress = 1;
+static int show_progress_verbose = 0;

 static void progress_interval(int signum)
 {
@@ -90,15 +93,20 @@ static int display(struct progress *progress,
unsigned n, const char *done)

 	progress->last_value = n;
 	tp = (progress->throughput) ? progress->throughput->display : "";
-	eol = done ? done : "   \r";
+	eol = done ? done : (show_progress_verbose ? "   \n" : "   \r");
 	if (progress->total) {
 		unsigned percent = n * 100 / progress->total;
 		if (percent != progress->last_percent || progress_update) {
 			progress->last_percent = percent;
-			fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
-				progress->title, percent, n,
-				progress->total, tp, eol);
-			fflush(stderr);
+			/* Show progress everytime if specified. But if progress is turned
+			 * off, only show the last message (when done is non-NULL) as a
+			 * summary: */
+			if (show_progress || done) {
+				fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
+						progress->title, percent, n,
+						progress->total, tp, eol);
+				fflush(stderr);
+			}
 			progress_update = 0;
 			return 1;
 		}
@@ -206,6 +214,21 @@ struct progress *start_progress_delay(const char
*title, unsigned total,
 				       unsigned percent_treshold, unsigned delay)
 {
 	struct progress *progress = malloc(sizeof(*progress));
+	const char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);
+	if (show_progress_env) {
+		if (!strcmp(show_progress_env, "true")) {
+			show_progress_env = "1";
+		}
+		if (!strcmp(show_progress_env, "false")) {
+			show_progress_env = "0";
+		}
+		if (!strcmp(show_progress_env, "verbose")) {
+			/* Show progress, but use LF codes in the output and not CR codes: */
+			show_progress_verbose = 1;
+		} else if (!strcmp(show_progress_env, "0")) {
+			show_progress = 0;
+		}
+	}
 	if (!progress) {
 		/* unlikely, but here's a good fallback */
 		fprintf(stderr, "%s...\n", title);
diff --git a/sideband.c b/sideband.c
index cca3360..21766a4 100644
--- a/sideband.c
+++ b/sideband.c
@@ -1,5 +1,6 @@
 #include "pkt-line.h"
 #include "sideband.h"
+#include "cache.h"

 /*
  * Receive multiplexed output stream over git native protocol.
@@ -26,7 +27,24 @@ int recv_sideband(const char *me, int in_stream,
int out, int err)
 	char buf[LARGE_PACKET_MAX + 2*FIX_SIZE];
 	char *suffix, *term;
 	int skip_pf = 0;
-
+	int show_progress = 1;
+	int show_progress_verbose = 0;
+	const char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);
+	if (show_progress_env) {
+		if (!strcmp(show_progress_env, "true")) {
+			show_progress_env = "1";
+		}
+		if (!strcmp(show_progress_env, "false")) {
+			show_progress_env = "0";
+		}
+		if (!strcmp(show_progress_env, "0")) {
+			show_progress = 0;
+		}
+		else if (!strcmp(show_progress_env, "verbose")) {
+			/* Show progress, but use LF codes in the output and not CR codes: */
+			show_progress_verbose = 1;
+		}
+	}
 	memcpy(buf, PREFIX, pf);
 	term = getenv("TERM");
 	if (term && strcmp(term, "dumb"))
@@ -58,6 +76,7 @@ int recv_sideband(const char *me, int in_stream, int
out, int err)
 			do {
 				char *b = buf;
 				int brk = 0;
+				int cr = 0;

 				/*
 				 * If the last buffer didn't end with a line
@@ -78,9 +97,15 @@ int recv_sideband(const char *me, int in_stream,
int out, int err)
 						brk = 0;
 						break;
 					}
-					if (b[brk-1] == '\n' ||
-					    b[brk-1] == '\r')
+					if (b[brk-1] == '\n') {
+						break;
+					} else if (b[brk-1] == '\r') {
+						if (show_progress_verbose) {
+							b[brk-1] = '\n';
+						}
+						cr = 1;
 						break;
+					}
 				}

 				/*
@@ -95,7 +120,10 @@ int recv_sideband(const char *me, int in_stream,
int out, int err)
 					memcpy(save, b + brk, sf);
 					b[brk + sf - 1] = b[brk - 1];
 					memcpy(b + brk - 1, suffix, sf);
-					safe_write(err, b, brk + sf);
+					/* Progress messages are those that end in CR codes */
+					if (show_progress || !cr) {
+						safe_write(err, b, brk + sf);
+					}
 					memcpy(b + brk, save, sf);
 					len -= brk;
 				} else {
-- 
1.6.2.rc0.3.g78f96


>From 44b1f2ecd2dc19ccb04660a730814c7b07b6d838 Mon Sep 17 00:00:00 2001
From: Brent Goodrick <brentg@hungover.brentg.com>
Date: Sun, 8 Feb 2009 10:53:33 -0800
Subject: [PATCH 2/2] Conform to git coding standards

This is a cosmetic change to remove curly braces in if statements
that have only one statement in the true or false clauses.
---
 progress.c |   14 ++++++--------
 sideband.c |   23 ++++++++---------------
 2 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/progress.c b/progress.c
index f92eaaa..c96d594 100644
--- a/progress.c
+++ b/progress.c
@@ -93,6 +93,8 @@ static int display(struct progress *progress,
unsigned n, const char *done)

 	progress->last_value = n;
 	tp = (progress->throughput) ? progress->throughput->display : "";
+	/* When show_progress_verbose is true, put each progress message on a
+	 * separate line: */
 	eol = done ? done : (show_progress_verbose ? "   \n" : "   \r");
 	if (progress->total) {
 		unsigned percent = n * 100 / progress->total;
@@ -216,18 +218,14 @@ struct progress *start_progress_delay(const char
*title, unsigned total,
 	struct progress *progress = malloc(sizeof(*progress));
 	const char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);
 	if (show_progress_env) {
-		if (!strcmp(show_progress_env, "true")) {
+		if (!strcmp(show_progress_env, "true"))
 			show_progress_env = "1";
-		}
-		if (!strcmp(show_progress_env, "false")) {
+		if (!strcmp(show_progress_env, "false"))
 			show_progress_env = "0";
-		}
-		if (!strcmp(show_progress_env, "verbose")) {
-			/* Show progress, but use LF codes in the output and not CR codes: */
+		if (!strcmp(show_progress_env, "verbose"))
 			show_progress_verbose = 1;
-		} else if (!strcmp(show_progress_env, "0")) {
+		else if (!strcmp(show_progress_env, "0"))
 			show_progress = 0;
-		}
 	}
 	if (!progress) {
 		/* unlikely, but here's a good fallback */
diff --git a/sideband.c b/sideband.c
index 21766a4..4bfb206 100644
--- a/sideband.c
+++ b/sideband.c
@@ -31,19 +31,14 @@ int recv_sideband(const char *me, int in_stream,
int out, int err)
 	int show_progress_verbose = 0;
 	const char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);
 	if (show_progress_env) {
-		if (!strcmp(show_progress_env, "true")) {
+		if (!strcmp(show_progress_env, "true"))
 			show_progress_env = "1";
-		}
-		if (!strcmp(show_progress_env, "false")) {
+		if (!strcmp(show_progress_env, "false"))
 			show_progress_env = "0";
-		}
-		if (!strcmp(show_progress_env, "0")) {
+		if (!strcmp(show_progress_env, "0"))
 			show_progress = 0;
-		}
-		else if (!strcmp(show_progress_env, "verbose")) {
-			/* Show progress, but use LF codes in the output and not CR codes: */
+		else if (!strcmp(show_progress_env, "verbose"))
 			show_progress_verbose = 1;
-		}
 	}
 	memcpy(buf, PREFIX, pf);
 	term = getenv("TERM");
@@ -97,12 +92,11 @@ int recv_sideband(const char *me, int in_stream,
int out, int err)
 						brk = 0;
 						break;
 					}
-					if (b[brk-1] == '\n') {
+					if (b[brk-1] == '\n')
 						break;
-					} else if (b[brk-1] == '\r') {
-						if (show_progress_verbose) {
+					else if (b[brk-1] == '\r') {
+						if (show_progress_verbose)
 							b[brk-1] = '\n';
-						}
 						cr = 1;
 						break;
 					}
@@ -121,9 +115,8 @@ int recv_sideband(const char *me, int in_stream,
int out, int err)
 					b[brk + sf - 1] = b[brk - 1];
 					memcpy(b + brk - 1, suffix, sf);
 					/* Progress messages are those that end in CR codes */
-					if (show_progress || !cr) {
+					if (show_progress || !cr)
 						safe_write(err, b, brk + sf);
-					}
 					memcpy(b + brk, save, sf);
 					len -= brk;
 				} else {
-- 
1.6.2.rc0.3.g78f96
--- cut here ---

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Junio C Hamano]

Brent Goodrick <bgoodr@gmail.com> writes:

> So, here is what I think happened in my repo:
>
> 1. A while ago, I made some changes and began testing them out.
> 2. I committed the change into the first commit (see
> e802880bb89524b1f70132f1ca0716624788db3f below)
> 3. Unfortunately, I then stumbled across the coding guidelines, and
> then discovered that my if statements had too many curly braces, and
> fixed that with another commit (but I doubt that is the problem here)
> 4. I did a git pull origin and found a conflict in a file I had
> changed in the first commit above into cache.h (I had inserted a line
> right where someone else had inserted a line). I probably should have
> stopped right then and there and not gone ahead with the merge, but do
> something different (but if so, then what should I have done instead?)
> :)

Your work is about adding this new feature.  Use a topic branch.

Now what is that topic branch is for?  Yes, it is about adding this new
feature, and nothing else.  Don't pull other people's changes made on my
tree into it.  That will make your topic branch "one new feature and
everything else" and useless as a topic branch.

What would make your life easier would be:

	$ git pull ;# to get up to date with me on your master branch
        $ git checkout -b bg/no-progress origin/master
        ... work on e802880 ...
	... test it ...
        $ git commit ;# record that on bg/no-progress topic

        $ git checkout master
        $ git merge bg/no-progress
        ... test the result of the merge ...

        $ git checkout bg/no-progress
        ... work on style fix ...
        ... test it ...
        $ git commit ;# again record it on bg/no-progress topic
                        
        $ git checkout master
        $ git merge bg/no-progress
        ... test the result of the merge ...

        $ git pull ;# to get up to date with me
        ... resolve conflicts ...

Then after you are convinced that everything on bg/no-progress is worthy
of sending to the list [*A*], but its tip is stale because things have
progressed on my end, you can do this:

	$ git checkout bg/no-progress
        $ git rebase origin/master	;# and rebase to the upstream
        
which may conflict again (but that would be the same conflict you saw with
your "git pull" from me, and rerere may remember it).

Review and test the result and then:

	$ git format-patch origin/master

There can be variants in the last few steps.  For example, your commits on
bg/no-progress may be full of "Oops, this is to fix my own mistake made in
earlier commits since I forked from the upstream".  You would not want to
have them in your submission (instead, you would want to pretend as if you
never made these mistakes in the first place).  For that, you may want to
do, after you feel the tip of bg/no-progress is in a good shape at point
*A* above:

	$ git checkout bg/no-progress
        $ git rebase -i origin/master	;# and rebase to the upstream
        
and reorder, squash, and fix them.

Also you may feel that at point [*A*] what you have is very precious and
you would not want yourself breaking it by the final rebase (which is a
very reasonable thing to feel).  In such a case, the final rewrite could
be:

	$ git checkout bg/no-progress^0
        $ git rebase -i origin/master	;# and rebase to the upstream
	... test and review the result.
        ... convince yourself it is indeed better than
        ... what you earlier thought to be "very precious".
        ... and then finally
	$ git branch -f bg/no-progress
	$ git format-patch origin/master ;# send this

And to finish it off, you may do:

	$ git checkout master
        $ git merge --ours bg/no-progress

The above is a suggestion based on a design to allow you keep sticking to
your merge based workflow as much as possible, but you could instead
choose to keep rebasing.  I have some observations at the end of

    http://gitster.livejournal.com/24080.html

comparing the merge based workflow and the rebase based one.

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Brent Goodrick]

Much thanks for your extensive writeup, Junio! I will try to follow your
advice on a brand new git clone'ed repository and just reapply my
changes there into the topic branch (makes sense for these small sets
of changes; but not for larger sets ... read my comments below).

But for my education, I've interspersed below some questions where I
am still misunderstanding the situation or intent behind your
recommendation:

On Sun, Feb 8, 2009 at 1:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Now what is that topic branch is for?  Yes, it is about adding this new
> feature, and nothing else.  Don't pull other people's changes made on my
> tree into it.  That will make your topic branch "one new feature and
> everything else" and useless as a topic branch.

Fair enough, but I don't understand what is referred to by "my tree" above?

>
> What would make your life easier would be:
>
>        $ git pull ;# to get up to date with me on your master branch

I am concluding that I need to throw away (well, saving it off first) my
current repo and then do the git pull only from within a fresh git clone?

>        $ git checkout -b bg/no-progress origin/master
>        ... work on e802880 ...
>        ... test it ...
>        $ git commit ;# record that on bg/no-progress topic
>
>        $ git checkout master
>        $ git merge bg/no-progress
>        ... test the result of the merge ...

Refering to that git merge bg/no-progress command above. You said not
to merge from master to bg/no-progress at this early stage, which
makes sense, but now you are going in the reverse via master <--
bg/no-progress. And here I do not see a commit, but that command is
followed straight way with a "git checkout bg/no-progress" below.  Is
that just for testing the merge with the intent of just throwing the
changes away?  In other words, is this next "git checkout
bg/no-progress" command going to silently throw away the "git merge
bg/progress" step at this point?

>
>        $ git checkout bg/no-progress
>        ... work on style fix ...
>        ... test it ...
>        $ git commit ;# again record it on bg/no-progress topic
>
>        $ git checkout master
>        $ git merge bg/no-progress
>        ... test the result of the merge ...
>
>        $ git pull ;# to get up to date with me
>        ... resolve conflicts ...
>
> Then after you are convinced that everything on bg/no-progress is worthy
> of sending to the list [*A*], but its tip is stale because things have
> progressed on my end, you can do this:

Similar question: Is this next "git checkout bg/no-progress" below
going to loose the conflicts I would have just resolved above
(referring to the most recent "... resolve conflicts ..." line above)?

>
>        $ git checkout bg/no-progress
>        $ git rebase origin/master      ;# and rebase to the upstream
>
> which may conflict again (but that would be the same conflict you saw with
> your "git pull" from me, and rerere may remember it).

What does "rerere" mean, or is that a typo?

>
> Review and test the result and then:
>
>        $ git format-patch origin/master
>
> There can be variants in the last few steps.  For example, your commits on
> bg/no-progress may be full of "Oops, this is to fix my own mistake made in
> earlier commits since I forked from the upstream".  You would not want to
> have them in your submission (instead, you would want to pretend as if you
> never made these mistakes in the first place).  For that, you may want to
> do, after you feel the tip of bg/no-progress is in a good shape at point
> *A* above:
>
>        $ git checkout bg/no-progress
>        $ git rebase -i origin/master   ;# and rebase to the upstream
>
> and reorder, squash, and fix them.

What do you mean by "reorder, squash" mean here? Is that something
that is done as a part of the -i option to git rebase?

>
> Also you may feel that at point [*A*] what you have is very precious and
> you would not want yourself breaking it by the final rebase (which is a
> very reasonable thing to feel).  In such a case, the final rewrite could
> be:
>
>        $ git checkout bg/no-progress^0
>        $ git rebase -i origin/master   ;# and rebase to the upstream
>        ... test and review the result.
>        ... convince yourself it is indeed better than
>        ... what you earlier thought to be "very precious".
>        ... and then finally
>        $ git branch -f bg/no-progress
>        $ git format-patch origin/master ;# send this

What is the significance of the ^0 construct tacked onto the end of
"bg/no-progress" at this point, versus just "git checkout
bg/no-progress" without the "^0"?

I made the mistake of reading the "SPECIFYING REVISIONS" section in
git-rev-parse(1) manual, which states:

    A suffix ^ to a revision parameter means the first parent of that
    commit object. ^<n> means the <n>th parent (i.e. rev^ is
    equivalent to rev^1). As a special rule, rev^0 means the commit
    itself and is used when rev is the object name of a tag object
    that refers to a commit object.

I'm having a hard time translating "tag object" and "commit object"
into things I understand w.r.t. the repo I see from my end.

>
> And to finish it off, you may do:
>
>        $ git checkout master
>        $ git merge --ours bg/no-progress

The --ours option to git-merge does not seem to be documented (at
least it is not in the user manual). There is a --ours option
indicated in the git-checkout man page.

>
> The above is a suggestion based on a design to allow you keep sticking to
> your merge based workflow as much as possible, but you could instead
> choose to keep rebasing.  I have some observations at the end of
>
>    http://gitster.livejournal.com/24080.html
>
> comparing the merge based workflow and the rebase based one.
>

The rebase flow would work better for this given that I do eventually
want to send my changes upstream. So, for my/our future Googling
reference: I quote the section out of
http://gitster.livejournal.com/24080.html that I believe applied to me
_before_ I messed things up so badly:

your_blog> Another advantage of rebasing your personal patch constantly is that
your_blog> it forces you a discipline to adjust your changes to the changes in
your_blog> the upstream as early as possible.  If you do not rebase
and choose to
your_blog> use merge in your workflow, your personal changes will be buried deep
your_blog> in the history.  When one of your many later merges with the upstream
your_blog> made you resolve the conflicts with such old changes, two things
your_blog> happen:
your_blog>
your_blog>     * You do not remember what your own change was about, and have a
your_blog>       hard time resolving the conflict;
your_blog>
your_blog>     * You may be able to resolve the conflict, but what you can
your_blog>       extract from "git log --no-merges origin.." will not be
your_blog>       something you can eventually send upstream.  You will need to
your_blog>       rebase before submitting.

Again, much MUCH thanks for your assistance!

Brent

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

On Sunday 08 February 2009 18:13:00 you wrote:
> On Sun, Feb 8, 2009 at 1:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Now what is that topic branch is for?  Yes, it is about adding this new
> > feature, and nothing else.  Don't pull other people's changes made on my
> > tree into it.  That will make your topic branch "one new feature and
> > everything else" and useless as a topic branch.
>
> Fair enough, but I don't understand what is referred to by "my tree" above?

Junio means his git tree.  Which is where we get releases from.

> >        $ git checkout -b bg/no-progress origin/master
> >        ... work on e802880 ...
> >        ... test it ...
> >        $ git commit ;# record that on bg/no-progress topic
> >
> >        $ git checkout master
> >        $ git merge bg/no-progress
> >        ... test the result of the merge ...
>
> Refering to that git merge bg/no-progress command above. You said not
> to merge from master to bg/no-progress at this early stage, which
> makes sense, but now you are going in the reverse via master <--
> bg/no-progress.

Well, master is not a topic branch, so merging a topic branch into it is not 
necessarily bad.

> And here I do not see a commit, but that command is
> followed straight way with a "git checkout bg/no-progress" below.  Is
> that just for testing the merge with the intent of just throwing the
> changes away?

Merge automatically does a commit unless there are conflicts.

> In other words, is this next "git checkout
> bg/no-progress" command going to silently throw away the "git merge
> bg/progress" step at this point?

No, it doesn't throw it away.  However, it never made any changes to pg/no-
progress just to master, so bg/no-progress will not show the results of the 
merge.

> Similar question: Is this next "git checkout bg/no-progress" below
> going to loose the conflicts I would have just resolved above
> (referring to the most recent "... resolve conflicts ..." line above)?

It's going to but you back on bg/no-progress, which doesn't have Junio's 
latest changes, so there won't be any conflicts immediately.

> > which may conflict again (but that would be the same conflict you saw
> > with your "git pull" from me, and rerere may remember it).
> What does "rerere" mean, or is that a typo?

REuse REcorded REsolutions.  It's a git option to remember how you resolved 
merge conflicts and automatically apply those resolutions later.

> > and reorder, squash, and fix them.
> What do you mean by "reorder, squash" mean here? Is that something
> that is done as a part of the -i option to git rebase?

Reordering and squashing can be done via rebase -i, but it's basically just 
the practice of "prettying" your changes.  
http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ has more 
prose on the subject.

> >        $ git checkout bg/no-progress^0
> What is the significance of the ^0 construct tacked onto the end of
> "bg/no-progress" at this point, versus just "git checkout
> bg/no-progress" without the "^0"?

It took me a second, but I believe this checks out bg/no-progress and detaches 
HEAD.
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Brent Goodrick]

On Sun, Feb 8, 2009 at 5:18 PM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> > What do you mean by "reorder, squash" mean here? Is that something
> > that is done as a part of the -i option to git rebase?
>
> Reordering and squashing can be done via rebase -i, but it's basically just
> the practice of "prettying" your changes.
> http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ has more
> prose on the subject.

Thanks Boyd.  I made the mistake of using git revert HEAD thinking it
would just delete that last revision, but it instead added a new
revision that acted as if it just reversed the changes.

What I really want to do is simply replace the last two commits on the
branch with one commit, so that when I make my patch it will be just
the full set of changes and not a lot of noise. Is there a way to do
that? (note: I did try the git merge --squash command but it just
showed me the usage, as I was on my bg/no-progress branch).  Note that
I know that I would not be able to do this once some of my changes had
merged upstream.

Thanks,
bgoodr

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Junio C Hamano]

Brent Goodrick <bgoodr@gmail.com> writes:

> What I really want to do is simply replace the last two commits on the
> branch with one commit, so that when I make my patch it will be just
> the full set of changes and not a lot of noise. Is there a way to do
> that? (note: I did try the git merge --squash command but it just
> showed me the usage, as I was on my bg/no-progress branch).  Note that
> I know that I would not be able to do this once some of my changes had
> merged upstream.

Suppose you have this topology.  You forked and built 2 commits, while the
upstream advanced its tip (or not).

                 1--2 your commits (master)
                /
	---o---o---o upstream (origin)

1. Using "rebase -i"

    ... on your "master"
    $ git rebase -i origin
    ... will give you an insn sheet for interactive rebase to edit.
    ... you will see something like:

	pick xxxxxx title of commit 1
       	pick yyyyyy title of commit 2

    ... edit the second "pick" to "squash", save and exit the editor.
    ... You are telling it to "first cherry-pick my 1, and then squash my
    ... 2 on top of it.

    ... it will do as it is told, and will give you another editor, with
    ... messages from both commits in it.  Edit to formulate a log message
    ... suitable for the combined commit, save and exit the editor.

   You will end up with:

	---o---o---o---X

   where rightmost 'o' is still origin, X is your two commits squashed
   into one.

2. Using "mrege -s squash"

    ... on your "master"
    $ git merge --squash origin
    ... this will stop without creating a commit.  Then you would
    $ git commit
    ... and the editor will give you the log message from all the
    ... commits on the branch you just merged.  Come up with a single
    ... log message to describe all, save and exit the editor.

   You will end up with:

	---o---o---o---X

   where rightmost 'o' is still origin, X is your two commits squashed
   into one.

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Brent Goodrick]

My changes should live on my bg/no-progress branch until which time as
they are accepted so I don't want them plunked down onto the
originating branch quite yet (rebasing is fine, but I don't want to
disturb that originating branch).

To explain what I mean: Yesterday, I had this configuration on my
bg/no-progress branch:

             A---B---C---D (bg/no-progress)
            /
----1-----2----3----4 (master)

B C and D commits are noisy,
fix-the-white-space-and-conform-to-coding-guidelines type commits. I
want to collapse A through D into one commit called E on that branch
so that I can run git format-patch -M on the result and provide a nice
patch email. I would end up with:

             E (bg/no-progress)
            /
----1-----2----3----4 (master)

I do have a way to do that, but it is cumbersome: I ended up doing:

1. git diff -p >saved_patch of A through D (I don't recall the exact
git diff command).
2. Use a form of git rebase similar to "git rebase --onto topicA~5
topicA~3 topicA" as explained in the git-rebase man page
3. Use git apply saved_patch
4. Reapply the commit with a new commit message
5. Use git format-patch -M --stdout .... > mail.txt

Again, all while staying on the bg/no-progress branch.

But that was tricky (at least the git rebase command was). Is there a
shorter, cleaner way to compress multiple commits on a given branch
using one rebase command and not saving off a patch?

Thanks,
bg


On Sun, Feb 8, 2009 at 8:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Brent Goodrick <bgoodr@gmail.com> writes:
>
> > What I really want to do is simply replace the last two commits on the
> > branch with one commit, so that when I make my patch it will be just
> > the full set of changes and not a lot of noise. Is there a way to do
> > that? (note: I did try the git merge --squash command but it just
> > showed me the usage, as I was on my bg/no-progress branch).  Note that
> > I know that I would not be able to do this once some of my changes had
> > merged upstream.
>
> Suppose you have this topology.  You forked and built 2 commits, while the
> upstream advanced its tip (or not).
>
>                 1--2 your commits (master)
>                /
>        ---o---o---o upstream (origin)
>
> 1. Using "rebase -i"
>
>    ... on your "master"
>    $ git rebase -i origin
>    ... will give you an insn sheet for interactive rebase to edit.
>    ... you will see something like:
>
>        pick xxxxxx title of commit 1
>        pick yyyyyy title of commit 2
>
>    ... edit the second "pick" to "squash", save and exit the editor.
>    ... You are telling it to "first cherry-pick my 1, and then squash my
>    ... 2 on top of it.
>
>    ... it will do as it is told, and will give you another editor, with
>    ... messages from both commits in it.  Edit to formulate a log message
>    ... suitable for the combined commit, save and exit the editor.
>
>   You will end up with:
>
>        ---o---o---o---X
>
>   where rightmost 'o' is still origin, X is your two commits squashed
>   into one.
>
> 2. Using "mrege -s squash"
>
>    ... on your "master"
>    $ git merge --squash origin
>    ... this will stop without creating a commit.  Then you would
>    $ git commit
>    ... and the editor will give you the log message from all the
>    ... commits on the branch you just merged.  Come up with a single
>    ... log message to describe all, save and exit the editor.
>
>   You will end up with:
>
>        ---o---o---o---X
>
>   where rightmost 'o' is still origin, X is your two commits squashed
>   into one.

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Monday 09 February 2009 15:59:40 Brent Goodrick wrote:
> To explain what I mean: Yesterday, I had this configuration on my
> bg/no-progress branch:
>
>              A---B---C---D (bg/no-progress)
>             /
> ----1-----2----3----4 (master)
>
> B C and D commits are noisy,
> fix-the-white-space-and-conform-to-coding-guidelines type commits. I
> want to collapse A through D into one commit called E on that branch
> so that I can run git format-patch -M on the result and provide a nice
> patch email. I would end up with:
>
>              E (bg/no-progress)
>             /
> ----1-----2----3----4 (master)

Here's my way to do that:
git rebase -i $(git merge-base master bg/noprogress) bg/no-progress
# Editor opens
# Change "pick" -> "squash" for commits B, C, and D.
# rebase runs
# Maybe resolve conflicts

If you are willing to have:
             E (bg/no-progress)
            /
--1--2--3--4 (master)

at the end, it's a little bit simpler:
git rebase -i master bg/no-progress
# All the rest the same.
-- 
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Trouble testing out a patch on a branch new scratch git.git repository

[Sitaram Chamarty]

On 2009-02-09, Brent Goodrick <bgoodr@gmail.com> wrote:
> To explain what I mean: Yesterday, I had this configuration on my
> bg/no-progress branch:
>
>              A---B---C---D (bg/no-progress)
>             /
> ----1-----2----3----4 (master)
>
> B C and D commits are noisy,
> fix-the-white-space-and-conform-to-coding-guidelines type commits. I
> want to collapse A through D into one commit called E on that branch
> so that I can run git format-patch -M on the result and provide a nice
> patch email. I would end up with:
>
>              E (bg/no-progress)
>             /
> ----1-----2----3----4 (master)

You want to squash the last 4 patches on the current branch
into one?

The fastest way, if you don't mind re-typing the commit
message for the combined commit, is this:

    git reset --soft HEAD~4
    git commit

A kinder, gentler, way is this:

(1) type in 'git rebase -i HEAD~4'

(2) In the editor that pops up, change the 'pick' on all but
    the first entry to 'squash' or just 's' and save the
    file.

    There won't be any conflicts in this scenario, so don't
    worry about that.

(3) Another editor will pop up showing all 4 commit messages
    in one edit buffer -- combine the various commit
    messages however you wish and save the file.

Done :-)

-- 
Sitaram