On 6/27/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > $ 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...
> $ ~/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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html