Junio C Hamano <gits...@pobox.com> 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

* 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

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