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.



-- 
Paul Richards

Hi Paul,

Paul Richards wrote:

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.

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 [off-list ref] 1272275407 -0500
  committer Jonathan Nieder [off-list ref] 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 [off-list ref]
  Signed-off-by: Jonathan Nieder [off-list ref]
  $ 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 [off-list ref] wrote:

Hi Paul,

Paul Richards wrote:

quoted

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.

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 [off-list ref] 1272275407 -0500
 committer Jonathan Nieder [off-list ref] 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 [off-list ref]
 Signed-off-by: Jonathan Nieder [off-list ref]
 $ 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

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



-- 
Paul Richards

Jonathan Nieder [off-list ref] writes:

Hi Paul,

Paul Richards wrote:

quoted

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.

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.

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).

-- 
Jakub Narebski
Poland
ShadeHawk on #git