How can I easily verify my diffs are in parent branch?

How can I easily verify my diffs are in parent branch?

[Alex Bennee]

Hi,

This is not the case of looking through the logs for my commit as I'm
exporting my changes from my tree into the company system through CVS.
This means all the usual commit tracking benefits are lost.

So I have a master branch which tracks this master baseline from CVS and
each release I import a big change set which includes all the fixes that
went into that baseline.

What I need to do is check that my commits that I submitted for the
baseline have been correctly merged. Of course if I do "git-diff
master..mywork" I'll see all the other code that has been added in (or
more usually is missing from my branch).

Is there an invocation of git-diff or another tool that can tell me all
my diffs are present in the big uber-commit of my master branch baseline
release?

-- 
Alex, homepage: http://www.bennee.com/~alex/
Any excuse will serve a tyrant. -- Aesop

Re: How can I easily verify my diffs are in parent branch?

[Alex Riesen]

On 4/4/07, Alex Bennee <kernel-hacker@bennee.com> wrote:
> Is there an invocation of git-diff or another tool that can tell me all
> my diffs are present in the big uber-commit of my master branch baseline
> release?

You can limit git-diff to the pathnames you touched in your commits
(assuming you now the first commit you sent upstream).

git diff-tree --name-only first HEAD | while read f; do
  git diff-tree --shortstat upstream HEAD -- "$f"
done

It is very inefficient, though

Re: How can I easily verify my diffs are in parent branch?

[Andy Parkins]

On Wednesday 2007 April 04 12:36, Alex Bennee wrote:

> What I need to do is check that my commits that I submitted for the
> baseline have been correctly merged. Of course if I do "git-diff
> master..mywork" I'll see all the other code that has been added in (or
> more usually is missing from my branch).
>
> Is there an invocation of git-diff or another tool that can tell me all
> my diffs are present in the big uber-commit of my master branch baseline
> release?

Kind of.  Try git-cherry (I like to use -v as well).  This will compare the 
hash of the diff of each of the revisions in your current branch with those 
of an upstream branch.

 * -- O -- * -- * -- C' -- * (upstream)
       \
        A -- B -- C -- D (yourbranch)

With something like the above, were C has been accepted into upstream as 
revision C', runing git-cherry on yourbranch would give:

 $ git-cherry upstream
 +A
 +B
 -C
 +D

The "-" in front of C means that you can remove C from yourbranch - it's been 
accepted.

However, this relies on the applied patch matching exactly (not the log 
message - that can be anything), so if a typo got fixed by the maintainer, it 
would show up as not having been accepted.

Another good way of telling is to rebase yourbranch onto the current 
upstream - a patch that doesn't need applying (because it's already there) 
get's dropped automatically by git.  This is really handy because git 
effectively filters those patches that you don't need to worry about any more 
in yourbranch.  This would cope with a typo fix as well, because git-rebase 
would note a conflict which you would then see as being a minor typo and 
would do "git rebase --skip" which would manually drop the patch from 
yourbranch.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: How can I easily verify my diffs are in parent branch?

[Linus Torvalds]

On Wed, 4 Apr 2007, Alex Bennee wrote:
> 
> This is not the case of looking through the logs for my commit as I'm
> exporting my changes from my tree into the company system through CVS.
> This means all the usual commit tracking benefits are lost.

Yeah, sad.

> So I have a master branch which tracks this master baseline from CVS and
> each release I import a big change set which includes all the fixes that
> went into that baseline.

So all your small diffs get smushed in as part of one *big* change? Or do 
they still exist in the baseline CVS tree as individual commits?

If they still exist in the CVS tree as individual commits, you're slightly 
better off: you can use "git patch-id" to generate a hash of all the 
patches, and compare just the hashes. That allows you to efficiently find 
patches that have been applied *identically* in both trees.

NOTE! "git-patch-id" generates a hash of a patch by ignoring 
 - line numbers
 - whitespace
 - commit comments
so "identical" means just that the patch has to have the exact same 
context and +/- patterns, but it will still be considered identical if 
it's been moved around (perhaps because some other patch added/removed 
code before it) or if the whitespace has been tweaked.

You can then compare the hashes upstream with all the commits *you* cared 
about, and see if they are all there. But as noted, this only works if 
upstream is expected to actually honor patch-boundaries. If you just get a 
single big changeset that contains *all* the changes, doign this obviously 
won't work.

NOTE2! I don't think anybody actually *uses* git-patch-id, and what you 
should do is to use "git cherry" that does this all internally, but it is 
worth understanding *what* git-cherry does.

So to compare all patch-ID's, you can do

	git cherry cvs-upstream my-branch

adn it should look at all the commits that are in *your* branch but not 
upstream, and report their ID's preceded by a "-" if they are upstream, 
and a "+" if they are not.

You can then look at the "+" commits more closely, to see whether maybe 
they actually did get merged, but got changed/fixed in the process, or 
whether they really are missing.

> Is there an invocation of git-diff or another tool that can tell me all
> my diffs are present in the big uber-commit of my master branch baseline
> release?

If git cherry doesn't work for you, you're kind of screwed and have to do 
it manually. Of course, even "manually" can be done with a lot of help 
from git.

For example, one thing you can do, if the number of commits you have is 
fairly small, is to just be on your "my-branch" and then do

	git rebase [--merge] cvs-upstream

which will rebase your "my-branch" onto the CVS upstream thing. It will 
automatically discard any patches that get merged away (which effectively 
means that they were already there). The end result will be that your 
branch will now either be identical to "cvs-upstream" (if everything was 
already there) or will contain the commits that weren't there on top of 
the new cvs-upstream tip.

NOTE NOTE NOTE! The "git rebase" thing sounds perfect, but the fact is, 
quite often you'll end up having to help it do its work. It really 
defaults to just trying to apply the patches (ie without "--merge" it's 
literally just a fancy

	git-format-patch | git am

pipeline).

So "git rebase" may well be the right thing for you, but quite frankly, 
it's more likely to work well for simple cases (with no real conflicts 
with anybody elses work in the same areas) than for anything complicated.

For complicated stuff, you'll be on your own. "git diff pathname" etc..

		Linus

