cherry-pick --message?

Hi all,

I have an slightly unusual usecase for cherry-pick:
I want to modify the commit message that is used in the process,
e.g. do an d/^PROP:/ on it, but unfortunately -m does something
else here.

And there is no --message here for good reason, as cherry-pick
can pick multiple commits and so on. Bad for me, though.

So, am I down to the combo of format-patch and apply, or is there
an easier way? (I'd also like to end up in the same state as with
cherry-pick should there be conflicts.)

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

On Tue, Mar 21, 2017 at 05:05:20PM +0100, Andreas Krey wrote:

Hi all,

I have an slightly unusual usecase for cherry-pick:
I want to modify the commit message that is used in the process,
e.g. do an d/^PROP:/ on it, but unfortunately -m does something
else here.

And there is no --message here for good reason, as cherry-pick
can pick multiple commits and so on. Bad for me, though.

So, am I down to the combo of format-patch and apply, or is there
an easier way? (I'd also like to end up in the same state as with
cherry-pick should there be conflicts.)

There's "cherry-pick --edit".

I had to look it up, though. For a single message I'd have probably done
"git cherry-pick $commit && git commit --amend". For multiple I'd just
cherry-pick them all first, then follow-up with "git rebase -i".

-Peff

On Tue, 21 Mar 2017 13:00:05 +0000, Jeff King wrote:
...

quoted

I have an slightly unusual usecase for cherry-pick:
I want to modify the commit message that is used in the process,
e.g. do an d/^PROP:/ on it, but unfortunately -m does something
else here.

...

There's "cherry-pick --edit".

Yes, but. I'm in a toolchain, not a user. I'm a command that let
the user cherry-pick specific things, and I need to edit out the things
that made the original commit eligible to be picked in the first place.

Can't quite rely on the tool's user to do that. :-(

I'm not familiar with the plumbing to know where to look there.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

On Tue, Mar 21, 2017 at 06:07:34PM +0100, Andreas Krey wrote:

quoted

There's "cherry-pick --edit".

Yes, but. I'm in a toolchain, not a user. I'm a command that let
the user cherry-pick specific things, and I need to edit out the things
that made the original commit eligible to be picked in the first place.

Can't quite rely on the tool's user to do that. :-(

I'm not familiar with the plumbing to know where to look there.

You can do:

  GIT_EDITOR='sed -i d/^PROP:/' git cherry-pick --edit

but if there's a conflict, the user has resume it with that environment
variable set. If you can rely on the user using your tool, that might
work. If they might run arbitrary git commands, then no.

Probably "format-patch | sed | am -3" is your best bet if you want to
modify the patches in transit _and_ have the user just use normal git
tools.

-Peff

On Tue, 21 Mar 2017 13:33:35 +0000, Jeff King wrote:
...

Probably "format-patch | sed | am -3" is your best bet if you want to
modify the patches in transit _and_ have the user just use normal git
tools.

Except that 'git am' doesn't have --no-commit like cherry-pick does. :-(
It's always something. (Perhaps I'm instead going to rewrite the commit
before cherry-picking it.)

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Andreas Krey wrote:

On Tue, 21 Mar 2017 13:33:35 +0000, Jeff King wrote:

quoted

Probably "format-patch | sed | am -3" is your best bet if you want to
modify the patches in transit _and_ have the user just use normal git
tools.

Except that 'git am' doesn't have --no-commit like cherry-pick does. :-(
It's always something. (Perhaps I'm instead going to rewrite the commit
before cherry-picking it.)

'git apply --index' can do that.  I agree that it would be sensible
for 'git am' to grow a --no-commit option to do that.

Thanks and hope that helps,
Jonathan