From: Martin Langhoff Date: Tue, 27 Jun 2006 09:52:21 GMT Subject: Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery Message-ID: <46a038f90606270252p2beac88bo3cf7aa8d3845450c@mail.gmail.com> In-Reply-To: On 6/27/06, Johannes Schindelin 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