Re: How can I easily verify my diffs are in parent branch?

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> So to compare all patch-ID's, you can do
>
> 	git cherry cvs-upstream my-branch
>
> adn it should look at all the commits that are in *your* branch but not 
> upstream, and report their ID's preceded by a "-" if they are upstream, 
> and a "+" if they are not.
>
> You can then look at the "+" commits more closely, to see whether maybe 
> they actually did get merged, but got changed/fixed in the process, or 
> whether they really are missing.

Funny.

Last night I was thinking about git-cherry, as it is one of the
few commands that have "funny parameter semantics that do not
mesh well with git-log family" (others are format-patch and
rebase).

I think we should be able to use --left-right and ... operator
to express what the above cherry does with something like:

    $ git log --left-right --ignore-common-patch cvs-upstream...my-branch

The --ignore-common-patch option does not exist yet, but the
basic code to implement it should already be accessible from the
log family, as that is what format-patch needs to do.

Re: How can I easily verify my diffs are in parent branch?

[David Kågedal]

Junio C Hamano <junkio@cox.net> writes:

> I think we should be able to use --left-right and ... operator
> to express what the above cherry does with something like:
>
>     $ git log --left-right --ignore-common-patch cvs-upstream...my-branch

--left-right is not documented, so I think it's hard for people (for
me at least) to follow your reasoning.

Would it be to much to ask for to want to have all options have some
kind of documentation? As in not accepting patches for new options
that don't include documentation?

"git log -Sleft-right" will actually give me the documentation I want,
since the docs are written but only put in the commit message.  A git
user that only uses a git installation has no way of finding that,
though.

-- 
David Kågedal

Re: How can I easily verify my diffs are in parent branch?

[Junio C Hamano]

David Kågedal <davidk@lysator.liu.se> writes:

> Junio C Hamano <junkio@cox.net> writes:
>
>> I think we should be able to use --left-right and ... operator
>> to express what the above cherry does with something like:
>>
>>     $ git log --left-right --ignore-common-patch cvs-upstream...my-branch
>
> --left-right is not documented, so I think it's hard for people (for
> me at least) to follow your reasoning.
>
> Would it be to much to ask for to want to have all options have some
> kind of documentation?

Not at all.  I often wish that ;-)

> As in not accepting patches for new options
> that don't include documentation?
>
> "git log -Sleft-right" will actually give me the documentation I want,
> since the docs are written but only put in the commit message.

Fair enough.  Perhaps the list can help out ;-).

[PATCH] Document --left-right option to rev-list.

[Brian Gernhardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 2337 bytes --]

Explanation is paraphrased from "577ed5c... rev-list --left-right"
---

Junio C Hamano <junkio@cox.net> writes:

> David Kågedal <davidk@lysator.liu.se> writes:
>
>> "git log -Sleft-right" will actually give me the documentation I want,
>> since the docs are written but only put in the commit message.
>
> Fair enough.  Perhaps the list can help out ;-).

Like this?  :-)

 Documentation/git-rev-list.txt |   19 +++++++++++++++++++
 builtin-rev-list.c             |    1 +
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 3fa45b8..5b33865 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -21,6 +21,7 @@ SYNOPSIS
 	     [ \--stdin ]
 	     [ \--topo-order ]
 	     [ \--parents ]
+	     [ \--left-right ]
 	     [ \--encoding[=<encoding>] ]
 	     [ \--(author|committer|grep)=<pattern> ]
 	     [ [\--objects | \--objects-edge] [ \--unpacked ] ]
@@ -101,6 +102,24 @@ include::pretty-formats.txt[]
 
 	Print the parents of the commit.
 
+--left-right::
+
+	Mark which side of a symmetric diff a commit is reachable from.
+	Commits from the left side are prefixed with `<` and those from
+	the right with `>`.  If combined with `--boundary`, those
+	commits are prefixed with `-`.  For example:
+
+-----------------------------------------------------------------------
+	$ git rev-list --left-right --boundary --pretty=oneline A...B
+
+	>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
+	>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
+	<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
+	<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
+	-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
+	-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a
+-----------------------------------------------------------------------
+
 Diff Formatting
 ~~~~~~~~~~~~~~~
 
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index f91685a..09774f9 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -35,6 +35,7 @@ static const char rev_list_usage[] =
 "    --header | --pretty\n"
 "    --abbrev=nr | --no-abbrev\n"
 "    --abbrev-commit\n"
+"    --left-right\n"
 "  special purpose:\n"
 "    --bisect\n"
 "    --bisect-vars"
-- 
1.5.1.32.gdd6cd

Re: [PATCH] Document --left-right option to rev-list.

[Junio C Hamano]

Thanks.

Re: [PATCH] Document --left-right option to rev-list.

[Alex Riesen]

On 4/5/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
> +--left-right::
> +
> +       Mark which side of a symmetric diff a commit is reachable from.
> +       Commits from the left side are prefixed with `<` and those from
> +       the right with `>`.  If combined with `--boundary`, those
> +       commits are prefixed with `-`.  For example:

"If combined with '--boundary', the boundary commits will be also printed
and prefixed with '-'."

Otherwise it is a bit unclear what commits are prefixed with '-': the left,
the right, or the boundary.

[PATCH 1/2] git-log --cherry-pick

[Junio C Hamano]

This is meant to be a saner replacement for "git-cherry".

When used with "A...B", this filters out commits whose patch
text has the same patch-id as a commit on the other side.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

  Junio C Hamano <junkio@cox.net> writes:

  > Funny.
  >
  > Last night I was thinking about git-cherry, as it is one of the
  > few commands that have "funny parameter semantics that do not
  > mesh well with git-log family" (others are format-patch and
  > rebase).
  >
  > I think we should be able to use --left-right and ... operator
  > to express what the above cherry does with something like:
  >
  >     $ git log --left-right --ignore-common-patch cvs-upstream...my-branch
  >
  > The --ignore-common-patch option does not exist yet, but the
  > basic code to implement it should already be accessible from the
  > log family, as that is what format-patch needs to do.

 revision.c |  141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 revision.h |    1 +
 2 files changed, 142 insertions(+), 0 deletions(-)

