Re: cherry-pick --since ?

[Brandon Casey <casey@nrlssc.navy.mil>]

On Fri, 20 Apr 2007, Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Is there functionality to allow something akin to
>> a
>>    git cherry-pick --since <commit>
>>
>> or maybe syntax similar to git cherry where the upstream, head,
>> and limit can be specified. Or the .. syntax would work.
>>
>>
>> Here's my use case:
>>
>> Two branches, 'A' and 'B'.
>> 'A' is the master branch.
>> 'B' was forked some time ago and is in bug fix only mode.
>> Much of 'A' and 'B' are still the same, but there have been
>>   some intrusive changes made to 'A' that should not go into 'B'.
>
> You forgot to say "My objective is to make sure all the good
> fixes in B are forward ported to A" but I am assuming that is
> the case.

Yes, that is the case, but the flow is both ways. Other developers
may implement fixes in 'A', which must be backported to 'B'. They
don't care about 'B'.

>>   This is also why I can't just pull from 'B'. rebase may work,
>>   but then of course all of the commit id's change.
>
> I do not understand why you cannot merge 'B' into 'A'.  From the
> commit ancestry perspective, merging is exactly the right thing
> to do if your goal is to forward port all fixes in B to A.

I thought I recalled having problems with a different tree and a
similar situation, where a merge did not do what I expected. I'll
have to take a look at that one again and post a scenario if I
find one.

I just tried a pull from 'B' into 'A' with this tree, and it worked.
The need to cherry-pick from 'A' into 'B' still exists though. The
work around using format-patch that Alex suggested does work. Being
able to cherry-pick a range in a more direct way seems like it would
be useful though.

-brandon