On jeudi 07 janvier 2010, David Reitter wrote: > On Jan 7, 2010, at 1:22 PM, Christian MICHON wrote: > > I recall asking a similar question in 2008, and the answer was to look > > at "git graft" and use "git filter-branch" to recreate history. > > Thanks, I've tried that and I recall that filter-branch wasn't willing to > rewrite just the recent history - at least in started going over all 100k > revisions at a very slow pace. > > I'm still unsure how, after the filter-branch, I would have some ancestor > from the B series so that future pulls from the remote work, while having > an ancestor from A, to make sure I can continue merging into C. If > history is rewritten, I'll get new revisions and lose ancestors. I'm > beginning to thing that the cutting and pasting I'd like is conceptually > impossible. > > So what one would need is to specify a "silent parent" for a revision > that is relevant w.r.t. future three-way merges, but indicates that the > history behind the silent parent is irrelevant and shouldn't be shown in > a git-log. The runaway parent would be guaranteed to _not_ contribute > any content to the tree of the child revision, as is the case with a > "merge ours". What you could perhaps do with "git replace" or a graft is to change the merge commit so that it has only one parent instead of 2. > This could be implemented as a way to mark a parent as silent (checked by > git-log at least), but one could also allow for an empty commit that, > while having a normal parent, clears out the tree. > > Let me know if this idea is completely crazy. -- This looks like the right thing to do using "git replace" or grafts. Best regards, Christian. -- 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