diff --git a/revision.c b/revision.c
index 486393c..0903f19 100644
--- a/revision.c
+++ b/revision.c
@@ -422,6 +422,139 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
 	}
 }
 
+/*
+ * This needs to be moved from builtin-log -- its get_patch_ids() implementation
+ * is horrible -- it pollutes the object array with non objects!
+ */
+static int get_patch_id(struct commit *commit, struct diff_options *options,
+		unsigned char *sha1)
+{
+	if (commit->parents)
+		diff_tree_sha1(commit->parents->item->object.sha1,
+		               commit->object.sha1, "", options);
+	else
+		diff_root_tree_sha1(commit->object.sha1, "", options);
+	diffcore_std(options);
+	return diff_flush_patch_id(options, sha1);
+}
+
+struct patch_id_ent {
+	unsigned char patch_id[20];
+	char seen;
+};
+
+static int compare_patch_id(const void *a_, const void *b_)
+{
+	struct patch_id_ent *a = *((struct patch_id_ent **)a_);
+	struct patch_id_ent *b = *((struct patch_id_ent **)b_);
+	return hashcmp(a->patch_id, b->patch_id);
+}
+
+static void cherry_pick_list(struct commit_list *list)
+{
+	struct commit_list *p;
+	int left_count = 0, right_count = 0, nr;
+	struct patch_id_ent *patches, **table;
+	int left_first, table_size;
+	struct diff_options opts;
+
+	/* First count the commits on the left and on the right */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		unsigned flags = commit->object.flags;
+		if (flags & BOUNDARY)
+			;
+		else if (flags & SYMMETRIC_LEFT)
+			left_count++;
+		else
+			right_count++;
+	}
+
+	left_first = left_count < right_count;
+	table_size = left_first ? left_count : right_count;
+
+	/* Allocate a look-up table to help matching up */
+	patches = xcalloc(table_size, sizeof(struct patch_id_ent));
+	table = xcalloc(table_size, sizeof(struct patch_id_ent *));
+	nr = 0;
+
+	diff_setup(&opts);
+	opts.recursive = 1;
+	if (diff_setup_done(&opts) < 0)
+		die("diff_setup_done failed");
+
+	/* Compute patch-ids for one side */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		unsigned flags = commit->object.flags;
+
+		if (flags & BOUNDARY)
+			continue;
+		/*
+		 * If we have fewer left, left_first is set and we omit
+		 * commits on the right branch in this loop.  If we have
+		 * fewer right, we skip the left ones.
+		 */
+		if (left_first != !!(flags & SYMMETRIC_LEFT))
+			continue;
+		if (get_patch_id(commit, &opts, patches[nr].patch_id))
+			continue;
+		/*
+		 * FIXME: this does not really work if the side
+		 * we are dealing with have two commits with the same
+		 * patch id, as we end up having two entries in the
+		 * patch table.
+		 */
+		table[nr] = &(patches[nr]);
+		commit->util = table[nr];
+		nr++;
+	}
+	qsort(table, nr, sizeof(table[0]), compare_patch_id);
+
+	/* Check the other side */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		unsigned flags = commit->object.flags;
+		struct patch_id_ent ent, *entp = &ent, **found;
+
+		if (flags & BOUNDARY)
+			continue;
+		/*
+		 * If we have fewer left, left_first is set and we omit
+		 * commits on the left branch in this loop.
+		 */
+		if (left_first == !!(flags & SYMMETRIC_LEFT))
+			continue;
+		if (get_patch_id(commit, &opts, ent.patch_id))
+			continue;
+		/*
+		 * Have we seen the same patch id?
+		 */
+		found = bsearch(&entp, table, nr, sizeof(table[0]),
+				compare_patch_id);
+		if (!found)
+			continue;
+		(*found)->seen = 1;
+		commit->object.flags |= SHOWN; /* exclude this from the output set */
+	}
+
+	/* Now check the original side for seen ones */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		struct patch_id_ent *ent;
+
+		ent = commit->util;
+		if (!ent)
+			continue;
+		if (ent->seen)
+			commit->object.flags |= SHOWN;
+		commit->util = NULL;
+	}
+
+	free(table);
+	free(patches);
+}
+
 static void limit_list(struct rev_info *revs)
 {
 	struct commit_list *list = revs->commits;
@@ -449,6 +582,9 @@ static void limit_list(struct rev_info *revs)
 			continue;
 		p = &commit_list_insert(commit, p)->next;
 	}
+	if (revs->cherry_pick)
+		cherry_pick_list(newlist);
+
 	revs->commits = newlist;
 }
 
@@ -913,6 +1049,11 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 				revs->left_right = 1;
 				continue;
 			}
