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

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jun 27, 2006, 09:52 UTC
Message-ID: <46a038f90606270252p2beac88bo3cf7aa8d3845450c@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.63.0606271016450.29667@wbgn013.biozentrum.uni-wuerzburg.de>

On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

Show 8 quoted lines

> 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.
>
> >   $ 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...

Show 8 quoted lines

> >   $ ~/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