On Thu, Sep 15, 2016 at 4:06 PM, Konstantin Khomoutov <
> On Thu, 15 Sep 2016 02:18:17 -0700 (PDT)
> Maaartinus <maaarti...@gmail.com> wrote:
> > There's no really good solution for batch editing commit messages.
> > You can use interactive rebase, filter branch, or format patch, but
> > you never get a nice complete list of messages to edit. Maybe this
> > idea makes sense:
> > When rebasing interactively, I often see typos or other things, I'd
> > like to fix. I can use the "edit 1234567" line for this, but this
> > interacts with my original reason for rebasing. Fixing messages
> > immediately would be the best.
> Well, to be honest I wanted the same feature several times on various
> occasions. Looks like a quite natural thing to demand.
> Actually, in my case I just once edited the message of a commit right
> there in the rebase script -- assuming the change will be picked up
> (it has been not, of course). ;-)
Exactly this happens to me at least once in a month. I know it doesn't
work, but deep inside, I still hope. :D
> So allow to use a line like "message 1234567 My new message" working
> > just like "pick", but replacing the commit message.
> There's a problem with this approach.
> If all/most your commits have single-line commit messages you're either
> committing really tiny chunks of changes or your approach to explaining
> your work is seriously hosed: useful commits use the first line of
> their message as the title, and then go on explaining what the change
> does, and *why.*
For this, there's the second proposal: add an option to "rebase -i" making
the whole commit message appear in "git-rebase-todo". This would be
impractical for normal rebase, but perfect for batch commit message edits.
> And this naturally leads us to the "reword" action.
> I mean, displaying those "titles" of the commit messages is a really
> nice property of the rebase script constructor but you might have typos
> everywhere in the commit message, not only in its title line.
> So after some pondering your (and mine) idea looks as an optimization
> in a wrong place: it does not allow to sensibly verify whole commit
> messages anyway and hence falls short of really reaching a useful goal.
With my second proposal, it does.
> For this to work well, add an option to "rebase -i" making the whole
> > commit message appear in "git-rebase-todo".
> > I'm aware of "reword", but it's not exactly what I want.
> > What do you think?
> All-in-all, this list is not for discussing propositions like yours
> anyway: here, we help Git newbies solve their problems with Git; its
> development is discussed elsewhere -- on the main Git list.
> Please see  for more info.
OK, thank you. I'll think about it more and post an improved proposal there.
> PS: I'd use tags like "history" and "rebase", but I'm not allowed to.
> I'm sorry, but what does this sentence mean?
> Are you maybe talking about some feature of the Google Groups web
Exactly. I hate tagging things wrong.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.