+			if (!strcmp(arg, "--cherry-pick")) {
+				revs->cherry_pick = 1;
+				revs->left_right = 1;
+				continue;
+			}
 			if (!strcmp(arg, "--objects")) {
 				revs->tag_objects = 1;
 				revs->tree_objects = 1;
diff --git a/revision.h b/revision.h
index 55e6b53..b69624a 100644
--- a/revision.h
+++ b/revision.h
@@ -47,6 +47,7 @@ struct rev_info {
 			left_right:1,
 			parents:1,
 			reverse:1,
+			cherry_pick:1,
 			first_parent_only:1;
 
 	/* Diff flags */

[PATCH 1/4] Add %m to '--pretty=format:'

[Junio C Hamano]

When used with '--boundary A...B', this shows the -/</> marker
you would get with --left-right option to 'git-log' family.
When symmetric diff is not used, everybody is shown to be on the
"right" branch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 * This was one thing I found missing from the "--pretty=format:"
   Dscho did.  This time it comes with a documentation updates ;-).

 Documentation/pretty-formats.txt |    1 +
 commit.c                         |   16 +++++++++++++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2fe6c31..d7ffc21 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -117,6 +117,7 @@ The placeholders are:
 - '%Cgreen': switch color to green
 - '%Cblue': switch color to blue
 - '%Creset': reset color
+- '%m': left, right or boundary mark
 - '%n': newline
 
 
diff --git a/commit.c b/commit.c
index 754d1b8..952095f 100644
--- a/commit.c
+++ b/commit.c
@@ -4,6 +4,8 @@
 #include "pkt-line.h"
 #include "utf8.h"
 #include "interpolate.h"
+#include "diff.h"
+#include "revision.h"
 
 int save_commit_buffer = 1;
 
@@ -808,7 +810,8 @@ static long format_commit_message(const struct commit *commit,
 		{ "%Cgreen" },	/* green */
 		{ "%Cblue" },	/* blue */
 		{ "%Creset" },	/* reset color */
-		{ "%n" }	/* newline */
+		{ "%n" },	/* newline */
+		{ "%m" },	/* left/right/bottom */
 	};
 	enum interp_index {
 		IHASH = 0, IHASH_ABBREV,
@@ -824,14 +827,15 @@ static long format_commit_message(const struct commit *commit,
 		ISUBJECT,
 		IBODY,
 		IRED, IGREEN, IBLUE, IRESET_COLOR,
-		INEWLINE
+		INEWLINE,
+		ILEFT_RIGHT,
 	};
 	struct commit_list *p;
 	char parents[1024];
 	int i;
 	enum { HEADER, SUBJECT, BODY } state;
 
-	if (INEWLINE + 1 != ARRAY_SIZE(table))
+	if (ILEFT_RIGHT + 1 != ARRAY_SIZE(table))
 		die("invalid interp table!");
 
 	/* these are independent of the commit */
@@ -852,6 +856,12 @@ static long format_commit_message(const struct commit *commit,
 	interp_set_entry(table, ITREE_ABBREV,
 			find_unique_abbrev(commit->tree->object.sha1,
 				DEFAULT_ABBREV));
+	interp_set_entry(table, ILEFT_RIGHT,
+			 (commit->object.flags & BOUNDARY)
+			 ? "-"
+			 : (commit->object.flags & SYMMETRIC_LEFT)
+			 ? "<"
+			 : ">");
 
 	parents[1] = 0;
 	for (i = 0, p = commit->parents;
-- 
1.5.1.777.gd14d3

[PATCH 2/4] Refactor patch-id filtering out of git-cherry and git-format-patch.

[Junio C Hamano]

This implements the patch-id computation and recording library,
patch-ids.c, and rewrites the get_patch_ids() function used in
cherry and format-patch to use it, so that they do not pollute
the object namespace.  Earlier code threw non-objects into the
in-core object database, and hoped for not getting bitten by
SHA-1 collisions.  While it may be practically Ok, it still was
an ugly hack.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 * Replacement of the previous one.  I wanted to clean-up the
   mess first.

 Makefile      |    3 +-
 builtin-log.c |   44 ++++---------
 patch-ids.c   |  192 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 patch-ids.h   |   21 ++++++
 4 files changed, 228 insertions(+), 32 deletions(-)
 create mode 100644 patch-ids.c
 create mode 100644 patch-ids.h

diff --git a/Makefile b/Makefile
index a77d31d..f956c3d 100644
--- a/Makefile
+++ b/Makefile
@@ -283,7 +283,7 @@ LIB_H = \
 	diff.h object.h pack.h pkt-line.h quote.h refs.h list-objects.h sideband.h \
 	run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
 	tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
-	utf8.h reflog-walk.h
+	utf8.h reflog-walk.h patch-ids.h
 
 DIFF_OBJS = \
 	diff.o diff-lib.o diffcore-break.o diffcore-order.o \
@@ -295,6 +295,7 @@ LIB_OBJS = \
 	date.o diff-delta.o entry.o exec_cmd.o ident.o \
 	interpolate.o \
 	lockfile.o \
+	patch-ids.o \
 	object.o pack-check.o patch-delta.o path.o pkt-line.o sideband.o \
 	reachable.o reflog-walk.o \
 	quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
diff --git a/builtin-log.c b/builtin-log.c
index 71df957..df676df 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -12,6 +12,7 @@
 #include "builtin.h"
 #include "tag.h"
 #include "reflog-walk.h"
+#include "patch-ids.h"
 
 static int default_show_root = 1;
 
@@ -333,25 +334,12 @@ static int reopen_stdout(struct commit *commit, int nr, int keep_subject)
 
 }
 
-static int get_patch_id(struct commit *commit, struct diff_options *options,
-		unsigned char *sha1)
-{
-	if (commit->parents)
-		diff_tree_sha1(commit->parents->item->object.sha1,
-		               commit->object.sha1, "", options);
-	else
-		diff_root_tree_sha1(commit->object.sha1, "", options);
-	diffcore_std(options);
-	return diff_flush_patch_id(options, sha1);
-}
-
-static void get_patch_ids(struct rev_info *rev, struct diff_options *options, const char *prefix)
+static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const char *prefix)
 {
 	struct rev_info check_rev;
 	struct commit *commit;
 	struct object *o1, *o2;
 	unsigned flags1, flags2;
-	unsigned char sha1[20];
 
 	if (rev->pending.nr != 2)
 		die("Need exactly one range.");
@@ -364,10 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co
 	if ((flags1 & UNINTERESTING) == (flags2 & UNINTERESTING))
 		die("Not a range.");
 
-	diff_setup(options);
-	options->recursive = 1;
-	if (diff_setup_done(options) < 0)
-		die("diff_setup_done failed");
+	init_patch_ids(ids);
 
 	/* given a range a..b get all patch ids for b..a */
 	init_revisions(&check_rev, prefix);
@@ -382,8 +367,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co
 		if (commit->parents && commit->parents->next)
 			continue;
 
-		if (!get_patch_id(commit, options, sha1))
-			created_object(sha1, xcalloc(1, sizeof(struct object)));
+		add_commit_patch_id(commit, ids);
 	}
 
 	/* reset for next revision walk */
@@ -420,7 +404,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	int ignore_if_in_upstream = 0;
 	int thread = 0;
 	const char *in_reply_to = NULL;
-	struct diff_options patch_id_opts;
+	struct patch_ids ids;
 	char *add_signoff = NULL;
 	char message_id[1024];
 	char ref_message_id[1024];
@@ -554,22 +538,19 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	}
 
 	if (ignore_if_in_upstream)
-		get_patch_ids(&rev, &patch_id_opts, prefix);
+		get_patch_ids(&rev, &ids, prefix);
 
 	if (!use_stdout)
 		realstdout = fdopen(dup(1), "w");
 
 	prepare_revision_walk(&rev);
 	while ((commit = get_revision(&rev)) != NULL) {
-		unsigned char sha1[20];
-
 		/* ignore merges */
 		if (commit->parents && commit->parents->next)
 			continue;
 
 		if (ignore_if_in_upstream &&
-				!get_patch_id(commit, &patch_id_opts, sha1) &&
-				lookup_object(sha1))
+				has_commit_patch_id(commit, &ids))
 			continue;
 
 		nr++;
@@ -624,6 +605,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 			fclose(stdout);
 	}
 	free(list);
