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
if "git cherry" used that to understand that two commits where "the
same", then it would be a lot closer.

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,
NeilBrown