"Philip Oakley" <philipoak...@iee.org> 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'
    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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to