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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 26, 2006, 23:00 UTC
Message-ID: <Pine.LNX.4.63.0606270057260.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <46a038f90606261550p145b20a6gbe960e0abc16e8a4@mail.gmail.com>

Hi,

On Tue, 27 Jun 2006, Martin Langhoff wrote:

Show 14 quoted lines

> On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> > 
> > On Tue, 27 Jun 2006, Martin Langhoff wrote:
> > 
> > > And it errors out with ignore-if-in-upstream:
> > >
> > >  $ ./git format-patch --ignore-if-in-upstream -o .patches origin master
> > >  fatal: Not a range.
> > 
> > Could you test with "origin..master" instead of "origin master"?
> 
> Funny you mention that! Now it works ;-) and it even produces the
> patches I would expect.

The funny thing is: I did something to account for the old syntax, but only if you specified _one_ ref, not _two_. It would be easy, but is it needed? (I.e. are your fingers so trained on it?)

Show 7 quoted lines

> There is something strange though. I have a repo with ~150 pending 
> patches to push, of which git-cherry spots ~100 as already merged 
> upstream. So the old git-format-patch.sh would spit 50 patches, and the 
> initial C version would do 150.
> 
> Now this version gives me 50 patches, regardless of
> --ignore-if-in-upstream. Is that expected?

Hell, no! Something is really wrong there.

What does "git-rev-list their..my | wc" say?

> Also, if the two heads are identical, it still says 'Fatal: Not a
> range", but that isn't so important.

This is a consequence of my being too lazy to support the old "theirs mine" syntax (see above).

Ciao, Dscho