git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).