git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Carl Worth <cworth@cworth.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Johannes Sixt <J.Sixt@eudaptics.com>,
	git@vger.kernel.org
Subject: Re: Merging commits together into a super-commit
Date: Thu, 10 May 2007 15:22:12 -0400	[thread overview]
Message-ID: <20070510192212.GP13719@fieldses.org> (raw)
In-Reply-To: <87vef0350y.wl%cworth@cworth.org>

On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:
> So, compared to the rebase usage, this does add two commands for
> bookkeeping the original state and cleaning it up. But the syntax for
> the cherry-pick part is quite a bit simpler than the original rebase
> at least.

Yeah, something like that would be great.  I think I've seen others
suggest similar syntax before, so it's probably just a question of one
of us who want this finding time to write the patches.

> Also, "reset --hard" isn't actually what I want in this case. I'd like
> this recipe to use something that would move the current branch to
> some other point, but in a safe way, (that is, not destroy any
> uncommitted changes that might exist at the beginning). I don't have
> any proposal for what that would be.

The tag creation and cleanup could get to be annoying too.  You could
scrounge through the reflog instead of using a temporary tag, but
depending on the amount of --amend'ing and cherry-picking you do the
reflog entry may end up in a different place each time, so it's probably
hard to make this automatic.

> stg - This probably works great if you're using it as a primary
>       interface. But trying to use it as a quick one-off when
>       generally using core git does not work well at all. Instead of
>       the two "git tag" commands in my recipe above, an stg recipe
>       would involve a lot of additional bookkeeping with stg init, stg
>       uncommit [N times for fixing a commit N steps back in the
>       history], stg goto, stg push, etc.

I also didn't like having to come up with another name for each
patch--I'd rather just run git-log or gitk and cut-n-paste the sha1.

For kernel work I started out working with multiple (sym- or
hard-linked) trees, then used akpm's patch scripts, then stgit.  I think
I'm happiest just using plain git.

The one thing I've never been good at is keeping the history of the
patch series itself.

--b.

  parent reply	other threads:[~2007-05-10 19:22 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
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           ` J. Bruce Fields [this message]
2007-05-10 19:47             ` Merging commits together into a super-commit 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=20070510192212.GP13719@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=J.Sixt@eudaptics.com \
    --cc=cworth@cworth.org \
    --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).