Thomas Rast <trast@xxxxxxxxxxxxxxx> 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. -- 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