Re: [BUG] Cannot push some grafted branches

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@student.ethz.ch> writes:

> 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.)

I do not buy either of the above.  When you are replacing one with
something else, you ought to know what that something else is and
how to create it.  Editing a text file with an editor to replace
40-hex object names with another is not a more intuitive way for end
users, either (in other words, you are seeing this from the point of
view of somebody who *knows* the internal representation of Git
objects too much).

> * 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.

That is an irrelevant point when comparing the "go down to bare
metal replacing the object representation" vs "use the usual Git
tools the end users are already familiar with" approaches.  You will
encounter the issue you are raising if you make a newer commit a
parent of an existing child with an older commit timestamp, no
matter how you do the grafting.