From: Marc Weber <marco-oweber@gmx.de>
To: git <git@vger.kernel.org>
Subject: Re: cherry picking several patches at once
Date: Sat, 23 Jan 2010 01:24:06 +0100 [thread overview]
Message-ID: <1264205767-sup-4547@nixos> (raw)
In-Reply-To: <94a0d4531001221557n7a892f03u5e5d1c5e5ba5fea0@mail.gmail.com>
Hi,
I like both ideas. I fact I had both my self.
Cherry-picking a range can be implemented using a simple shell script.
So that is not that important.
> I think that would not be possible because of the challenges when
> dealing with conflicts.
If cherry-picking to a not checkout branch causes conflicts it could be
rejected. It's that simple.
The use case is: You have many topic-branches. Of course you develop on
the big temporary merge. However you want to push your changes to the
topic branches. You may be working on multiple topics at the same time.
Some of the topics may quick hacks to make a porject work on your system
such as patching shebang lines, change PHP require lines etc.
Currently you have to
git checkout topic1; git cherry-pick big-merge
git checkout topic2; git cherry-pick big-merge~2
git checkout big-merge
compare this to
git cherry-push HEAD topic1
git cherry-push HEAD~2 topic2
not much typing.
Very often there are no conflicts and you know that there are none.
If you have conflicts you can still fallback going the slow way.
Maybe the command could behave this way:
git cherry-push-checkout-on-failure hash other-branch
I'd be very happy about such a git cherry-push-checkout-on-failure
command. I'm not sure whether the command should be renamed. I did so
for fun.
Marc Weber
next prev parent reply other threads:[~2010-01-23 0:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 16:11 cherry picking several patches at once Felipe Balbi
2010-01-22 23:57 ` Felipe Contreras
2010-01-23 0:24 ` Marc Weber [this message]
2010-01-23 11:17 ` Sverre Rabbelier
2010-01-24 10:52 ` Felipe Balbi
2010-01-24 13:10 ` Felipe Contreras
2010-01-24 15:31 ` Marc Weber
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=1264205767-sup-4547@nixos \
--to=marco-oweber@gmx.de \
--cc=git@vger.kernel.org \
/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).