From: Alejandro Colomar <alx@kernel.org>
To: phillip.wood@dunelm.org.uk
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: git-cherry-pick(1) -- path
Date: Sun, 12 May 2024 17:35:02 +0200 [thread overview]
Message-ID: <xnzks3eybwx5lj7vnf66pfacjvcn4anhgfe7fx3ljvtysxpsrv@tt2wvkwezh3l> (raw)
In-Reply-To: <fz7tgtvp6qp7h3vcaviibn3rktkwg5q4qjeuvmciejqn2m7uow@3o5hi6hdbkt5>
[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]
Hi,
On Sat, May 11, 2024 at 10:08:47PM GMT, Alejandro Colomar wrote:
> Hi Phillip,
>
> On Sat, May 11, 2024 at 04:01:18PM GMT, Phillip Wood wrote:
> > sequencer.c. If we go for the "write new trees and use those in the merge"
> > approach then we'd need to change do_pick_commit() to create the trees and
> > we'd probably want to change do_recursive_merge() to take trees rather than
> > commits. We'd also need to add a new pathspec member to struct replay_opts
> > to pass the pathspec around.
>
> I've been thinking this evening that since
> `git format-patch ... | git am -3` works so well, and since the behavior
> of cherry-pick -- path isn't so obvious (we're discussing different
> strategies), maybe we should just not do it. I fell in love with am -3.
In the end, I'm using the following:
$ git log --oneline 2024a..tz/main -- tzfile.5 tzselect.8 zic.8 zdump.8 \
| awk '{print $1}' \
| tac \
| while read c; do
git format-patch --stdout -1 $c -- tzfile.5 tzselect.8 z*.8 \
| sed '/^---$/s/^/\n/' \
| sed "/^---$/i Cherry-picked-from: tz.git $( \
git log -1 --oneline --abbrev=12 $c \
| awk '{print $1}' \
) (\"$( \
git log -1 --oneline $c \
| sed 's/[^ ]* //' \
)\")";
done \
| git am -3 -s;
And it works like a charm. If I had to spell that as a
git-cherry-pick(1) command, I'd say
`git cherry-pick -x -s 2024a..tz/main -- tzfile.5 tzselect.8 zic.8 zdump.8`
BTW, there's something I noticed when I had an accident (forgot to
tac(1) the commit list): the git-am(1) conflicts session isn't as good
as a cherry-pick one: it doesn't show which commits are being applied.
If you're in the middle of a 50-commit cherry-pick, it's hard to see
where it's going wrong. So maybe adding this functionallity to
git-cherry-pick(1) could be a good thing.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-05-12 15:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 22:32 git-cherry-pick(1) -- path Alejandro Colomar
2024-05-10 1:15 ` Junio C Hamano
2024-05-10 9:05 ` Alejandro Colomar
2024-05-10 10:00 ` Phillip Wood
2024-05-10 17:03 ` Junio C Hamano
2024-05-11 11:46 ` Alejandro Colomar
2024-05-11 15:01 ` Phillip Wood
2024-05-11 20:08 ` Alejandro Colomar
2024-05-12 15:35 ` Alejandro Colomar [this message]
2024-05-13 15:16 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xnzks3eybwx5lj7vnf66pfacjvcn4anhgfe7fx3ljvtysxpsrv@tt2wvkwezh3l \
--to=alx@kernel.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).