login
Header Space

 
 

Re: Edit log message after commit

Previous thread: First cut at git port to Cygwin by H. Peter Anvin on Wednesday, September 28, 2005 - 8:53 pm. (55 messages)

Next thread: [PATCH] Add git-symbolic-ref by Junio C Hamano on Thursday, September 29, 2005 - 12:24 am. (1 message)
To: <git@...>
Date: Wednesday, September 28, 2005 - 10:28 pm

Hi,

Is there any method to edit the log message after committed? I couldn't find any information in Documentation and in git mailing list.


Regards,
Kevin Leung

-
To: Kevin Leung <hysoka@...>
Cc: <git@...>
Date: Thursday, September 29, 2005 - 4:35 am

As the others said, a commit object is immutable but it can be
replaced with a new one and the path from HEAD changed. If you need to
do this often, have a look at StGIT. It allows you to create patches
as git commit objects and indefinitely edit them (both file changes
and commit information like log messages, author etc.).

In the latest snapshot, I also added a commit command to permanently
store the patches into the repository after which you won't be able to
edit them anymore (that's useful for maintainers using StGIT, not only
contributors).

-- 
Catalin

-
To: <git@...>
Date: Friday, September 30, 2005 - 3:58 am

Thanks Yashi and Catalin for the pointers. The information is exactly what
I was looking for. :-)

-
To: <git@...>
Date: Thursday, September 29, 2005 - 3:45 am

Thank you all of you. I was able to redo the commit.

But as Tony has pointed out. I would have needed to redo all the subsequent commits if I was to change non-HEAD commit message. What is the proper way of doing that? Is it the same as Documentation/howto/revert-branch-rebase.txt ?

One more question is that, how to use the git commit --reedit-message flag? According to Documentation/howto/rebase-and-edit.txt, I guess the meaning is to re-apply one commit to current HEAD?

-
To: Kevin Leung <hysoka@...>
Cc: <git@...>
Date: Thursday, September 29, 2005 - 12:05 pm

At Thu, 29 Sep 2005 15:45:49 +0800,

as pointed out by others, if the tree is already public, do revert.
otherwise, use git-cherry-pick and git-rebase might help.  but it
might not be a good idea. (don't know)

to illustrate this, create the following tree

c
|
b
|
a
|
initial

    git-init-db
    echo hello &gt; hello.c
    git-update-index --add hello.c
    git-commit -v -m 'initial'
    echo a &gt;&gt; hello.c
    git-commit -a -m 'add a'
    echo b &gt;&gt; hello.c
    git-commit -a -m 'add b'
    echo c &gt;&gt; hello.c
    git-commit -a -m 'add c'

say, you want to edit the commit message for 'add a'.

first, create new branch at where you wanna change the message

    git checkout -b temp HEAD^^^   # hmm... HEAD^3 doesn't work

cherry pick the 'add a' commit but don't commit yet

    git-cherry-pick -n master^^

commit the change with reediting the original commit log

    git commit --reedit master^^

rebase the _master_ to temp

    git-checkout master
    git-rebase temp

I'm pretty sure that there is better way to do it and these should be
easy to be scripted.

my two cents,
--
          yashi
-
To: Yasushi SHOJI <yashi@...>
Cc: <git@...>
Date: Friday, September 30, 2005 - 4:24 am

Because it should be spelled HEAD~3.  HEAD^3 is "the third
parent of HEAD" and usually does not exist, unless you are
talking about an Octopus merge of three or more branches.


-
To: Kevin Leung <hysoka@...>
Cc: <git@...>
Date: Thursday, September 29, 2005 - 12:58 am

The commit must be at the head, or else you can't change it without 
breaking the chain of following commits.  If you are using Cogito, use 
cg-admin-uncommit and then re-commit it.  Otherwise, create a new commit 
object for the same tree and parent(s) as the old commit, with the new 
message.  The new commit object is your new head.

--
				Brian Gerst
-
To: Kevin Leung <hysoka@...>
Cc: <git@...>
Date: Thursday, September 29, 2005 - 12:17 am

No.  Once a git object is created it is immutable (since its name is the
hash of its contents).  If you realise right after you make a commit that
you want to change the message, you would have to redo it ... use
git diff or git whatchanged to get the details and the diffs, then use
git reset to backup, and re-apply.

If you have made subsequent commits, then you'll have to back those
out and redo them too.

If you have published your tree, then it's better to live with the 'bad'
commit than try to re-write history.

-Tony
-
To: Kevin Leung <hysoka@...>
Cc: <git@...>
Date: Thursday, September 29, 2005 - 12:15 am

Undoing and re-committing can be done with the following
recipe.

There is a *big* *red* *warning*, though.  If you have already
made available the commit you are about to undo to others, and
later other people have made more commits on top of them,
merging their changes back to your repository would make the
commit history look a bit funny.  You could still do this
without damaging the repository.  This warning only applies to
the shape of the commit graph.

First, the easiest case.  Undoing and recommitting the latest
commit in the current branch.

(1) Run "git diff HEAD" and make sure that your working tree
    matches the latest commit you are about to undo.  Then:

    $ git reset --soft HEAD^

    This leaves the working tree intact (i.e. it still has what
    you to have in the commit you are "fixing").

(2) Optional.  If you wanted to make changes other than commit
    log, do your edit here in the working tree.  When done, run
    "git diff HEAD" to make sure the changes are what you want
    the "fixed" commit to have.

(3) Run:

    $ git commit -c ORIG_HEAD

    If you made changes in (2) and have not done
    "git-update-index" on them, you may want to add '-a' there.
    If you are just redoing the log message you probably would
    not.

    This gives you the editor with the log message from the
    commit you undone in step (1).  Do your edit and exit the
    editor as usual.

Look at the output in "gitk HEAD ORIG_HEAD" to understand what
happened.  You just rewound a commit, and made a different
commit.

Harder, more cumbersome case, is when you realize that you made
a mistake a several commits ago.  This is described in detail in
Documentation/howto/revert-branch-rebase.  Read it.

-
Previous thread: First cut at git port to Cygwin by H. Peter Anvin on Wednesday, September 28, 2005 - 8:53 pm. (55 messages)

Next thread: [PATCH] Add git-symbolic-ref by Junio C Hamano on Thursday, September 29, 2005 - 12:24 am. (1 message)
speck-geostationary