Re: git replace: should it check for object type, and can it replace merges?

"Philip Oakley" [off-list ref] writes:

A recent comment http://stackoverflow.com/a/18027030/717355 on a
question I asked two years ago about 'grafts' and 'replace' indicates
that users think that 'git replace' can't replace a merge commit. The
documentation doesn't have any examples and gives the naive impression
that one should only replace a simple commit with another simple
commit.

Having looked at the code, I realised that anything can be replaced
with anything, which is perhaps not what was intended. A simple
thought is that the replace should be like-for-like with regard to
object type, though that would not include replacing a sub-module for
a tree (and vice versa).

Off hand I cannot come up with any case where you can replace one object
with one of a different type, keeping the history valid.

To back that up:

* Refs can be "replaced" simply by changing the ref itself.

* Annotated tags contain the type of the tagged object.

* The tree/parent lines in commits must be a tree and commits, resp.

* The object types referred to by trees are specified in the 'mode'
  field:
    100644 and 100755    blob
    160000               commit
    040000               tree
  (these are the only valid modes)

* Blobs don't point at anything.

So yes:

Should 'git replace' check the object types to ensure they are sensible?

I think that would be a very good thing to check.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch