Re: git-log - hide parent (was: merging two equivalent branches)
- From
Christian Couder <chriscool@tuxfamily.org>
- Date
- Jan 8, 2010, 05:00 UTC
- Message-ID
- <201001080600.26088.chriscool@tuxfamily.org>
- In-Reply-To
- <DF05F91F-CBFD-458A-A99F-79E98ACA5146@gmail.com>
On jeudi 07 janvier 2010, David Reitter wrote:
Show 21 quoted lines
> 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.
Show 5 quoted lines
> 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.