Hi, On Tue, 27 Jun 2006, Martin Langhoff wrote: > On 6/27/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > > 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. I hoped that much. > > (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 Yes, I am lazy. > > 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 :-/ What do you mean? Is the patch-id of the cherry-picked different? (If there was a conflict which was manually resolved, I think there is no way we can detect that that patch was cherry-picked, but if it applied cleanly, the patch-id should be equal both in upstream and downstream.) Ciao, Dscho - : 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