Junio C Hamano <[email protected]> writes:
> I do not understand why you even want to go in the harder route in
> the first place, only to complicate things?
>
> All you want to do is to craft a commit object that records a
> specific tree shape, has a set of parents you want, and has the log
> information you want. Once you have the commit, you can replace an
> unwanted commit with it.
[...]
> $ git checkout X^0 ;# detach
> $ git reset --soft A
> $ git commit -C X
[...]
> Is this not intuitive enough?
I still wouldn't recommend this approach in git-replace(1) for several
reasons:
* It does not generalize in any direction. For each field you may want
to change, you have to know a _specific_ way of getting just the
commit you want.
* More to the point of replacing the parent lists, while the above might
be expected of a slightly advanced git user, you get into deep magic
the second you want to fake a merge commit with an arbitrary
combination of parents. (No, you don't need to tell me how. I'm just
saying that fooling with either MERGE_HEAD or read-tree is not for
mere mortals.)
* The above potentially introduces clock skew into the repository, which
can trigger bugs (like rev-list accidentally missing out on some side
arm!) until we get around to implementing and using generation
numbers.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
