threads / discuss / 7509

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

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

## tl;dr

19 messages between Apr 4, 2007 and Apr 14, 2007.

replies: 18people: 8as markdown or json

Alex Bennee· Apr 4, 2007, 11:36 UTC · lore
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
Alex Riesen· Apr 4, 2007, 12:28 UTC · re: Alex Bennee · lore

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

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
Andy Parkins· Apr 4, 2007, 12:56 UTC · re: Alex Bennee · lore

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

On Wednesday 2007 April 04 12:36, Alex Bennee wrote:
Show 8 quoted lines
> 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
Linus Torvalds· Apr 4, 2007, 15:12 UTC · re: Alex Bennee · lore

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

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
Junio C Hamano· Apr 5, 2007, 05:25 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 11 quoted lines
> 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.

David Kågedal· Apr 5, 2007, 09:16 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Apr 5, 2007, 10:24 UTC · re: David Kågedal · lore

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

David Kågedal <davidk@lysator.liu.se> writes:
Show 12 quoted lines
> 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 ;-)
Show 5 quoted lines
> 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 ;-).
Brian Gernhardt· Apr 5, 2007, 14:53 UTC · re: Junio C Hamano · lore

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

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

Junio C Hamano <junkio@cox.net> writes:
Show 6 quoted lines
> 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
Alex Riesen· Apr 7, 2007, 10:54 UTC · re: Brian Gernhardt · lore

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

On 4/5/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
Show 6 quoted lines
> +--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.

Junio C Hamano· Apr 9, 2007, 11:07 UTC · re: Junio C Hamano · lore

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

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 */
Junio C Hamano· Apr 10, 2007, 22:39 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Apr 10, 2007, 22:39 UTC · re: Junio C Hamano · lore

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

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
Johannes Schindelin· Apr 14, 2007, 08:57 UTC · re: Junio C Hamano · lore

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

Hi,
On Tue, 10 Apr 2007, Junio C Hamano wrote:
Show 7 quoted lines
> 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

Junio C Hamano· Apr 10, 2007, 22:40 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Apr 10, 2007, 22:41 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Apr 9, 2007, 11:11 UTC · re: Junio C Hamano · lore

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

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;
Alex Bennee· Apr 11, 2007, 11:37 UTC · re: Linus Torvalds · lore

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

On Wed, 2007-04-04 at 08:12 -0700, Linus Torvalds wrote:
Show 11 quoted lines
> 
> 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
Linus Torvalds· Apr 11, 2007, 16:00 UTC · re: Alex Bennee · lore

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

On Wed, 11 Apr 2007, Alex Bennee wrote:
Show 8 quoted lines
> 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.
Show 10 quoted lines
> > 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

← back to recent threads