On Fri, Jul 15 2016, Dmitry Torokhov wrote:

> On Fri, Jul 15, 2016 at 05:01:33PM +1000, NeilBrown wrote:
>> On Fri, Jul 15 2016, James Bottomley wrote:
>> 
>> > On Fri, 2016-07-15 at 15:52 +1000, NeilBrown wrote:
>> >> I do find quilt useful when backporting a series of patches so that I
>> >> can resolve the conflicts on each patch individually and move 
>> >> backwards and forwards through the list of patches.  I don't think 
>> >> git has an easy way to store a branch of patches-that-I-need-to-apply 
>> >> and to then give me one at a time, removing them from the branch.  I 
>> >> could use 'stgit' for that if necessary, though it is very tempting 
>> >> to write something that is better integrated with git.
>> >
>> > Git cherry and git cherry-pick can do this.  Git cherry-pick can take a
>> > range of patches to apply, so you can select a bunch of patches to
>> > backport or otherwise move all at once.  Git cherry can tell you (to
>> > within an approximation, since it uses matching) what patches are
>> > common between two branches even if they have differing commit ids.
>> >
>> > The format is a bit frightening if you're not used to it, which is why
>> > stgit may be a better user experience, but you can do it with basic
>> > git.
>> 
>> I wasn't aware of "git cherry".  It certainly could be useful, but based
>> on the man page it would get confused by modifications made to resolve
>> conflicts.
>> If "get cherry-pick" auto-added an "upstream HASHID" line to the comment, and
>
> "git cherry-pick -x <commit>" does this.

 From the man page
     This is done only for cherry picks without conflicts.
 making it fairly useless for my use-case.

 Thanks anyway,
 NeilBrown


>
>> if "git cherry" used that to understand that two commits where "the
>> same", then it would be a lot closer.
>
> That would be nice.
>
>> 
>> Then a command, maybe "git cherry-pick" with no args, which did the
>> equivalent of: 
>>   git cherry-pick `git cherry | head -n1`
>> 
>> would almost work for "quilt push", and the "git rerere" thing (which I
>> almost understand) would mean that "git reset --hard HEAD^" would work
>> for "git pop" (or "git cherry-pop").
>> 
>> I'd probably want some way to record the upstream and limit commits for
>> a particular session.  e.g.
>>    git cherry start XX YY
>> 
>> then "git cherry-pick" and "git cherry-pop" would DoTheRightThing.
>> Maybe.
>> 
>
> Thanks.
>
> -- 
> Dmitry