All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: esr@thyrsus.com, git@vger.kernel.org
Subject: Re: RFC - "git editlog" feature for fixing up local commit messages
Date: Tue, 30 Mar 2010 10:52:42 +0200	[thread overview]
Message-ID: <4BB1BBDA.2050102@drmicha.warpmail.net> (raw)
In-Reply-To: <32541b131003291314r2f5a77e8g28e79b5983821e41@mail.gmail.com>

Avery Pennarun venit, vidit, dixit 29.03.2010 22:14:
> On Mon, Mar 29, 2010 at 9:31 AM, Eric Raymond <esr@thyrsus.com> wrote:
>> My editcomment script, as it exists, has a technical problem...the
>> editor needs to be something like emacsclient that actually invokes in
>> a different X window, otherwise whatever it writes to stdout will end
>> up stuffed in the comment along with the text I actually wanted to put
>> there.  The underlying problem is that git-filter-branch is sort of a
>> nuclear-powered chainsaw - gets the job done, but in a way that is
>> prone to messy side effects.  A more elegant implementation would
>> probably need to tie deeper into the plumbing.
> 
> It ought to be easy to work around this; simply extract the log
> message *before* filter-branch using something like
> 
>        git cat-file commit HEAD | tail -n +6 >msg.tmp
> 
> (I'm sure someone will correct me by providing a less revolting way to
> extract the commit message, but it's somehow not coming to me right
> now.)
> 
> Then launch $EDITOR to edit the message, then inside the
> filter-branch, just use that file instead of launching the editor.
> 
> Alternatively, in case you want the option of editing *multiple*
> commit messages at once, you could just redirect stdin/stdout to
> /dev/tty.
> 
> A further option would be to extend git-rebase--interactive.sh (yes,
> it's just a shell script) to take an option that makes a given commit
> (or commits) 'reword' by default instead of 'pick'.  And maybe another
> option to make git-rebase--interactive.sh not actually pop up an
> editor before it starts running.  Then your editcommit script could
> just be a thin wrapper around rebase with those options.

I think the OP's point was that filter-branch is better at keeping
merges in place; I'm not sure if this is true when rebase-i is used with
reword only.

> <insert obligatory wistful reference to git-sequencer> (I don't
> actually know anything about git-sequencer.)

Oh yeah:)

Michael

  reply	other threads:[~2010-03-30  8:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 13:31 RFC - "git editlog" feature for fixing up local commit messages Eric Raymond
2010-03-29 13:41 ` Sverre Rabbelier
2010-03-29 15:08   ` Nicolas Pitre
2010-03-29 20:14 ` Avery Pennarun
2010-03-30  8:52   ` Michael J Gruber [this message]
2010-03-30 18:36     ` Avery Pennarun
2010-03-30 23:11       ` Jonathan Nieder
2010-03-30  5:46 ` Miles Bader

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=4BB1BBDA.2050102@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=apenwarr@gmail.com \
    --cc=esr@thyrsus.com \
    --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 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.