git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* how to most effectively cherry pick by selective patch hunk?
@ 2021-02-09 13:58 Robert P. J. Day
  2021-02-09 16:39 ` Jeff King
  0 siblings, 1 reply; 5+ messages in thread
From: Robert P. J. Day @ 2021-02-09 13:58 UTC (permalink / raw)
  To: Git Mailing list


  (i'm looking for a solution not just for current git but, sadly,
going back to git-2.9.2, which is installed on my current contract
build system, and i have little authority to bump it up.)

  summary: made a couple dozen commits on branch, call it "oldb",
where i was relatively undisciplined about enforcing clean, modular
commits so i want to go back and clean things up -- refactor by
changing order, combining some trivial commits into one, breaking
large, unwieldy commits into smaller pieces, better commit messages
and so on, so i start a new branch "newb" at the same origin, and
here's the problem.

  every old commit consisted of adding a new patch to an existing
openembedded recipe, so every commit had two components:

  * a brand new patch file to be placed under "files/", and
  * adding a new line to SRC_URI variable, as in:

    SRC_URI += " \
	first.patch \
	second.patch \
	third.patch \
	... etc etc ...
    "

  i think you see the problem. a commit adding a brand new file will
never create a merge conflict, as it's a new file. but if i start
reordering commits, then the addition of that line to the .bbappend
file will *certainly* conflict as the patches will almost certainly be
renamed and in a different order.

  what would be great is some sort of "-p" (patch selection) option
with cherry-pick, but i don't see that.

  what would work for me is to auto-get the addition of the patch file
from the old branch, at which point i am more than happy to manually
fix the .bbappend file and manually do another commit. i'm thinking i
can just "git checkout" the new patch file from the old branch, and
take it from there.

  thoughts? am i overthinking this?

rday

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: how to most effectively cherry pick by selective patch hunk?
  2021-02-09 13:58 how to most effectively cherry pick by selective patch hunk? Robert P. J. Day
@ 2021-02-09 16:39 ` Jeff King
  2021-02-09 16:58   ` Robert P. J. Day
  2021-02-09 17:12   ` Andreas Schwab
  0 siblings, 2 replies; 5+ messages in thread
From: Jeff King @ 2021-02-09 16:39 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Git Mailing list

On Tue, Feb 09, 2021 at 08:58:06AM -0500, Robert P. J. Day wrote:

>   what would be great is some sort of "-p" (patch selection) option
> with cherry-pick, but i don't see that.

We have "checkout -p", but of course the problem there is that it's
picking out of the whole state of that commit. So you might see other
changes not introduced by that commit.

Conceptually, adding "cherry-pick -p" would be pretty easy. The strategy
for all of the "-p" options is to generate a diff, then feed that diff
to the patch-selection code, then apply whatever the user selects. For
"checkout -p $commit", that diff is the diff between $commit and our
current state. But for "cherry-pick -p", it would be the diff between
$commit^ and $commit.

Of course that involves a change to Git, and you were looking for
something you could do with existing versions. :) You can emulate it by
making the commit's parent equivalent to your current state. I.e.:

  git checkout --detach ;# detached HEAD for temporary commit
  git cherry-pick $commit ;# maybe deal with conflicts
  commit=$(git rev-parse --verify HEAD) ;# remember the temp commit
  git checkout - ;# back to your branch
  git checkout -p $commit

-Peff

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: how to most effectively cherry pick by selective patch hunk?
  2021-02-09 16:39 ` Jeff King
@ 2021-02-09 16:58   ` Robert P. J. Day
  2021-02-09 17:12   ` Andreas Schwab
  1 sibling, 0 replies; 5+ messages in thread
From: Robert P. J. Day @ 2021-02-09 16:58 UTC (permalink / raw)
  To: Jeff King; +Cc: Git Mailing list

On Tue, 9 Feb 2021, Jeff King wrote:

> On Tue, Feb 09, 2021 at 08:58:06AM -0500, Robert P. J. Day wrote:
>
> >   what would be great is some sort of "-p" (patch selection) option
> > with cherry-pick, but i don't see that.
>
> We have "checkout -p", but of course the problem there is that it's
> picking out of the whole state of that commit. So you might see
> other changes not introduced by that commit.

  this is probably what i'll use since i can use <pathspec> to grab
only the patch file from that commit, then add and commit it manually
from there.

rday

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: how to most effectively cherry pick by selective patch hunk?
  2021-02-09 16:39 ` Jeff King
  2021-02-09 16:58   ` Robert P. J. Day
@ 2021-02-09 17:12   ` Andreas Schwab
  2021-02-11  0:54     ` Elijah Newren
  1 sibling, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2021-02-09 17:12 UTC (permalink / raw)
  To: Jeff King; +Cc: Robert P. J. Day, Git Mailing list

On Feb 09 2021, Jeff King wrote:

> Of course that involves a change to Git, and you were looking for
> something you could do with existing versions. :) You can emulate it by
> making the commit's parent equivalent to your current state. I.e.:
>
>   git checkout --detach ;# detached HEAD for temporary commit
>   git cherry-pick $commit ;# maybe deal with conflicts
>   commit=$(git rev-parse --verify HEAD) ;# remember the temp commit
>   git checkout - ;# back to your branch
>   git checkout -p $commit

Alternatively, you could cherry-pick normally, then use
 git checkout -p HEAD^
to remove what you don't want.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: how to most effectively cherry pick by selective patch hunk?
  2021-02-09 17:12   ` Andreas Schwab
@ 2021-02-11  0:54     ` Elijah Newren
  0 siblings, 0 replies; 5+ messages in thread
From: Elijah Newren @ 2021-02-11  0:54 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Jeff King, Robert P. J. Day, Git Mailing list

On Tue, Feb 9, 2021 at 11:44 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Feb 09 2021, Jeff King wrote:
>
> > Of course that involves a change to Git, and you were looking for
> > something you could do with existing versions. :) You can emulate it by
> > making the commit's parent equivalent to your current state. I.e.:
> >
> >   git checkout --detach ;# detached HEAD for temporary commit
> >   git cherry-pick $commit ;# maybe deal with conflicts
> >   commit=$(git rev-parse --verify HEAD) ;# remember the temp commit
> >   git checkout - ;# back to your branch
> >   git checkout -p $commit
>
> Alternatively, you could cherry-pick normally, then use
>  git checkout -p HEAD^
> to remove what you don't want.

Or, going into the slightly esoteric, you could define a custom local
merge driver for the particular file you want to ignore and say that
merges of that file always use the original version and ignore changes
made on both sides.

man gitattributes(5), search for "filfre"

Appears to be unchanged since git-2.5.0.

Only ever used them once myself long ago (and not for a real usecase),
because I wanted to understand what they were for.  However, it seems
like they might be useful here.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-02-11  1:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-09 13:58 how to most effectively cherry pick by selective patch hunk? Robert P. J. Day
2021-02-09 16:39 ` Jeff King
2021-02-09 16:58   ` Robert P. J. Day
2021-02-09 17:12   ` Andreas Schwab
2021-02-11  0:54     ` Elijah Newren

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).