Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> ... There was no actual developmet on branch
> "another", so all the commits went away, but it left the merge (because
> that's how --full-history works), which has now become pointless.
>
> So you should do a "merge cleanup" phase after running --full-history.
In short, you will end up with something like this:
.---. (side branch)
/ \
---A---B---C (merge)
The "merge clean-up" would conceptually be a simple operation.
Whenever you see a merge C, you look at its parents A and B, and
cull the ones that are reachable from other parents. You notice
that A is an ancestor of B, drop A from the parents of C, and
simplify the above down to:
---A---B---C (not-a-merge)
However, I suspect that this is impossible without making
--full-history with "merge clean-up" imply "limited".
In the case of filter-branch, it needs to use topo-order in
order to guarantee that all its parents commits have been
rewritten before rewriting a commit, so the traversal is already
limited.
It might be simpler for filter-branch to remove parents that are
ancestor of other parents ("git show-branch --independent" would
work well for this, I think), before feeding the list of mapped
parents to the parent-filter.
-
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
