From: Petr Baudis <pasky@suse.cz>
To: git@vger.kernel.org
Cc: kkeil@suse.de
Subject: [Core GIT] Long-term cherrypicking
Date: Wed, 21 Sep 2005 18:40:15 +0200 [thread overview]
Message-ID: <20050921164015.GC21971@pasky.or.cz> (raw)
Hello,
I've been working out some workflow possibilities with Karsten Keil at
the SuSE Labs conference, and I'd like to see your opinions. His
position does not seem unique at all, so I'm a bit surprised that noone
solved this before, or at least I didn't find any documentation about
this in the tutorial and howtos (or perhaps I missed it?).
His situation is that he has some patches in the ISDN subsystem, a
public repository, but sends the patches over e-mail to Linus. So he is
something between the subsystem maintainer and individual developer in
the categories listed out in the tutorial. What should be his merging
strategy?
Since he has public repository, he cannot rebase, but he needs to
be cherrypicking. The trouble is, git-cherry really does not work
"through" merges now - it stops at his last merge with Linus. The
obvious solution would be something like this patch:
diff --git a/git-cherry.sh b/git-cherry.sh
--- a/git-cherry.sh
+++ b/git-cherry.sh
@@ -5,18 +5,22 @@
. git-sh-setup || die "Not a git archive."
-usage="usage: $0 "'[-v] <upstream> [<head>]
+usage="usage: $0 "'[-v] <upstream> [<head>] [<base>]
__*__*__*__*__> <upstream>
- /
- fork-point
+ / \
+ <base> \ fork-point
\__+__+__+__+__+__+__+__> <head>
Each commit between the fork-point and <head> is examined, and
-compared against the change each commit between the fork-point and
+compared against the change each commit between the <base> and
<upstream> introduces. If the change seems to be in the upstream,
it is shown on the standard output with prefix "+". Otherwise
it is shown with prefix "-".
+
+If no <base> is specified, it is assumed to be the same as fork-point.
+This is the case if you run git-cherry only before you merge the
+upstream.
'
case "$1" in -v) verbose=t; shift ;; esac
@@ -35,12 +39,16 @@ case "$#" in
2) upstream=`git-rev-parse --verify "$1"` &&
ours=`git-rev-parse --verify "$2"` || exit
;;
+3) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify "$2"` &&
+ base=`git-rev-parse --verify "$3"` || exit
*) echo >&2 "$usage"; exit 1 ;;
esac
# Note that these list commits in reverse order;
# not that the order in inup matters...
-inup=`git-rev-list ^$ours $upstream` &&
+[ -z "$base" ] && base=$ours
+inup=`git-rev-list ^$base $upstream` &&
ours=`git-rev-list $ours ^$upstream` || exit
tmp=.cherry-tmp$$
Then you would invoke it like
git cherry origin master forkpoint
where forkpoint is a tag pointing at the last known point in Linus'
branch when he had all my (well, Karsten's) patches integrated in his
tree. I tested it briefly and it seems to work - I suppose that I will
leave more testing to him. :-) If GIT wants to be even cooler, it could
remember the last forkpoint and automatically advance it.
Opinions?
PS: Perex hints over my shoulder that the ALSA guys are just manually
recording which patches were merged and which weren't. It's a shame that
GIT has no UI to do that for them if it can. Anyway, I'll be thinking
about if/how to implement the cherrypicking workflow support for Cogito.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
next reply other threads:[~2005-09-21 16:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 16:40 Petr Baudis [this message]
2005-09-21 20:57 ` [Core GIT] Long-term cherrypicking Junio C Hamano
2005-09-21 22:19 ` Petr Baudis
2005-09-21 23:26 ` Junio C Hamano
2005-09-22 8:31 ` Greg KH
2005-09-22 9:53 ` Catalin Marinas
2005-09-22 9:58 ` Petr Baudis
2005-09-22 10:17 ` Catalin Marinas
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=20050921164015.GC21971@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=kkeil@suse.de \
/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 NNTP newsgroup(s).