+	if (ignore_if_in_upstream)
+		free_patch_ids(&ids);
 	return 0;
 }
 
@@ -646,7 +629,7 @@ static const char cherry_usage[] =
 int cmd_cherry(int argc, const char **argv, const char *prefix)
 {
 	struct rev_info revs;
-	struct diff_options patch_id_opts;
+	struct patch_ids ids;
 	struct commit *commit;
 	struct commit_list *list = NULL;
 	const char *upstream;
@@ -692,7 +675,7 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
 			return 0;
 	}
 
-	get_patch_ids(&revs, &patch_id_opts, prefix);
+	get_patch_ids(&revs, &ids, prefix);
 
 	if (limit && add_pending_commit(limit, &revs, UNINTERESTING))
 		die("Unknown commit %s", limit);
@@ -708,12 +691,10 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
 	}
 
 	while (list) {
-		unsigned char sha1[20];
 		char sign = '+';
 
 		commit = list->item;
-		if (!get_patch_id(commit, &patch_id_opts, sha1) &&
-		    lookup_object(sha1))
+		if (has_commit_patch_id(commit, &ids))
 			sign = '-';
 
 		if (verbose) {
@@ -731,5 +712,6 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
 		list = list->next;
 	}
 
+	free_patch_ids(&ids);
 	return 0;
 }
diff --git a/patch-ids.c b/patch-ids.c
new file mode 100644
index 0000000..a288fac
--- /dev/null
+++ b/patch-ids.c
@@ -0,0 +1,192 @@
+#include "cache.h"
+#include "diff.h"
+#include "commit.h"
+#include "patch-ids.h"
+
+static int commit_patch_id(struct commit *commit, struct diff_options *options,
+		    unsigned char *sha1)
+{
+	if (commit->parents)
+		diff_tree_sha1(commit->parents->item->object.sha1,
+		               commit->object.sha1, "", options);
+	else
+		diff_root_tree_sha1(commit->object.sha1, "", options);
+	diffcore_std(options);
+	return diff_flush_patch_id(options, sha1);
+}
+
+static uint32_t take2(const unsigned char *id)
+{
+	return ((id[0] << 8) | id[1]);
+}
+
+/*
+ * Conventional binary search loop looks like this:
+ *
+ *      do {
+ *              int mi = (lo + hi) / 2;
+ *              int cmp = "entry pointed at by mi" minus "target";
+ *              if (!cmp)
+ *                      return (mi is the wanted one)
+ *              if (cmp > 0)
+ *                      hi = mi; "mi is larger than target"
+ *              else
+ *                      lo = mi+1; "mi is smaller than target"
+ *      } while (lo < hi);
+ *
+ * The invariants are:
+ *
+ * - When entering the loop, lo points at a slot that is never
+ *   above the target (it could be at the target), hi points at a
+ *   slot that is guaranteed to be above the target (it can never
+ *   be at the target).
+ *
+ * - We find a point 'mi' between lo and hi (mi could be the same
+ *   as lo, but never can be the same as hi), and check if it hits
+ *   the target.  There are three cases:
+ *
+ *    - if it is a hit, we are happy.
+ *
+ *    - if it is strictly higher than the target, we update hi with
+ *      it.
+ *
+ *    - if it is strictly lower than the target, we update lo to be
+ *      one slot after it, because we allow lo to be at the target.
+ *
+ * When choosing 'mi', we do not have to take the "middle" but
+ * anywhere in between lo and hi, as long as lo <= mi < hi is
+ * satisfied.  When we somehow know that the distance between the
+ * target and lo is much shorter than the target and hi, we could
+ * pick mi that is much closer to lo than the midway.
+ */
+static int patch_pos(struct patch_id **table, int nr, const unsigned char *id)
+{
+	int hi = nr;
+	int lo = 0;
+	int mi = 0;
+
+	if (!nr)
+		return -1;
+
+	if (nr != 1) {
+		unsigned lov, hiv, miv, ofs;
+
+		for (ofs = 0; ofs < 18; ofs += 2) {
+			lov = take2(table[0]->patch_id + ofs);
+			hiv = take2(table[nr-1]->patch_id + ofs);
+			miv = take2(id + ofs);
+			if (miv < lov)
+				return -1;
+			if (hiv < miv)
+				return -1 - nr;
+			if (lov != hiv) {
+				/*
+				 * At this point miv could be equal
+				 * to hiv (but id could still be higher);
+				 * the invariant of (mi < hi) should be
+				 * kept.
+				 */
+				mi = (nr-1) * (miv - lov) / (hiv - lov);
+				if (lo <= mi && mi < hi)
+					break;
+				die("oops");
+			}
+		}
+		if (18 <= ofs)
+			die("cannot happen -- lo and hi are identical");
+	}
+
+	do {
+		int cmp;
+		cmp = hashcmp(table[mi]->patch_id, id);
+		if (!cmp)
+			return mi;
+		if (cmp > 0)
+			hi = mi;
+		else
+			lo = mi + 1;
+		mi = (hi + lo) / 2;
+	} while (lo < hi);
+	return -lo-1;
+}
+
+#define BUCKET_SIZE 190 /* 190 * 21 = 3990, with slop close enough to 4K */
+struct patch_id_bucket {
+	struct patch_id_bucket *next;
+	int nr;
+	struct patch_id bucket[BUCKET_SIZE];
+};
+
+int init_patch_ids(struct patch_ids *ids)
+{
+	memset(ids, 0, sizeof(*ids));
+	diff_setup(&ids->diffopts);
+	ids->diffopts.recursive = 1;
+	if (diff_setup_done(&ids->diffopts) < 0)
+		return error("diff_setup_done failed");
+	return 0;
+}
+
+int free_patch_ids(struct patch_ids *ids)
+{
+	struct patch_id_bucket *next, *patches;
+
+	free(ids->table);
+	for (patches = ids->patches; patches; patches = next) {
+		next = patches->next;
+		free(patches);
+	}
+	return 0;
+}
+
+static struct patch_id *add_commit(struct commit *commit,
+				   struct patch_ids *ids,
+				   int no_add)
+{
+	struct patch_id_bucket *bucket;
+	struct patch_id *ent;
+	unsigned char sha1[20];
+	int pos;
+
+	if (commit_patch_id(commit, &ids->diffopts, sha1))
+		return NULL;
+	pos = patch_pos(ids->table, ids->nr, sha1);
+	if (0 <= pos)
+		return ids->table[pos];
+	if (no_add)
+		return NULL;
+
+	pos = -1 - pos;
+
+	bucket = ids->patches;
+	if (!bucket || (BUCKET_SIZE <= bucket->nr)) {
+		bucket = xcalloc(1, sizeof(*bucket));
+		bucket->next = ids->patches;
+		ids->patches = bucket;
+	}
+	ent = &bucket->bucket[bucket->nr++];
+	hashcpy(ent->patch_id, sha1);
+
+	if (ids->alloc <= ids->nr) {
+		ids->alloc = alloc_nr(ids->nr);
+		ids->table = xrealloc(ids->table, sizeof(ent) * ids->alloc);
+	}
+	if (pos < ids->nr)
+		memmove(ids->table + pos + 1, ids->table + pos,
+			sizeof(ent) * (ids->nr - pos));
+	ids->nr++;
+	ids->table[pos] = ent;
+	return ids->table[pos];
+}
+
+struct patch_id *has_commit_patch_id(struct commit *commit,
+				     struct patch_ids *ids)
+{
+	return add_commit(commit, ids, 1);
+}
+
+struct patch_id *add_commit_patch_id(struct commit *commit,
+				     struct patch_ids *ids)
+{
+	return add_commit(commit, ids, 0);
+}
diff --git a/patch-ids.h b/patch-ids.h
new file mode 100644
index 0000000..c8c7ca1
--- /dev/null
+++ b/patch-ids.h
@@ -0,0 +1,21 @@
+#ifndef PATCH_IDS_H
+#define PATCH_IDS_H
+
+struct patch_id {
+	unsigned char patch_id[20];
+	char seen;
+};
+
+struct patch_ids {
+	struct diff_options diffopts;
+	int nr, alloc;
+	struct patch_id **table;
+	struct patch_id_bucket *patches;
+};
+
+int init_patch_ids(struct patch_ids *);
+int free_patch_ids(struct patch_ids *);
+struct patch_id *add_commit_patch_id(struct commit *, struct patch_ids *);
+struct patch_id *has_commit_patch_id(struct commit *, struct patch_ids *);
+
+#endif /* PATCH_IDS_H */
-- 
1.5.1.777.gd14d3

