All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.