Skip to content
Snippets Groups Projects
  • Patrick Mézard's avatar
    d1afbf03e69a
    rebase: allow collapsing branches in place (issue3111) · d1afbf03e69a
    Patrick Mézard authored
    We allow rebase plus collapse, but not collapse only? I imagine people would
    rebase first then collapse once they are sure the rebase is correct and it is
    the right time to finish it.
    
    I was reluctant to submit this patch for reasons detailed below, but it
    improves rebase --collapse usefulness so much it is worth the ugliness.
    
    The fix is ugly because we should be fixing the collapse code path rather than
    the merge. Collapsing by merging changesets repeatedly is inefficient compared
    to what commit --amend does: commitctx(), update, strip. The problem with the
    latter is, to generate the synthetic changeset, copy records are gathered with
    copies.pathcopies(). copies.pathcopies() is still implemented with merging in
    mind and discards information like file replaced by the copy of another,
    criss-cross copies and so forth. I believe this information should not be lost,
    even if we decide not to interpret it fully later, at merge time.
    
    The second issue with improving rebase --collapse is the option should not be
    there to begin with. Rebasing and collapsing are orthogonal and a dedicated
    command would probably enable a better, simpler ui. We should avoid advertizing
    rebase --collapse, but with this fix it becomes the best shipped solution to
    collapse changesets.
    
    And for the record, available techniques are:
    - revert + commit + strip: lose copies
    - mq/qfold: repeated patching() (mostly correct, fragile)
    - rebase: repeated merges (mostly correct, fragile)
    - collapse: revert + tag rewriting wizardry, lose copies
    - histedit: repeated patching() (mostly correct, fragile)
    - amend: copies.pathcopies() + commitctx() + update + strip
    d1afbf03e69a
    History
    rebase: allow collapsing branches in place (issue3111)
    Patrick Mézard authored
    We allow rebase plus collapse, but not collapse only? I imagine people would
    rebase first then collapse once they are sure the rebase is correct and it is
    the right time to finish it.
    
    I was reluctant to submit this patch for reasons detailed below, but it
    improves rebase --collapse usefulness so much it is worth the ugliness.
    
    The fix is ugly because we should be fixing the collapse code path rather than
    the merge. Collapsing by merging changesets repeatedly is inefficient compared
    to what commit --amend does: commitctx(), update, strip. The problem with the
    latter is, to generate the synthetic changeset, copy records are gathered with
    copies.pathcopies(). copies.pathcopies() is still implemented with merging in
    mind and discards information like file replaced by the copy of another,
    criss-cross copies and so forth. I believe this information should not be lost,
    even if we decide not to interpret it fully later, at merge time.
    
    The second issue with improving rebase --collapse is the option should not be
    there to begin with. Rebasing and collapsing are orthogonal and a dedicated
    command would probably enable a better, simpler ui. We should avoid advertizing
    rebase --collapse, but with this fix it becomes the best shipped solution to
    collapse changesets.
    
    And for the record, available techniques are:
    - revert + commit + strip: lose copies
    - mq/qfold: repeated patching() (mostly correct, fragile)
    - rebase: repeated merges (mostly correct, fragile)
    - collapse: revert + tag rewriting wizardry, lose copies
    - histedit: repeated patching() (mostly correct, fragile)
    - amend: copies.pathcopies() + commitctx() + update + strip