{"thread":{"id":"17660","subject":"Trouble testing out a patch on a branch new scratch git.git repository","startedAt":"2009-02-08T20:56:48Z","lastAt":"2009-02-10T05:32:09Z","messageCount":9,"participants":["Brent Goodrick","Junio C Hamano","Boyd Stephen Smith Jr.","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"103784","messageId":"e38bce640902081256j3cd84aadn2f0cc863cfca904d@mail.gmail.com","threadId":"17660","inReplyTo":null,"subject":"Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-08T20:56:48Z","receivedAt":"2009-02-08T20:56:48Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"Hi,\n\nI have a patch ready for my new --progress switch, and am trying to\nprepare the PATCH/RFC email.  I am having problems testing out the\npatch with get-am.  I suspect if my patch is going to have any hope at\nbeing applied, I have to figure out what is causing git am to fail to\napply the change.\n\nSo, here is what I think happened in my repo:\n\n1. A while ago, I made some changes and began testing them out.\n2. I committed the change into the first commit (see\ne802880bb89524b1f70132f1ca0716624788db3f below)\n3. Unfortunately, I then stumbled across the coding guidelines, and\nthen discovered that my if statements had too many curly braces, and\nfixed that with another commit (but I doubt that is the problem here)\n4. I did a git pull origin and found a conflict in a file I had\nchanged in the first commit above into cache.h (I had inserted a line\nright where someone else had inserted a line). I probably should have\nstopped right then and there and not gone ahead with the merge, but do\nsomething different (but if so, then what should I have done instead?)\n:)\n5. I manually edited cache.h to resolve the conflict, and then\nexecuted \"git add cache.h\"\n6. Committed the merge with git commit\n(78f968776048d6dace68e6367fbd4e7d81041fef below)\n7. Ran \"git format-patch -M --stdout origin/master\" and dumped it to a file.\n8. Created a new scratch repository and tried to apply the patch with\nthis script:\n\n#!/bin/sh\nset -x\nset -e\ncd /tmp\nrm -rf checkout_test\nmkdir checkout_test\ncd checkout_test\ngit clone git://git.kernel.org/pub/scm/git/git.git\ncd git\ngit am /tmp/patch\n\nAnd the git am command failed on the cache.h file that had the\nconflict I manually fixed. But note also a failure to apply the change\nto git.c too (which, BTW, did not require any man-handling during the\nmerge). The output of that git am command is:\n\ngit am /tmp/patch\nApplying: Add progress options\nerror: patch failed: cache.h:371\nerror: cache.h: patch does not apply\nerror: patch failed: git.c:4\nerror: git.c: patch does not apply\nPatch failed at 0001 Add progress options\nWhen you have resolved this problem run \"git am --resolved\".\nIf you would prefer to skip this patch, instead run \"git am --skip\".\nTo restore the original branch and stop patching run \"git am --abort\".\n\nHere is a trimmed down git log output showing where my commits stand\nw.r.t. the merge and the other commits in between (see <snip> line):\n\n\ngit log -100\ncommit 78f968776048d6dace68e6367fbd4e7d81041fef\nMerge: 44b1f2e... 621f1b4...\nAuthor: Brent Goodrick <brentg@hungover.brentg.com>\nDate:   Sun Feb 8 11:03:13 2009 -0800\n\n    Merge branch 'master' of git://git.kernel.org/pub/scm/git/git\n\n    Conflicts:\n    \tcache.h\n\ncommit 44b1f2ecd2dc19ccb04660a730814c7b07b6d838\nAuthor: Brent Goodrick <brentg@hungover.brentg.com>\nDate:   Sun Feb 8 10:53:33 2009 -0800\n\n    Conform to git coding standards\n\n    This is a cosmetic change to remove curly braces used if statements\n    that have only one statement in the true or false clauses.\n\n<snip>... many other commits here </snip>\n\ncommit e802880bb89524b1f70132f1ca0716624788db3f\nAuthor: Brent Goodrick <brentg@hungover.brentg.com>\nDate:   Mon Feb 2 19:34:56 2009 -0800\n\n    Add progress options\n\n    Add --progress, --no-progress, and --progress-verbose options, which\n    correspond to the GIT_PROGRESS environment variable setting of \"1\",\n    \"0\", and \"verbose\", respectively.\n\n    Signed-off-by: Brent Goodrick <bgoodr@gmail.com>\n\n\nAny ideas as to what I need to do next here?  Even if this patch gets\nrejected from being put into git.git, I still would like to know what\nI did wrong.\n\nThanks,\nbgoodr\n\nP.S., For everyone's reference, the rest of this message contains a\nraw dump of the \"git format-patch -M --stdout origin/master\" command\nshowing my work in progress that I would like to somehow reform into\nan eventual PATCH/RFC email.\n\nP.S.S. Please also reply while CCing me as I have hence had to take\nmyself off of the mailing list (I can't process 100+ messages per\nday). 8)\n\n\n\n\n\n--- cut here ---\nFrom e802880bb89524b1f70132f1ca0716624788db3f Mon Sep 17 00:00:00 2001\nFrom: Brent Goodrick <brentg@hungover.brentg.com>\nDate: Mon, 2 Feb 2009 19:34:56 -0800\nSubject: [PATCH 1/2] Add progress options\n\nAdd --progress, --no-progress, and --progress-verbose options, which\ncorrespond to the GIT_PROGRESS environment variable setting of \"1\",\n\"0\", and \"verbose\", respectively.\n\nSigned-off-by: Brent Goodrick <bgoodr@gmail.com>\n---\n Documentation/git.txt                  |   15 +++++++++++++\n builtin-pack-objects.c                 |    2 +-\n cache.h                                |    1 +\n contrib/completion/git-completion.bash |    3 ++\n git.c                                  |    8 ++++++-\n progress.c                             |   33 ++++++++++++++++++++++++----\n sideband.c                             |   36 ++++++++++++++++++++++++++++---\n 7 files changed, 87 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 17dc8b2..158b313 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -11,6 +11,7 @@ SYNOPSIS\n [verse]\n 'git' [--version] [--exec-path[=GIT_EXEC_PATH]]\n     [-p|--paginate|--no-pager]\n+    [--progress|--no-progress|--progress-verbose]\n     [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n     [--help] COMMAND [ARGS]\n\n@@ -176,6 +177,20 @@ help ...`.\n --no-pager::\n \tDo not pipe git output into a pager.\n\n+--progress::\n+\tShow progress for long-running processing. This corresponds to\n+\tsetting the GIT_PROGRESS environment variable to 1. This is\n+\tthe default.\n+\n+--no-progress::\n+\tInstead of showing intermediate progress, just show\n+\tcompletion of major steps in processing. This corresponds to\n+\tsetting the GIT_PROGRESS environment variable to 0.\n+\n+--progress-verbose::\n+\tEnable progress and show intermediate progress results as one\n+\tper line.\n+\n --git-dir=<path>::\n \tSet the path to the repository. This can also be controlled by\n \tsetting the GIT_DIR environment variable. It can be an absolute\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex cb51916..7ba5268 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -81,7 +81,7 @@ static int depth = 50;\n static int delta_search_threads;\n static int pack_to_stdout;\n static int num_preferred_base;\n-static struct progress *progress_state;\n+static struct progress *progress_state = NULL;\n static int pack_compression_level = Z_DEFAULT_COMPRESSION;\n static int pack_compression_seen;\n\ndiff --git a/cache.h b/cache.h\nindex 8d965b8..ecfda5a 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -371,6 +371,7 @@ static inline enum object_type\nobject_type(unsigned int mode)\n #define GITATTRIBUTES_FILE \".gitattributes\"\n #define INFOATTRIBUTES_FILE \"info/attributes\"\n #define ATTRIBUTE_MACRO_PREFIX \"[attr]\"\n+#define GIT_PROGRESS_ENVIRONMENT \"GIT_PROGRESS\"\n\n extern int is_bare_repository_cfg;\n extern int is_bare_repository(void);\ndiff --git a/contrib/completion/git-completion.bash\nb/contrib/completion/git-completion.bash\nindex 81f70ec..a555241 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1701,6 +1701,9 @@ _git ()\n \t\t--*)   __gitcomp \"\n \t\t\t--paginate\n \t\t\t--no-pager\n+\t\t\t--progress\n+\t\t\t--no-progress\n+\t\t\t--progress-verbose\n \t\t\t--git-dir=\n \t\t\t--bare\n \t\t\t--version\ndiff --git a/git.c b/git.c\nindex ecc8fad..166a201 100644\n--- a/git.c\n+++ b/git.c\n@@ -4,7 +4,7 @@\n #include \"quote.h\"\n\n const char git_usage_string[] =\n-\t\"git [--version] [--exec-path[=GIT_EXEC_PATH]]\n[-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR]\n[--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]\";\n+\t\"git [--version] [--exec-path[=GIT_EXEC_PATH]]\n[-p|--paginate|--no-pager]\n[--progress|--no-progress|--progress-verbose] [--bare]\n[--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND\n[ARGS]\";\n\n const char git_more_info_string[] =\n \t\"See 'git help COMMAND' for more information on a specific command.\";\n@@ -115,6 +115,12 @@ static int handle_options(const char*** argv,\nint* argc, int* envchanged)\n \t\t\tsetenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);\n \t\t\tif (envchanged)\n \t\t\t\t*envchanged = 1;\n+\t\t} else if (!strcmp(cmd, \"--progress\")) {\n+\t\t\tsetenv(GIT_PROGRESS_ENVIRONMENT, \"1\", 1);\n+\t\t} else if (!strcmp(cmd, \"--no-progress\")) {\n+\t\t\tsetenv(GIT_PROGRESS_ENVIRONMENT, \"0\", 1);\n+\t\t} else if (!strcmp(cmd, \"--progress-verbose\")) {\n+\t\t\tsetenv(GIT_PROGRESS_ENVIRONMENT, \"verbose\", 1);\n \t\t} else {\n \t\t\tfprintf(stderr, \"Unknown option: %s\\n\", cmd);\n \t\t\tusage(git_usage_string);\ndiff --git a/progress.c b/progress.c\nindex 55a8687..f92eaaa 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -10,6 +10,7 @@\n\n #include \"git-compat-util.h\"\n #include \"progress.h\"\n+#include \"cache.h\"\n\n #define TP_IDX_MAX      8\n\n@@ -36,6 +37,8 @@ struct progress {\n };\n\n static volatile sig_atomic_t progress_update;\n+static int show_progress = 1;\n+static int show_progress_verbose = 0;\n\n static void progress_interval(int signum)\n {\n@@ -90,15 +93,20 @@ static int display(struct progress *progress,\nunsigned n, const char *done)\n\n \tprogress->last_value = n;\n \ttp = (progress->throughput) ? progress->throughput->display : \"\";\n-\teol = done ? done : \"   \\r\";\n+\teol = done ? done : (show_progress_verbose ? \"   \\n\" : \"   \\r\");\n \tif (progress->total) {\n \t\tunsigned percent = n * 100 / progress->total;\n \t\tif (percent != progress->last_percent || progress_update) {\n \t\t\tprogress->last_percent = percent;\n-\t\t\tfprintf(stderr, \"%s: %3u%% (%u/%u)%s%s\",\n-\t\t\t\tprogress->title, percent, n,\n-\t\t\t\tprogress->total, tp, eol);\n-\t\t\tfflush(stderr);\n+\t\t\t/* Show progress everytime if specified. But if progress is turned\n+\t\t\t * off, only show the last message (when done is non-NULL) as a\n+\t\t\t * summary: */\n+\t\t\tif (show_progress || done) {\n+\t\t\t\tfprintf(stderr, \"%s: %3u%% (%u/%u)%s%s\",\n+\t\t\t\t\t\tprogress->title, percent, n,\n+\t\t\t\t\t\tprogress->total, tp, eol);\n+\t\t\t\tfflush(stderr);\n+\t\t\t}\n \t\t\tprogress_update = 0;\n \t\t\treturn 1;\n \t\t}\n@@ -206,6 +214,21 @@ struct progress *start_progress_delay(const char\n*title, unsigned total,\n \t\t\t\t       unsigned percent_treshold, unsigned delay)\n {\n \tstruct progress *progress = malloc(sizeof(*progress));\n+\tconst char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);\n+\tif (show_progress_env) {\n+\t\tif (!strcmp(show_progress_env, \"true\")) {\n+\t\t\tshow_progress_env = \"1\";\n+\t\t}\n+\t\tif (!strcmp(show_progress_env, \"false\")) {\n+\t\t\tshow_progress_env = \"0\";\n+\t\t}\n+\t\tif (!strcmp(show_progress_env, \"verbose\")) {\n+\t\t\t/* Show progress, but use LF codes in the output and not CR codes: */\n+\t\t\tshow_progress_verbose = 1;\n+\t\t} else if (!strcmp(show_progress_env, \"0\")) {\n+\t\t\tshow_progress = 0;\n+\t\t}\n+\t}\n \tif (!progress) {\n \t\t/* unlikely, but here's a good fallback */\n \t\tfprintf(stderr, \"%s...\\n\", title);\ndiff --git a/sideband.c b/sideband.c\nindex cca3360..21766a4 100644\n--- a/sideband.c\n+++ b/sideband.c\n@@ -1,5 +1,6 @@\n #include \"pkt-line.h\"\n #include \"sideband.h\"\n+#include \"cache.h\"\n\n /*\n  * Receive multiplexed output stream over git native protocol.\n@@ -26,7 +27,24 @@ int recv_sideband(const char *me, int in_stream,\nint out, int err)\n \tchar buf[LARGE_PACKET_MAX + 2*FIX_SIZE];\n \tchar *suffix, *term;\n \tint skip_pf = 0;\n-\n+\tint show_progress = 1;\n+\tint show_progress_verbose = 0;\n+\tconst char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);\n+\tif (show_progress_env) {\n+\t\tif (!strcmp(show_progress_env, \"true\")) {\n+\t\t\tshow_progress_env = \"1\";\n+\t\t}\n+\t\tif (!strcmp(show_progress_env, \"false\")) {\n+\t\t\tshow_progress_env = \"0\";\n+\t\t}\n+\t\tif (!strcmp(show_progress_env, \"0\")) {\n+\t\t\tshow_progress = 0;\n+\t\t}\n+\t\telse if (!strcmp(show_progress_env, \"verbose\")) {\n+\t\t\t/* Show progress, but use LF codes in the output and not CR codes: */\n+\t\t\tshow_progress_verbose = 1;\n+\t\t}\n+\t}\n \tmemcpy(buf, PREFIX, pf);\n \tterm = getenv(\"TERM\");\n \tif (term && strcmp(term, \"dumb\"))\n@@ -58,6 +76,7 @@ int recv_sideband(const char *me, int in_stream, int\nout, int err)\n \t\t\tdo {\n \t\t\t\tchar *b = buf;\n \t\t\t\tint brk = 0;\n+\t\t\t\tint cr = 0;\n\n \t\t\t\t/*\n \t\t\t\t * If the last buffer didn't end with a line\n@@ -78,9 +97,15 @@ int recv_sideband(const char *me, int in_stream,\nint out, int err)\n \t\t\t\t\t\tbrk = 0;\n \t\t\t\t\t\tbreak;\n \t\t\t\t\t}\n-\t\t\t\t\tif (b[brk-1] == '\\n' ||\n-\t\t\t\t\t    b[brk-1] == '\\r')\n+\t\t\t\t\tif (b[brk-1] == '\\n') {\n+\t\t\t\t\t\tbreak;\n+\t\t\t\t\t} else if (b[brk-1] == '\\r') {\n+\t\t\t\t\t\tif (show_progress_verbose) {\n+\t\t\t\t\t\t\tb[brk-1] = '\\n';\n+\t\t\t\t\t\t}\n+\t\t\t\t\t\tcr = 1;\n \t\t\t\t\t\tbreak;\n+\t\t\t\t\t}\n \t\t\t\t}\n\n \t\t\t\t/*\n@@ -95,7 +120,10 @@ int recv_sideband(const char *me, int in_stream,\nint out, int err)\n \t\t\t\t\tmemcpy(save, b + brk, sf);\n \t\t\t\t\tb[brk + sf - 1] = b[brk - 1];\n \t\t\t\t\tmemcpy(b + brk - 1, suffix, sf);\n-\t\t\t\t\tsafe_write(err, b, brk + sf);\n+\t\t\t\t\t/* Progress messages are those that end in CR codes */\n+\t\t\t\t\tif (show_progress || !cr) {\n+\t\t\t\t\t\tsafe_write(err, b, brk + sf);\n+\t\t\t\t\t}\n \t\t\t\t\tmemcpy(b + brk, save, sf);\n \t\t\t\t\tlen -= brk;\n \t\t\t\t} else {\n-- \n1.6.2.rc0.3.g78f96\n\n\n>From 44b1f2ecd2dc19ccb04660a730814c7b07b6d838 Mon Sep 17 00:00:00 2001\nFrom: Brent Goodrick <brentg@hungover.brentg.com>\nDate: Sun, 8 Feb 2009 10:53:33 -0800\nSubject: [PATCH 2/2] Conform to git coding standards\n\nThis is a cosmetic change to remove curly braces in if statements\nthat have only one statement in the true or false clauses.\n---\n progress.c |   14 ++++++--------\n sideband.c |   23 ++++++++---------------\n 2 files changed, 14 insertions(+), 23 deletions(-)\n\ndiff --git a/progress.c b/progress.c\nindex f92eaaa..c96d594 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -93,6 +93,8 @@ static int display(struct progress *progress,\nunsigned n, const char *done)\n\n \tprogress->last_value = n;\n \ttp = (progress->throughput) ? progress->throughput->display : \"\";\n+\t/* When show_progress_verbose is true, put each progress message on a\n+\t * separate line: */\n \teol = done ? done : (show_progress_verbose ? \"   \\n\" : \"   \\r\");\n \tif (progress->total) {\n \t\tunsigned percent = n * 100 / progress->total;\n@@ -216,18 +218,14 @@ struct progress *start_progress_delay(const char\n*title, unsigned total,\n \tstruct progress *progress = malloc(sizeof(*progress));\n \tconst char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);\n \tif (show_progress_env) {\n-\t\tif (!strcmp(show_progress_env, \"true\")) {\n+\t\tif (!strcmp(show_progress_env, \"true\"))\n \t\t\tshow_progress_env = \"1\";\n-\t\t}\n-\t\tif (!strcmp(show_progress_env, \"false\")) {\n+\t\tif (!strcmp(show_progress_env, \"false\"))\n \t\t\tshow_progress_env = \"0\";\n-\t\t}\n-\t\tif (!strcmp(show_progress_env, \"verbose\")) {\n-\t\t\t/* Show progress, but use LF codes in the output and not CR codes: */\n+\t\tif (!strcmp(show_progress_env, \"verbose\"))\n \t\t\tshow_progress_verbose = 1;\n-\t\t} else if (!strcmp(show_progress_env, \"0\")) {\n+\t\telse if (!strcmp(show_progress_env, \"0\"))\n \t\t\tshow_progress = 0;\n-\t\t}\n \t}\n \tif (!progress) {\n \t\t/* unlikely, but here's a good fallback */\ndiff --git a/sideband.c b/sideband.c\nindex 21766a4..4bfb206 100644\n--- a/sideband.c\n+++ b/sideband.c\n@@ -31,19 +31,14 @@ int recv_sideband(const char *me, int in_stream,\nint out, int err)\n \tint show_progress_verbose = 0;\n \tconst char * show_progress_env = getenv(GIT_PROGRESS_ENVIRONMENT);\n \tif (show_progress_env) {\n-\t\tif (!strcmp(show_progress_env, \"true\")) {\n+\t\tif (!strcmp(show_progress_env, \"true\"))\n \t\t\tshow_progress_env = \"1\";\n-\t\t}\n-\t\tif (!strcmp(show_progress_env, \"false\")) {\n+\t\tif (!strcmp(show_progress_env, \"false\"))\n \t\t\tshow_progress_env = \"0\";\n-\t\t}\n-\t\tif (!strcmp(show_progress_env, \"0\")) {\n+\t\tif (!strcmp(show_progress_env, \"0\"))\n \t\t\tshow_progress = 0;\n-\t\t}\n-\t\telse if (!strcmp(show_progress_env, \"verbose\")) {\n-\t\t\t/* Show progress, but use LF codes in the output and not CR codes: */\n+\t\telse if (!strcmp(show_progress_env, \"verbose\"))\n \t\t\tshow_progress_verbose = 1;\n-\t\t}\n \t}\n \tmemcpy(buf, PREFIX, pf);\n \tterm = getenv(\"TERM\");\n@@ -97,12 +92,11 @@ int recv_sideband(const char *me, int in_stream,\nint out, int err)\n \t\t\t\t\t\tbrk = 0;\n \t\t\t\t\t\tbreak;\n \t\t\t\t\t}\n-\t\t\t\t\tif (b[brk-1] == '\\n') {\n+\t\t\t\t\tif (b[brk-1] == '\\n')\n \t\t\t\t\t\tbreak;\n-\t\t\t\t\t} else if (b[brk-1] == '\\r') {\n-\t\t\t\t\t\tif (show_progress_verbose) {\n+\t\t\t\t\telse if (b[brk-1] == '\\r') {\n+\t\t\t\t\t\tif (show_progress_verbose)\n \t\t\t\t\t\t\tb[brk-1] = '\\n';\n-\t\t\t\t\t\t}\n \t\t\t\t\t\tcr = 1;\n \t\t\t\t\t\tbreak;\n \t\t\t\t\t}\n@@ -121,9 +115,8 @@ int recv_sideband(const char *me, int in_stream,\nint out, int err)\n \t\t\t\t\tb[brk + sf - 1] = b[brk - 1];\n \t\t\t\t\tmemcpy(b + brk - 1, suffix, sf);\n \t\t\t\t\t/* Progress messages are those that end in CR codes */\n-\t\t\t\t\tif (show_progress || !cr) {\n+\t\t\t\t\tif (show_progress || !cr)\n \t\t\t\t\t\tsafe_write(err, b, brk + sf);\n-\t\t\t\t\t}\n \t\t\t\t\tmemcpy(b + brk, save, sf);\n \t\t\t\t\tlen -= brk;\n \t\t\t\t} else {\n-- \n1.6.2.rc0.3.g78f96\n--- cut here ---\n"},{"id":"103786","messageId":"7vy6wgwqjp.fsf@gitster.siamese.dyndns.org","threadId":"17660","inReplyTo":"e38bce640902081256j3cd84aadn2f0cc863cfca904d@mail.gmail.com","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-08T21:46:02Z","receivedAt":"2009-02-08T21:46:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brent Goodrick <bgoodr@gmail.com> writes:\n\n> So, here is what I think happened in my repo:\n>\n> 1. A while ago, I made some changes and began testing them out.\n> 2. I committed the change into the first commit (see\n> e802880bb89524b1f70132f1ca0716624788db3f below)\n> 3. Unfortunately, I then stumbled across the coding guidelines, and\n> then discovered that my if statements had too many curly braces, and\n> fixed that with another commit (but I doubt that is the problem here)\n> 4. I did a git pull origin and found a conflict in a file I had\n> changed in the first commit above into cache.h (I had inserted a line\n> right where someone else had inserted a line). I probably should have\n> stopped right then and there and not gone ahead with the merge, but do\n> something different (but if so, then what should I have done instead?)\n> :)\n\nYour work is about adding this new feature.  Use a topic branch.\n\nNow what is that topic branch is for?  Yes, it is about adding this new\nfeature, and nothing else.  Don't pull other people's changes made on my\ntree into it.  That will make your topic branch \"one new feature and\neverything else\" and useless as a topic branch.\n\nWhat would make your life easier would be:\n\n\t$ git pull ;# to get up to date with me on your master branch\n        $ git checkout -b bg/no-progress origin/master\n        ... work on e802880 ...\n\t... test it ...\n        $ git commit ;# record that on bg/no-progress topic\n\n        $ git checkout master\n        $ git merge bg/no-progress\n        ... test the result of the merge ...\n\n        $ git checkout bg/no-progress\n        ... work on style fix ...\n        ... test it ...\n        $ git commit ;# again record it on bg/no-progress topic\n                        \n        $ git checkout master\n        $ git merge bg/no-progress\n        ... test the result of the merge ...\n\n        $ git pull ;# to get up to date with me\n        ... resolve conflicts ...\n\nThen after you are convinced that everything on bg/no-progress is worthy\nof sending to the list [*A*], but its tip is stale because things have\nprogressed on my end, you can do this:\n\n\t$ git checkout bg/no-progress\n        $ git rebase origin/master\t;# and rebase to the upstream\n        \nwhich may conflict again (but that would be the same conflict you saw with\nyour \"git pull\" from me, and rerere may remember it).\n\nReview and test the result and then:\n\n\t$ git format-patch origin/master\n\nThere can be variants in the last few steps.  For example, your commits on\nbg/no-progress may be full of \"Oops, this is to fix my own mistake made in\nearlier commits since I forked from the upstream\".  You would not want to\nhave them in your submission (instead, you would want to pretend as if you\nnever made these mistakes in the first place).  For that, you may want to\ndo, after you feel the tip of bg/no-progress is in a good shape at point\n*A* above:\n\n\t$ git checkout bg/no-progress\n        $ git rebase -i origin/master\t;# and rebase to the upstream\n        \nand reorder, squash, and fix them.\n\nAlso you may feel that at point [*A*] what you have is very precious and\nyou would not want yourself breaking it by the final rebase (which is a\nvery reasonable thing to feel).  In such a case, the final rewrite could\nbe:\n\n\t$ git checkout bg/no-progress^0\n        $ git rebase -i origin/master\t;# and rebase to the upstream\n\t... test and review the result.\n        ... convince yourself it is indeed better than\n        ... what you earlier thought to be \"very precious\".\n        ... and then finally\n\t$ git branch -f bg/no-progress\n\t$ git format-patch origin/master ;# send this\n\nAnd to finish it off, you may do:\n\n\t$ git checkout master\n        $ git merge --ours bg/no-progress\n\nThe above is a suggestion based on a design to allow you keep sticking to\nyour merge based workflow as much as possible, but you could instead\nchoose to keep rebasing.  I have some observations at the end of\n\n    http://gitster.livejournal.com/24080.html\n\ncomparing the merge based workflow and the rebase based one.\n"},{"id":"103796","messageId":"e38bce640902081613v3e93c1e3g716118c38ce861ab@mail.gmail.com","threadId":"17660","inReplyTo":"7vy6wgwqjp.fsf@gitster.siamese.dyndns.org","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-09T00:13:00Z","receivedAt":"2009-02-09T00:13:00Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"Much thanks for your extensive writeup, Junio! I will try to follow your\nadvice on a brand new git clone'ed repository and just reapply my\nchanges there into the topic branch (makes sense for these small sets\nof changes; but not for larger sets ... read my comments below).\n\nBut for my education, I've interspersed below some questions where I\nam still misunderstanding the situation or intent behind your\nrecommendation:\n\nOn Sun, Feb 8, 2009 at 1:46 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Now what is that topic branch is for?  Yes, it is about adding this new\n> feature, and nothing else.  Don't pull other people's changes made on my\n> tree into it.  That will make your topic branch \"one new feature and\n> everything else\" and useless as a topic branch.\n\nFair enough, but I don't understand what is referred to by \"my tree\" above?\n\n>\n> What would make your life easier would be:\n>\n>        $ git pull ;# to get up to date with me on your master branch\n\nI am concluding that I need to throw away (well, saving it off first) my\ncurrent repo and then do the git pull only from within a fresh git clone?\n\n>        $ git checkout -b bg/no-progress origin/master\n>        ... work on e802880 ...\n>        ... test it ...\n>        $ git commit ;# record that on bg/no-progress topic\n>\n>        $ git checkout master\n>        $ git merge bg/no-progress\n>        ... test the result of the merge ...\n\nRefering to that git merge bg/no-progress command above. You said not\nto merge from master to bg/no-progress at this early stage, which\nmakes sense, but now you are going in the reverse via master <--\nbg/no-progress. And here I do not see a commit, but that command is\nfollowed straight way with a \"git checkout bg/no-progress\" below.  Is\nthat just for testing the merge with the intent of just throwing the\nchanges away?  In other words, is this next \"git checkout\nbg/no-progress\" command going to silently throw away the \"git merge\nbg/progress\" step at this point?\n\n>\n>        $ git checkout bg/no-progress\n>        ... work on style fix ...\n>        ... test it ...\n>        $ git commit ;# again record it on bg/no-progress topic\n>\n>        $ git checkout master\n>        $ git merge bg/no-progress\n>        ... test the result of the merge ...\n>\n>        $ git pull ;# to get up to date with me\n>        ... resolve conflicts ...\n>\n> Then after you are convinced that everything on bg/no-progress is worthy\n> of sending to the list [*A*], but its tip is stale because things have\n> progressed on my end, you can do this:\n\nSimilar question: Is this next \"git checkout bg/no-progress\" below\ngoing to loose the conflicts I would have just resolved above\n(referring to the most recent \"... resolve conflicts ...\" line above)?\n\n>\n>        $ git checkout bg/no-progress\n>        $ git rebase origin/master      ;# and rebase to the upstream\n>\n> which may conflict again (but that would be the same conflict you saw with\n> your \"git pull\" from me, and rerere may remember it).\n\nWhat does \"rerere\" mean, or is that a typo?\n\n>\n> Review and test the result and then:\n>\n>        $ git format-patch origin/master\n>\n> There can be variants in the last few steps.  For example, your commits on\n> bg/no-progress may be full of \"Oops, this is to fix my own mistake made in\n> earlier commits since I forked from the upstream\".  You would not want to\n> have them in your submission (instead, you would want to pretend as if you\n> never made these mistakes in the first place).  For that, you may want to\n> do, after you feel the tip of bg/no-progress is in a good shape at point\n> *A* above:\n>\n>        $ git checkout bg/no-progress\n>        $ git rebase -i origin/master   ;# and rebase to the upstream\n>\n> and reorder, squash, and fix them.\n\nWhat do you mean by \"reorder, squash\" mean here? Is that something\nthat is done as a part of the -i option to git rebase?\n\n>\n> Also you may feel that at point [*A*] what you have is very precious and\n> you would not want yourself breaking it by the final rebase (which is a\n> very reasonable thing to feel).  In such a case, the final rewrite could\n> be:\n>\n>        $ git checkout bg/no-progress^0\n>        $ git rebase -i origin/master   ;# and rebase to the upstream\n>        ... test and review the result.\n>        ... convince yourself it is indeed better than\n>        ... what you earlier thought to be \"very precious\".\n>        ... and then finally\n>        $ git branch -f bg/no-progress\n>        $ git format-patch origin/master ;# send this\n\nWhat is the significance of the ^0 construct tacked onto the end of\n\"bg/no-progress\" at this point, versus just \"git checkout\nbg/no-progress\" without the \"^0\"?\n\nI made the mistake of reading the \"SPECIFYING REVISIONS\" section in\ngit-rev-parse(1) manual, which states:\n\n    A suffix ^ to a revision parameter means the first parent of that\n    commit object. ^<n> means the <n>th parent (i.e. rev^ is\n    equivalent to rev^1). As a special rule, rev^0 means the commit\n    itself and is used when rev is the object name of a tag object\n    that refers to a commit object.\n\nI'm having a hard time translating \"tag object\" and \"commit object\"\ninto things I understand w.r.t. the repo I see from my end.\n\n>\n> And to finish it off, you may do:\n>\n>        $ git checkout master\n>        $ git merge --ours bg/no-progress\n\nThe --ours option to git-merge does not seem to be documented (at\nleast it is not in the user manual). There is a --ours option\nindicated in the git-checkout man page.\n\n>\n> The above is a suggestion based on a design to allow you keep sticking to\n> your merge based workflow as much as possible, but you could instead\n> choose to keep rebasing.  I have some observations at the end of\n>\n>    http://gitster.livejournal.com/24080.html\n>\n> comparing the merge based workflow and the rebase based one.\n>\n\nThe rebase flow would work better for this given that I do eventually\nwant to send my changes upstream. So, for my/our future Googling\nreference: I quote the section out of\nhttp://gitster.livejournal.com/24080.html that I believe applied to me\n_before_ I messed things up so badly:\n\nyour_blog> Another advantage of rebasing your personal patch constantly is that\nyour_blog> it forces you a discipline to adjust your changes to the changes in\nyour_blog> the upstream as early as possible.  If you do not rebase\nand choose to\nyour_blog> use merge in your workflow, your personal changes will be buried deep\nyour_blog> in the history.  When one of your many later merges with the upstream\nyour_blog> made you resolve the conflicts with such old changes, two things\nyour_blog> happen:\nyour_blog>\nyour_blog>     * You do not remember what your own change was about, and have a\nyour_blog>       hard time resolving the conflict;\nyour_blog>\nyour_blog>     * You may be able to resolve the conflict, but what you can\nyour_blog>       extract from \"git log --no-merges origin..\" will not be\nyour_blog>       something you can eventually send upstream.  You will need to\nyour_blog>       rebase before submitting.\n\nAgain, much MUCH thanks for your assistance!\n\nBrent\n"},{"id":"103800","messageId":"200902081918.35665.bss@iguanasuicide.net","threadId":"17660","inReplyTo":"e38bce640902081613v3e93c1e3g716118c38ce861ab@mail.gmail.com","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-02-09T01:18:29Z","receivedAt":"2009-02-09T01:18:29Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Sunday 08 February 2009 18:13:00 you wrote:\n> On Sun, Feb 8, 2009 at 1:46 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> > Now what is that topic branch is for?  Yes, it is about adding this new\n> > feature, and nothing else.  Don't pull other people's changes made on my\n> > tree into it.  That will make your topic branch \"one new feature and\n> > everything else\" and useless as a topic branch.\n>\n> Fair enough, but I don't understand what is referred to by \"my tree\" above?\n\nJunio means his git tree.  Which is where we get releases from.\n\n> >        $ git checkout -b bg/no-progress origin/master\n> >        ... work on e802880 ...\n> >        ... test it ...\n> >        $ git commit ;# record that on bg/no-progress topic\n> >\n> >        $ git checkout master\n> >        $ git merge bg/no-progress\n> >        ... test the result of the merge ...\n>\n> Refering to that git merge bg/no-progress command above. You said not\n> to merge from master to bg/no-progress at this early stage, which\n> makes sense, but now you are going in the reverse via master <--\n> bg/no-progress.\n\nWell, master is not a topic branch, so merging a topic branch into it is not \nnecessarily bad.\n\n> And here I do not see a commit, but that command is\n> followed straight way with a \"git checkout bg/no-progress\" below.  Is\n> that just for testing the merge with the intent of just throwing the\n> changes away?\n\nMerge automatically does a commit unless there are conflicts.\n\n> In other words, is this next \"git checkout\n> bg/no-progress\" command going to silently throw away the \"git merge\n> bg/progress\" step at this point?\n\nNo, it doesn't throw it away.  However, it never made any changes to pg/no-\nprogress just to master, so bg/no-progress will not show the results of the \nmerge.\n\n> Similar question: Is this next \"git checkout bg/no-progress\" below\n> going to loose the conflicts I would have just resolved above\n> (referring to the most recent \"... resolve conflicts ...\" line above)?\n\nIt's going to but you back on bg/no-progress, which doesn't have Junio's \nlatest changes, so there won't be any conflicts immediately.\n\n> > which may conflict again (but that would be the same conflict you saw\n> > with your \"git pull\" from me, and rerere may remember it).\n> What does \"rerere\" mean, or is that a typo?\n\nREuse REcorded REsolutions.  It's a git option to remember how you resolved \nmerge conflicts and automatically apply those resolutions later.\n\n> > and reorder, squash, and fix them.\n> What do you mean by \"reorder, squash\" mean here? Is that something\n> that is done as a part of the -i option to git rebase?\n\nReordering and squashing can be done via rebase -i, but it's basically just \nthe practice of \"prettying\" your changes.  \nhttp://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ has more \nprose on the subject.\n\n> >        $ git checkout bg/no-progress^0\n> What is the significance of the ^0 construct tacked onto the end of\n> \"bg/no-progress\" at this point, versus just \"git checkout\n> bg/no-progress\" without the \"^0\"?\n\nIt took me a second, but I believe this checks out bg/no-progress and detaches \nHEAD.\n-- \nBoyd Stephen Smith Jr.                   ,= ,-_-. =.\nbss@iguanasuicide.net                   ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'\nhttp://iguanasuicide.net/                    \\_/\n\n"},{"id":"103809","messageId":"e38bce640902081859o47462a58s59c120209fabb0@mail.gmail.com","threadId":"17660","inReplyTo":"200902081918.35665.bss@iguanasuicide.net","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-09T02:59:34Z","receivedAt":"2009-02-09T02:59:34Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Sun, Feb 8, 2009 at 5:18 PM, Boyd Stephen Smith Jr.\n<bss@iguanasuicide.net> wrote:\n> > What do you mean by \"reorder, squash\" mean here? Is that something\n> > that is done as a part of the -i option to git rebase?\n>\n> Reordering and squashing can be done via rebase -i, but it's basically just\n> the practice of \"prettying\" your changes.\n> http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ has more\n> prose on the subject.\n\nThanks Boyd.  I made the mistake of using git revert HEAD thinking it\nwould just delete that last revision, but it instead added a new\nrevision that acted as if it just reversed the changes.\n\nWhat I really want to do is simply replace the last two commits on the\nbranch with one commit, so that when I make my patch it will be just\nthe full set of changes and not a lot of noise. Is there a way to do\nthat? (note: I did try the git merge --squash command but it just\nshowed me the usage, as I was on my bg/no-progress branch).  Note that\nI know that I would not be able to do this once some of my changes had\nmerged upstream.\n\nThanks,\nbgoodr\n"},{"id":"103813","messageId":"7vmycww6if.fsf@gitster.siamese.dyndns.org","threadId":"17660","inReplyTo":"e38bce640902081859o47462a58s59c120209fabb0@mail.gmail.com","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-09T04:58:48Z","receivedAt":"2009-02-09T04:58:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brent Goodrick <bgoodr@gmail.com> writes:\n\n> What I really want to do is simply replace the last two commits on the\n> branch with one commit, so that when I make my patch it will be just\n> the full set of changes and not a lot of noise. Is there a way to do\n> that? (note: I did try the git merge --squash command but it just\n> showed me the usage, as I was on my bg/no-progress branch).  Note that\n> I know that I would not be able to do this once some of my changes had\n> merged upstream.\n\nSuppose you have this topology.  You forked and built 2 commits, while the\nupstream advanced its tip (or not).\n\n                 1--2 your commits (master)\n                /\n\t---o---o---o upstream (origin)\n\n1. Using \"rebase -i\"\n\n    ... on your \"master\"\n    $ git rebase -i origin\n    ... will give you an insn sheet for interactive rebase to edit.\n    ... you will see something like:\n\n\tpick xxxxxx title of commit 1\n       \tpick yyyyyy title of commit 2\n\n    ... edit the second \"pick\" to \"squash\", save and exit the editor.\n    ... You are telling it to \"first cherry-pick my 1, and then squash my\n    ... 2 on top of it.\n\n    ... it will do as it is told, and will give you another editor, with\n    ... messages from both commits in it.  Edit to formulate a log message\n    ... suitable for the combined commit, save and exit the editor.\n\n   You will end up with:\n\n\t---o---o---o---X\n\n   where rightmost 'o' is still origin, X is your two commits squashed\n   into one.\n\n2. Using \"mrege -s squash\"\n\n    ... on your \"master\"\n    $ git merge --squash origin\n    ... this will stop without creating a commit.  Then you would\n    $ git commit\n    ... and the editor will give you the log message from all the\n    ... commits on the branch you just merged.  Come up with a single\n    ... log message to describe all, save and exit the editor.\n\n   You will end up with:\n\n\t---o---o---o---X\n\n   where rightmost 'o' is still origin, X is your two commits squashed\n   into one.\n"},{"id":"103909","messageId":"e38bce640902091359j3f306839h9aeb699e18e420ab@mail.gmail.com","threadId":"17660","inReplyTo":"7vmycww6if.fsf@gitster.siamese.dyndns.org","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-09T21:59:40Z","receivedAt":"2009-02-09T21:59:40Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"My changes should live on my bg/no-progress branch until which time as\nthey are accepted so I don't want them plunked down onto the\noriginating branch quite yet (rebasing is fine, but I don't want to\ndisturb that originating branch).\n\nTo explain what I mean: Yesterday, I had this configuration on my\nbg/no-progress branch:\n\n             A---B---C---D (bg/no-progress)\n            /\n----1-----2----3----4 (master)\n\nB C and D commits are noisy,\nfix-the-white-space-and-conform-to-coding-guidelines type commits. I\nwant to collapse A through D into one commit called E on that branch\nso that I can run git format-patch -M on the result and provide a nice\npatch email. I would end up with:\n\n             E (bg/no-progress)\n            /\n----1-----2----3----4 (master)\n\nI do have a way to do that, but it is cumbersome: I ended up doing:\n\n1. git diff -p >saved_patch of A through D (I don't recall the exact\ngit diff command).\n2. Use a form of git rebase similar to \"git rebase --onto topicA~5\ntopicA~3 topicA\" as explained in the git-rebase man page\n3. Use git apply saved_patch\n4. Reapply the commit with a new commit message\n5. Use git format-patch -M --stdout .... > mail.txt\n\nAgain, all while staying on the bg/no-progress branch.\n\nBut that was tricky (at least the git rebase command was). Is there a\nshorter, cleaner way to compress multiple commits on a given branch\nusing one rebase command and not saving off a patch?\n\nThanks,\nbg\n\n\nOn Sun, Feb 8, 2009 at 8:58 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Brent Goodrick <bgoodr@gmail.com> writes:\n>\n> > What I really want to do is simply replace the last two commits on the\n> > branch with one commit, so that when I make my patch it will be just\n> > the full set of changes and not a lot of noise. Is there a way to do\n> > that? (note: I did try the git merge --squash command but it just\n> > showed me the usage, as I was on my bg/no-progress branch).  Note that\n> > I know that I would not be able to do this once some of my changes had\n> > merged upstream.\n>\n> Suppose you have this topology.  You forked and built 2 commits, while the\n> upstream advanced its tip (or not).\n>\n>                 1--2 your commits (master)\n>                /\n>        ---o---o---o upstream (origin)\n>\n> 1. Using \"rebase -i\"\n>\n>    ... on your \"master\"\n>    $ git rebase -i origin\n>    ... will give you an insn sheet for interactive rebase to edit.\n>    ... you will see something like:\n>\n>        pick xxxxxx title of commit 1\n>        pick yyyyyy title of commit 2\n>\n>    ... edit the second \"pick\" to \"squash\", save and exit the editor.\n>    ... You are telling it to \"first cherry-pick my 1, and then squash my\n>    ... 2 on top of it.\n>\n>    ... it will do as it is told, and will give you another editor, with\n>    ... messages from both commits in it.  Edit to formulate a log message\n>    ... suitable for the combined commit, save and exit the editor.\n>\n>   You will end up with:\n>\n>        ---o---o---o---X\n>\n>   where rightmost 'o' is still origin, X is your two commits squashed\n>   into one.\n>\n> 2. Using \"mrege -s squash\"\n>\n>    ... on your \"master\"\n>    $ git merge --squash origin\n>    ... this will stop without creating a commit.  Then you would\n>    $ git commit\n>    ... and the editor will give you the log message from all the\n>    ... commits on the branch you just merged.  Come up with a single\n>    ... log message to describe all, save and exit the editor.\n>\n>   You will end up with:\n>\n>        ---o---o---o---X\n>\n>   where rightmost 'o' is still origin, X is your two commits squashed\n>   into one.\n"},{"id":"103914","messageId":"200902091615.24958.bss@iguanasuicide.net","threadId":"17660","inReplyTo":"e38bce640902091359j3f306839h9aeb699e18e420ab@mail.gmail.com","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-02-09T22:14:26Z","receivedAt":"2009-02-09T22:14:26Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Monday 09 February 2009 15:59:40 Brent Goodrick wrote:\n> To explain what I mean: Yesterday, I had this configuration on my\n> bg/no-progress branch:\n>\n>              A---B---C---D (bg/no-progress)\n>             /\n> ----1-----2----3----4 (master)\n>\n> B C and D commits are noisy,\n> fix-the-white-space-and-conform-to-coding-guidelines type commits. I\n> want to collapse A through D into one commit called E on that branch\n> so that I can run git format-patch -M on the result and provide a nice\n> patch email. I would end up with:\n>\n>              E (bg/no-progress)\n>             /\n> ----1-----2----3----4 (master)\n\nHere's my way to do that:\ngit rebase -i $(git merge-base master bg/noprogress) bg/no-progress\n# Editor opens\n# Change \"pick\" -> \"squash\" for commits B, C, and D.\n# rebase runs\n# Maybe resolve conflicts\n\nIf you are willing to have:\n             E (bg/no-progress)\n            /\n--1--2--3--4 (master)\n\nat the end, it's a little bit simpler:\ngit rebase -i master bg/no-progress\n# All the rest the same.\n-- \nBoyd Stephen Smith Jr.           \t ,= ,-_-. =.\nbss@iguanasuicide.net            \t((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy \t `-'(. .)`-'\nhttp://iguanasuicide.net/        \t     \\_/\n\n"},{"id":"103949","messageId":"slrngp24ap.i22.sitaramc@sitaramc.homelinux.net","threadId":"17660","inReplyTo":"e38bce640902091359j3f306839h9aeb699e18e420ab@mail.gmail.com","subject":"Re: Trouble testing out a patch on a branch new scratch git.git repository","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-10T05:32:09Z","receivedAt":"2009-02-10T05:32:09Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-09, Brent Goodrick <bgoodr@gmail.com> wrote:\n> To explain what I mean: Yesterday, I had this configuration on my\n> bg/no-progress branch:\n>\n>              A---B---C---D (bg/no-progress)\n>             /\n> ----1-----2----3----4 (master)\n>\n> B C and D commits are noisy,\n> fix-the-white-space-and-conform-to-coding-guidelines type commits. I\n> want to collapse A through D into one commit called E on that branch\n> so that I can run git format-patch -M on the result and provide a nice\n> patch email. I would end up with:\n>\n>              E (bg/no-progress)\n>             /\n> ----1-----2----3----4 (master)\n\nYou want to squash the last 4 patches on the current branch\ninto one?\n\nThe fastest way, if you don't mind re-typing the commit\nmessage for the combined commit, is this:\n\n    git reset --soft HEAD~4\n    git commit\n\nA kinder, gentler, way is this:\n\n(1) type in 'git rebase -i HEAD~4'\n\n(2) In the editor that pops up, change the 'pick' on all but\n    the first entry to 'squash' or just 's' and save the\n    file.\n\n    There won't be any conflicts in this scenario, so don't\n    worry about that.\n\n(3) Another editor will pop up showing all 4 commit messages\n    in one edit buffer -- combine the various commit\n    messages however you wish and save the file.\n\nDone :-)\n\n-- \nSitaram\n"}]}