From: Carl Worth <cworth@cworth.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Sixt <J.Sixt@eudaptics.com>, git@vger.kernel.org
Subject: Re: Merging commits together into a super-commit
Date: Thu, 10 May 2007 09:57:10 -0700 [thread overview]
Message-ID: <87wszg39cp.wl%cworth@cworth.org> (raw)
In-Reply-To: <alpine.LFD.0.98.0705100857450.3986@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
On Thu, 10 May 2007 09:01:15 -0700 (PDT), Linus Torvalds wrote:
> Clearly git can, but equally clearly it really *would* be pretty nice if
> you could just do
>
> git cherry-pick x y z
>
> and create one commit and have the message already somewhat done for you
> (and "git revert" doing the same).
Perhaps with a --squash option. I've already been wanting a
cherry-pick that accepts a range, but that makes separate commits.
Yes, I know there's some git-rebase thing that will do it, but I can
never remember the right syntax for that without studying the
documentation[*]. What I find myself wanting to type is just:
git cherry-pick A..B
But there is the whole problem of how to deal with any conflict that
appears during the process.
-Carl
[*] I do use one form of rebase without ever needing to consult the
documentation, but it's in the opposite "direction", if you will, from
the cherry-pick-a-range operation. I use it when I want to rebase a
set of commits from my current branch to some other branch, such as:
git rebase origin
Not surprisingly, what's common about both of the operations above is
that they are really only accepting a single argument, (a range in one
case, and a branch-name in the other). That's what makes for an
easy-to-use command. Things that require multiple branch names in a
particular order, or extra options, (see "git rebase --onto newbase
upstream branch"), need someone smarter than me to drive them.
Another problem is that using the optional final [<branch>] argument
to git-rebase makes it change the current branch, (which no other
git-rebase operation does), and that's another thing I find very
confusing.
I'm sure the most complex form of git-rebase solves some precise
problem that someone has, (and maybe even gets used regularly). But
it's got enough complications that I just ignore it, (and would
instead really prefer being able to just cherry-pick a whole range).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-05-10 16:57 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-10 10:51 Merging commits together into a super-commit Alex Bennee
2007-05-10 11:19 ` Raimund Bauer
2007-05-10 11:32 ` Alex Bennee
2007-05-10 11:43 ` Johannes Schindelin
2007-05-10 11:40 ` Johannes Sixt
2007-05-10 16:01 ` Linus Torvalds
2007-05-10 16:57 ` Carl Worth [this message]
2007-05-10 17:14 ` J. Bruce Fields
2007-05-10 18:30 ` Carl Worth
2007-05-10 19:21 ` Petr Baudis
2007-05-10 19:48 ` Carl Worth
2007-05-10 20:02 ` Using StGIT for tweaking already-committed stuff Petr Baudis
2007-05-10 21:16 ` Carl Worth
2007-05-11 5:48 ` Integrate StGIT into Git? (Was: Re: Using StGIT for tweaking already-committed stuff) Jan Hudec
2007-05-10 22:23 ` Using StGIT for tweaking already-committed stuff Karl Hasselström
2007-05-11 20:40 ` Yann Dirson
2007-05-11 22:43 ` Karl Hasselström
2007-05-12 7:10 ` Yann Dirson
2007-05-12 11:09 ` Karl Hasselström
2007-05-10 20:29 ` Merging commits together into a super-commit Robin Rosenberg
2007-05-12 11:34 ` Yann Dirson
2007-05-12 13:59 ` Jakub Narebski
2007-05-12 14:02 ` Karl Hasselström
2007-05-12 14:41 ` Yann Dirson
2007-05-12 17:03 ` Karl Hasselström
2007-05-12 19:27 ` Junio C Hamano
2007-05-13 18:43 ` Karl Hasselström
2007-05-13 19:35 ` Yann Dirson
2007-05-14 19:28 ` [StGIT PATCH] Store branch description in the config file Karl Hasselström
2007-05-10 19:22 ` Merging commits together into a super-commit J. Bruce Fields
2007-05-10 19:47 ` Petr Baudis
2007-05-10 19:51 ` J. Bruce Fields
2007-05-12 9:53 ` Transactions for git (and stgit) ? Yann Dirson
2007-05-12 10:49 ` Karl Hasselström
2007-05-12 18:34 ` Yann Dirson
-- strict thread matches above, loose matches on Subject: below --
2007-05-10 21:55 Merging commits together into a super-commit linux
2007-05-11 11:54 ` Alex Riesen
[not found] ` <9909dee80705110537j7e6d1426p7723c110c0a2c667@mail.gmail.com>
2007-05-11 12:41 ` Eugine Kosenko
2007-05-12 13:02 ` Jan Hudec
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=87wszg39cp.wl%cworth@cworth.org \
--to=cworth@cworth.org \
--cc=J.Sixt@eudaptics.com \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.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).