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