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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]