Alter parent ID of existing commit object

Hi, Is it possible to edit an old commit object and only alter the ID of the parent commit but otherwise leave all the other information intact (tree, message, authors, date, etc).

I'd expect such a command to return the new hash of the modified commit.

Hi Paul,

Paul Richards wrote:

The standard answer to this question is to say “use grafts and filter-branch”. The git-filter-branch(1) man page explains this approach. It is very powerful, but sometimes I do not want to have that much power.

So I will tell a secret: in the scenarios when I wanted something like this (actually, what I have occasionally wanted is to transform a single-parent commit into a merge), I did something like the following:

  $ git cat-file commit $rev
  tree dcd2cc4b76f8756423f5c1ab7d2c62d458a8b15f
  parent 5f1e6d9ce35e212708f9adc55e6b9a7e0d296df4
  author Will Palmer <wmpalmer@gmail.com> 1272275407 -0500
  committer Jonathan Nieder <jrnieder@gmail.com> 1272275443 -0500
  
  pretty: Respect --abbrev option
  
  Prior to this, the output of git log -1 --format=%h was always 7
  characters long, without regard to whether --abbrev had been passed.
  
  Signed-off-by: Will Palmer <wmpalmer@gmail.com>
  Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
  $ git cat-file commit $rev >tmp
  $ sed -i -e "s/parent .*/parent $(git rev-parse othercommit)/" tmp
  $ git hash-object -t commit -w tmp
  ca55c560685284ac6d121939b2cd881f426e7074

Easy. Still, I would be happy to see this packaged in a command, so I could recommend it in combination with ‘git replace’ to people who are scared of sed.

Thanks for bringing it up. Jonathan

On 26 April 2010 11:38, Jonathan Nieder <jrnieder@gmail.com> wrote:

Thanks, this looks perfect. I knew about "cat-file", but "hash-object" was the missing command for me here. :)

Jonathan Nieder <jrnieder@gmail.com> writes:

This also rewrites history up from the changed commit, which is something that you need to take into account. It is IMVHO best solution if rewritten part of history was not published, e.g. in the case of private repository / private development.

In the case of already published history you can use "git replace" mechanism instead (with git-cat-file + git-hash-object).

Grafts _without_ using "git filter-branch" do not rewrite history, but are not transferrable. The modern 'refs/replaces/*' mechanism is.

Just FYI, as I guess in your situation grafts+git-filter-branch would be best solution (after running git-filter-branch you can remove graft).