On Fri, 2016-07-15 at 17:01 +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 non the man page it would get confused by modifications made to
> resolve conflicts.

I know, currently the matching is hard in the sha1 sums of the patch
less certain things which might change like line numbers.  However, we
use similarity matching in git merges to detect file moves, we could do
the same thing in git cherry to detect patches which look about the
same (probably we'd need some sort of flag to specify degree of
similarity).

> 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.

it does, just not by default, see -x option.

James


> 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
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss