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

From: Thomas Rast <trast@inf.ethz.ch>
Date: Aug 3, 2013, 15:46 UTC
Message-ID: <87zjsyydya.fsf@hexa.v.cablecom.net>
In-Reply-To: <24928554D0C34B4696DAD74F569E2E17@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 12 quoted lines

> 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