Re: [PATCH 2/4] Refactor patch-id filtering out of git-cherry and git-format-patch.

[Johannes Schindelin]

Hi,

On Tue, 10 Apr 2007, Junio C Hamano wrote:

> This implements the patch-id computation and recording library,
> patch-ids.c, and rewrites the get_patch_ids() function used in
> cherry and format-patch to use it, so that they do not pollute
> the object namespace.  Earlier code threw non-objects into the
> in-core object database, and hoped for not getting bitten by
> SHA-1 collisions.  While it may be practically Ok, it still was
> an ugly hack.

No, it was not an ugly hack. Instead, it served as a reminder that we 
_rely_ on different content having different SHA-1 ids.

Having said that, I do not particularly mind patch-ids being stored 
elsewhere, if only as a clean up. However, I would have liked your patch 
so much more if you had done the only sane thing: resurrect object-hash.c.

Now, we have yet another data structure which is unnecessarily bound to a 
certain use, and the next person wanting a new hashmap needs to add _yet_ 
another data structure.

Ciao,
Dscho

[PATCH 3/4] git-log --cherry-pick A...B

[Junio C Hamano]

This is meant to be a saner replacement for "git-cherry".

When used with "A...B", this filters out commits whose patch
text has the same patch-id as a commit on the other side.  It
would probably most useful to use with --left-right.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 revision.c |   88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 revision.h |    1 +
 2 files changed, 89 insertions(+), 0 deletions(-)

diff --git a/revision.c b/revision.c
index 486393c..e9de865 100644
--- a/revision.c
+++ b/revision.c
@@ -8,6 +8,7 @@
 #include "revision.h"
 #include "grep.h"
 #include "reflog-walk.h"
+#include "patch-ids.h"
 
 static char *path_name(struct name_path *path, const char *name)
 {
@@ -422,6 +423,86 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
 	}
 }
 
