Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery

On 6/27/06, Johannes Schindelin [off-list ref] wrote:

Hi,

I just cloned your repo, and as far as I can tell, the latest commit is on
June 23rd. So your numbers should be the same as mine. But not all are.

Taht repo is on a machine at work, but it's possible that I've cherry
picked a new commit onto master that isn't on the publc repo yet.

The problem I see: from the 53 non-merges in nzvleportfolio (who makes up
your branch names anyway?), there are two already in upstream: e3f56c and
7e448c5c. So it really should be 51.

quoted

  $ git-rev-list svnhead..master  | wc -l
  61

Same on my repo.

And if you add --no-merges it'll give you 51 or 52, depending...

quoted

  $ ~/local/git/git-format-patch.sh  -o .patchesold svnhead master
  ...
  $ ls .patchesold | wc -l
  52

I guess this propagates from git-cherry. (Did not test here, since I do
not have an old git-format-patch.sh handy, and am too lazy to get the last
version from my git repo.)

I think I did something like

  git-cat-file blob v1.3.3:git-format-patch.sh > git-format-patch.sh
  chmod ugo+x git-format-patch.sh

But anyway, looking at your numbers I take it that the new format-patch
with --ignore-if-in-upstream has the same output as the old format-patch,
right?

It does, but it may be "right" even though it's not realising that
some of the patches were cherry picked. git-cherry doesn't either. So
that algorythm isn't so hot in this case :-/

I jumped to conclusions earlier because I called git format-patch with
the old syntax (theirs ours) and it gave me 186 patches, which may
very well be the whole repo history, like it did earlier with git
itself. I thought that 186 were the patches pending, and that
git-cherry was cutting that to 52. Not so: it was a syntax issue.
Sorry about the noise!

cheers,



martin