Re: git-log - hide parent (was: merging two equivalent branches)

[Christian Couder <chriscool@tuxfamily.org>]

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.