+static void cherry_pick_list(struct commit_list *list)
+{
+	struct commit_list *p;
+	int left_count = 0, right_count = 0;
+	int left_first;
+	struct patch_ids ids;
+
+	/* First count the commits on the left and on the right */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		unsigned flags = commit->object.flags;
+		if (flags & BOUNDARY)
+			;
+		else if (flags & SYMMETRIC_LEFT)
+			left_count++;
+		else
+			right_count++;
+	}
+
+	left_first = left_count < right_count;
+	init_patch_ids(&ids);
+
+	/* Compute patch-ids for one side */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		unsigned flags = commit->object.flags;
+
+		if (flags & BOUNDARY)
+			continue;
+		/*
+		 * If we have fewer left, left_first is set and we omit
+		 * commits on the right branch in this loop.  If we have
+		 * fewer right, we skip the left ones.
+		 */
+		if (left_first != !!(flags & SYMMETRIC_LEFT))
+			continue;
+		commit->util = add_commit_patch_id(commit, &ids);
+	}
+
+	/* Check the other side */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		struct patch_id *id;
+		unsigned flags = commit->object.flags;
+
+		if (flags & BOUNDARY)
+			continue;
+		/*
+		 * If we have fewer left, left_first is set and we omit
+		 * commits on the left branch in this loop.
+		 */
+		if (left_first == !!(flags & SYMMETRIC_LEFT))
+			continue;
+
+		/*
+		 * Have we seen the same patch id?
+		 */
+		id = has_commit_patch_id(commit, &ids);
+		if (!id)
+			continue;
+		id->seen = 1;
+		commit->object.flags |= SHOWN;
+	}
+
+	/* Now check the original side for seen ones */
+	for (p = list; p; p = p->next) {
+		struct commit *commit = p->item;
+		struct patch_id *ent;
+
+		ent = commit->util;
+		if (!ent)
+			continue;
+		if (ent->seen)
+			commit->object.flags |= SHOWN;
+		commit->util = NULL;
+	}
+
+	free_patch_ids(&ids);
+}
+
 static void limit_list(struct rev_info *revs)
 {
 	struct commit_list *list = revs->commits;
@@ -449,6 +530,9 @@ static void limit_list(struct rev_info *revs)
 			continue;
 		p = &commit_list_insert(commit, p)->next;
 	}
+	if (revs->cherry_pick)
+		cherry_pick_list(newlist);
+
 	revs->commits = newlist;
 }
 
@@ -913,6 +997,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 				revs->left_right = 1;
 				continue;
 			}
