Re: [Ksummit-discuss] [CORE TOPIC] kernel unit testing

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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.

> 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