From: Thomas Rast <trast@student.ethz.ch>
Date: Wed, 19 Dec 2012 13:12:56 GMT
Subject: Re: [BUG] Cannot push some grafted branches
Message-ID: <87ip7yp4mf.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <7vehinibpc.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@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
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