+			if (!strcmp(arg, "--cherry-pick")) {
+				revs->cherry_pick = 1;
+				continue;
+			}
 			if (!strcmp(arg, "--objects")) {
 				revs->tag_objects = 1;
 				revs->tree_objects = 1;
diff --git a/revision.h b/revision.h
index 55e6b53..b69624a 100644
--- a/revision.h
+++ b/revision.h
@@ -47,6 +47,7 @@ struct rev_info {
 			left_right:1,
 			parents:1,
 			reverse:1,
+			cherry_pick:1,
 			first_parent_only:1;
 
 	/* Diff flags */
-- 
1.5.1.777.gd14d3

[PATCH 4/4] Documentation: --cherry-pick

[Junio C Hamano]

Document how to use --cherry-pick, using earlier documentation
update that adds an example to --left-right.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/git-rev-list.txt |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 12b71ed..77e068b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -22,6 +22,7 @@ SYNOPSIS
 	     [ \--topo-order ]
 	     [ \--parents ]
 	     [ \--left-right ]
+	     [ \--cherry-pick ]
 	     [ \--encoding[=<encoding>] ]
 	     [ \--(author|committer|grep)=<pattern> ]
 	     [ [\--objects | \--objects-edge] [ \--unpacked ] ]
@@ -224,6 +225,20 @@ limiting may be applied.
 	In addition to the '<commit>' listed on the command
 	line, read them from the standard input.
 
+--cherry-pick::
+
+	Omit any commit that introduces the same change as
+	another commit on the "other side" when the set of
+	commits are limited with symmetric difference.
++
+For example, if you have two branches, `A` and `B`, a usual way
+to list all commits on only one side of them is with
+`--left-right`, like the example above in the description of
+that option.  It however shows the commits that were cherry-picked
+from the other branch (for example, "3rd on b" may be cherry-picked
+from branch A).  With this option, such pairs of commits are
+excluded from the output.
+
 -g, --walk-reflogs::
 
 	Instead of walking the commit ancestry chain, walk
-- 
1.5.1.777.gd14d3

[PATCH 2/2] Add %m to '--pretty=format:'

[Junio C Hamano]

When used with '--boundary A...B', this shows the -/</> marker you
would get with --left-right option to 'git-log' family.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * This can be used like this:

	$ git log --cherry-pick --pretty='format:%m%h %s' origin...master
	<e712d0c upstream side commit
        <deadbee upstream side commit
        >cafedee commit on my side

   to identify commits yet to be sent, probably easier to read
   than git-cherry.

 commit.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/commit.c b/commit.c
index 754d1b8..952095f 100644
--- a/commit.c
+++ b/commit.c
@@ -4,6 +4,8 @@
 #include "pkt-line.h"
 #include "utf8.h"
 #include "interpolate.h"
+#include "diff.h"
+#include "revision.h"
 
 int save_commit_buffer = 1;
 
@@ -808,7 +810,8 @@ static long format_commit_message(const struct commit *commit,
 		{ "%Cgreen" },	/* green */
 		{ "%Cblue" },	/* blue */
 		{ "%Creset" },	/* reset color */
-		{ "%n" }	/* newline */
+		{ "%n" },	/* newline */
+		{ "%m" },	/* left/right/bottom */
 	};
 	enum interp_index {
 		IHASH = 0, IHASH_ABBREV,
@@ -824,14 +827,15 @@ static long format_commit_message(const struct commit *commit,
 		ISUBJECT,
 		IBODY,
 		IRED, IGREEN, IBLUE, IRESET_COLOR,
-		INEWLINE
+		INEWLINE,
+		ILEFT_RIGHT,
 	};
 	struct commit_list *p;
 	char parents[1024];
 	int i;
 	enum { HEADER, SUBJECT, BODY } state;
 
-	if (INEWLINE + 1 != ARRAY_SIZE(table))
+	if (ILEFT_RIGHT + 1 != ARRAY_SIZE(table))
 		die("invalid interp table!");
 
 	/* these are independent of the commit */
@@ -852,6 +856,12 @@ static long format_commit_message(const struct commit *commit,
 	interp_set_entry(table, ITREE_ABBREV,
 			find_unique_abbrev(commit->tree->object.sha1,
 				DEFAULT_ABBREV));
+	interp_set_entry(table, ILEFT_RIGHT,
+			 (commit->object.flags & BOUNDARY)
+			 ? "-"
+			 : (commit->object.flags & SYMMETRIC_LEFT)
+			 ? "<"
+			 : ">");
 
 	parents[1] = 0;
 	for (i = 0, p = commit->parents;

Re: How can I easily verify my diffs are in parent branch?

[Alex Bennee]

On Wed, 2007-04-04 at 08:12 -0700, Linus Torvalds wrote:
> 
> On Wed, 4 Apr 2007, Alex Bennee wrote:
> > 
> > This is not the case of looking through the logs for my commit as I'm
> > exporting my changes from my tree into the company system through CVS.
> > This means all the usual commit tracking benefits are lost.
> 
> Yeah, sad.
> <snip>
> So all your small diffs get smushed in as part of one *big* change? Or do 
> they still exist in the baseline CVS tree as individual commits?

Unfortunately they are all smushed together :-(

<snip>

> For example, one thing you can do, if the number of commits you have is 
> fairly small, is to just be on your "my-branch" and then do
> 
> 	git rebase [--merge] cvs-upstream

Yeah I've tried using the rebase approach (which I in fact use a lot
when re-baseing my work anyway without losing my micro commit history).
The one fly in the ointment is the branch result at the end contains no
changes so I have no historical record of what I did while creating the
change.

I assume the commit objects are still in git somewhere but I'm not sure
how to get at it. What I would like to ask git is "what did my git-log
look like when 'mybranch' was based off master at A instead of B after O
rebased?"

For the time being I tend to verify my work has got in by generating a
master..branch diff and loading it into emacs patch-mode and testing
each hunk has applied ok. I'm still deciding if I should bite the bullet
and write some more elisp to make it a one button operation or use a bit
of perl with git. 


-- 
Alex, homepage: http://www.bennee.com/~alex/
"The most difficult thing in the world is to know how to do a thing and
to watch someone else do it wrong without comment." -- Theodore H. White

Re: How can I easily verify my diffs are in parent branch?

[Linus Torvalds]

On Wed, 11 Apr 2007, Alex Bennee wrote:

> On Wed, 2007-04-04 at 08:12 -0700, Linus Torvalds wrote:
> > 
> > Yeah, sad.
> > <snip>
> > So all your small diffs get smushed in as part of one *big* change? Or do 
> > they still exist in the baseline CVS tree as individual commits?
> 
> Unfortunately they are all smushed together :-(

Ok, that just sucks.

> > For example, one thing you can do, if the number of commits you have is 
> > fairly small, is to just be on your "my-branch" and then do
> > 
> > 	git rebase [--merge] cvs-upstream
> 
> Yeah I've tried using the rebase approach (which I in fact use a lot
> when re-baseing my work anyway without losing my micro commit history).
> The one fly in the ointment is the branch result at the end contains no
> changes so I have no historical record of what I did while creating the
> change.

Ok, that's what "rebase" is *meant* to do. If the upstream already 
contains the patch (which especially with "--merge" means that it just 
cleanly did a 3-way merge - whether upstream was one big smushed- 
together thing or actually contained that patch explicitly doesn't 
matter), then "rebase" just skips that patch, since it's not "necessary" 
any more.

If you actually want to keep your own cleaner history, you should really 
do a "git merge", not a rebase. That's kind of the fundamental difference 
between rebasing and merging: rebasing throws away the old history (and 
creates totally new commits to keep the stuff that wasn't there), while 
"merge" creates a *superset* of the two histories.

> I assume the commit objects are still in git somewhere but I'm not sure
> how to get at it. What I would like to ask git is "what did my git-log
> look like when 'mybranch' was based off master at A instead of B after O
> rebased?"

What you *can* do, is to do "rebase *and* merge" kind of operation, if 
you really want to.

Your history will look a bit odd, and you'll have unmerged commits always 
show up twice (or as many times as you do this operation, in fact - if you 
keep on doing it, and they don't get merged up-stream, they'll always be 
re-done over and over again). But you'll have *both* the rebase result 
*and* the merge result.

The way to do that would be to basically be something like this by having 
*three* branches rather than two: your CVS import branch (call it "cvs"), 
your "merged work" branch (call it "cvs-merged") and the branch you 
actually do development on (call it "master")

 - update the "CVS tracking branch"

	# something like this.. 
	git cvsimport -i -m -o cvs

 - switch to the "cvs-merged" branch, and merge your old changes *and* the 
   new CVS state into it, but merge it as the CVS state *only*:

	# reset the "cvs-merge" branch to the new "cvs" state
	git branch -f cvs-merge cvs

	# switch to it
	git checkout cvs

	# and merge your old "master" into it but only merge the history, 
	# not the actual contents (ie using the "ours" strategy)
	git merge -s ours master

 - now, go back to your development branch, and rebase the work you have 
   there into the cvs-merge branch that works as the "history branch"

	# switch back to the development branch (which doesn't have the merge)
	git checkout master

	# Now, rebase the stuff that was *not* int he original "cvs" 
	# branch, but is in your development branch, and put it on top of 
	# the merge you just did.
	git rebase --merge --onto cvs-merge cvs

which *should* mean that in the end you have your "master" branch that 
contains your old history *and* the CVS history merged, *and* on top of 
that merge it also has the patches that you had in your old history that 
weren't in the CVS tree.

(The above is just a rough idea - I'm not actually guaranteeing that it 
works, I didn't test it, I just wrote it up as an example. That last 
"rebase" in particular might need some work to make sure that it only 
rebases your new stuff since the last cvs-merge: I think it will do that 
as-is, but I've always found the "git rebase" command to have very 
non-intuitive semantics because it doesn't use the normal "range" 
operations to describe what to actually rebase).

You get the idea. Once you get that working, you can just script it. The 
whole point is that you can use a merge *and* a rebase to both save away 
your old history, *and* to then re-do the commits that weren't merged on 
top of it.

So you *can* keep both the history *and* rewrite it, but it will require 
you to do more work, and you'd have to experiment a bit (as mentioned, I 
really don't think that "git rebase" example I gave above necessaly works 
as-is - you might have to tweak it a bit to make sure that it rebases 
exactly the commits that have been done since the last cvs merge: it might 
involve using "git-merge-base" to figure out what the last merge was 
before you do the "git merge -s ours" thing etc etc)

		Linus