threads / discuss / 15571

Editing Git Log

Subject: Editing Git Log

## tl;dr

4 messages between Sep 18, 2008 and Sep 18, 2008.

replies: 3people: 4as markdown or json

Piet Delaney· Sep 18, 2008, 05:52 UTC · lore

I think I recall reading that a feature of git was the prevention of the git commits from being changed. I noticed today that a couple of us have checked in files without our customary [XTENSA] architecture prefixed to the 1st line of our Commit Messages.

I couldn't find a way to do this, other than our reverting back to a earlier repository and recommitting (each?) change with the slightly changed Commit Message; not an attractive investment of our time.

Any suggestions?

-piet

Boaz Harrosh· Sep 18, 2008, 06:13 UTC · re: Piet Delaney · lore

Re: Editing Git Log

Piet Delaney wrote:

Show 16 quoted lines

> I think I recall reading that a feature of git was the prevention of the 
> git commits
> from being changed. I noticed today that a couple of us have checked in 
> files
> without our customary [XTENSA] architecture prefixed to the 1st line of our
> Commit Messages.
> 
> I couldn't find a way to do this, other than our reverting back to a 
> earlier repository
> and recommitting (each?) change with the slightly changed Commit Message;
> not an attractive investment of our time.
> 
> Any suggestions?
> 
> -piet
> --

git rebase --interactive FIRST_BAD_COMMIT^ will effectively do the same as above but in a nice automated way. Just change pick => edit on these patches that need fixing, you'll see.

Boaz

Björn Steinbrink· Sep 18, 2008, 06:21 UTC · re: Boaz Harrosh · lore

Re: Editing Git Log

On 2008.09.18 09:13:50 +0300, Boaz Harrosh wrote:

Show 21 quoted lines

> Piet Delaney wrote:
> > I think I recall reading that a feature of git was the prevention of the 
> > git commits
> > from being changed. I noticed today that a couple of us have checked in 
> > files
> > without our customary [XTENSA] architecture prefixed to the 1st line of our
> > Commit Messages.
> > 
> > I couldn't find a way to do this, other than our reverting back to a 
> > earlier repository
> > and recommitting (each?) change with the slightly changed Commit Message;
> > not an attractive investment of our time.
> > 
> > Any suggestions?
> > 
> > -piet
> > --
> 
> git rebase --interactive FIRST_BAD_COMMIT^ will effectively do the same
> as above but in a nice automated way. Just change pick => edit on these
> patches that need fixing, you'll see.

git filter-branch with a suited msg-filter is even more automated :-)

Björn

Matthias Kestenholz· Sep 18, 2008, 06:21 UTC · re: Piet Delaney · lore

Re: Editing Git Log

On Thu, Sep 18, 2008 at 7:52 AM, Piet Delaney <piet.delaney@tensilica.com> wrote:

Show 14 quoted lines

> I think I recall reading that a feature of git was the prevention of the git
> commits
> from being changed. I noticed today that a couple of us have checked in
> files
> without our customary [XTENSA] architecture prefixed to the 1st line of our
> Commit Messages.
>
> I couldn't find a way to do this, other than our reverting back to a earlier
> repository
> and recommitting (each?) change with the slightly changed Commit Message;
> not an attractive investment of our time.
>
> Any suggestions?
>

You have to create new commits, but you do not have to do it by hand. See filter-branch[1]

The example given in the manpage removes the git-svn identifiers:

git filter-branch --msg-filter '
        sed -e "/^git-svn-id:/d"
'

You can probably modify the sed expression and use it nearly as is (of course you would not want to filter the whole history, only the handful commits that came from you or your team.

[1]: http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html