Differences between revisions 1 and 7 (spanning 6 versions)
Revision 1 as of 2010-11-27 02:07:30
Size: 1205
Comment:
Revision 7 as of 2010-12-08 22:02:08
Size: 2796
Comment: Clarify intent & aim of extension and provide more discussion
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= Extension Name = = RebaseIfExtension =
Line 4: Line 4:
This extension builds on the RebaseExtension but adds some simple logic that chooses a merge instead of a rebase if there are conflicts.

This is useful since manual merges are error prone and a merge commit more clearly expresses each side of the merge, and the merge resolution choices, than a rebase (which tends to bundle all the local changes and the merge ops together and giving little chance of a rollback.)

The background for this is described in [[http://stackoverflow.com/questions/4086724/how-do-i-check-for-potential-merge-rebase-conflicts-in-mercurial|this StackOverflow question]].
This extension builds on the RebaseExtension but adds some simple logic that chooses a merge instead of a rebase if there are any file conflicts.
Line 14: Line 10:
'''This extension is/is not distributed with Mercurial.''' '''This extension is not distributed with Mercurial.'''
Line 18: Line 14:
Download site: https://bitbucket.org/marcusl/ml-hgext/src/tip/rebaseif.py

Issue tracker: https://bitbucket.org/marcusl/ml-hgext/issues
 * Download site: https://bitbucket.org/marcusl/ml-hgext/src/tip/rebaseif.py
 * Issue tracker: https://bitbucket.org/marcusl/ml-hgext/issues
 * If you like it, drop a note here: https://www.ohloh.net/p/ml-hgext
Line 23: Line 19:

The extension provides both a new command {{{rebaseif}}} as well as a new option to pull {{{--rebaseif}}} that invoke the rebaseif procedure after pulling. (Similar to RebaseExtension 's --rebase option).

The extension's usefulness lies in the fact that, if one wants a linear history, rebase is a good tool. However, rebase is fraught with danger as the conflict resolution is (mostly) manual. The conflict resolution(s) one make for a rebase that are afterwards pushed can never be inspected manually. The "merge" changes are lost, as they are incorporated in the output from the rebase command.

Reverting to a merge is the safe choice, since the choices (mine, theirs or a combo) is preserved in the merge commit. This can then be inspected to see if any conflicts where resolved in an inappropriate way.

If you prefer doing merges all the time (which is safe), this is not an extension for you. The more linear revision history is preferred by some people, but we can do better than heedlessly rebasing everything. This extension aims to provide a middle ground that makes the safe choice automatically.

Note that problems caused by changes in different files still can make your build fail (or cause other bugs or errors), so rebasing is never _entirely_ safe. However, most of us find that it's a good tool for keeping the history graph human-parseable.

A rebase operation is in many senses very equivalent to hg pull --update (or svn update) with local changes. I.e. your local changes are merged with the incoming ones, and you may pray that it still works as intended. If we are pragmatic about it, most hard-to-detect-and-fix errors come from bad conflict resolutions, not unrelated file changes.

The origin for this extension came from [[http://stackoverflow.com/questions/4086724/how-do-i-check-for-potential-merge-rebase-conflicts-in-mercurial|this StackOverflow question]].

Line 32: Line 44:
== Usage ==

{{{
> hg rebaseif
}}}

{{{
> hg pull --rebaseif
}}}
Line 38: Line 60:
CategoryExtension CategoryExtensionsByOthers CategoryExtensionsByOthers

RebaseIfExtension

This extension builds on the RebaseExtension but adds some simple logic that chooses a merge instead of a rebase if there are any file conflicts.

1. Status

This extension is not distributed with Mercurial.

Author: MarcusLindblom

2. Overview

The extension provides both a new command rebaseif as well as a new option to pull --rebaseif that invoke the rebaseif procedure after pulling. (Similar to RebaseExtension 's --rebase option).

The extension's usefulness lies in the fact that, if one wants a linear history, rebase is a good tool. However, rebase is fraught with danger as the conflict resolution is (mostly) manual. The conflict resolution(s) one make for a rebase that are afterwards pushed can never be inspected manually. The "merge" changes are lost, as they are incorporated in the output from the rebase command.

Reverting to a merge is the safe choice, since the choices (mine, theirs or a combo) is preserved in the merge commit. This can then be inspected to see if any conflicts where resolved in an inappropriate way.

If you prefer doing merges all the time (which is safe), this is not an extension for you. The more linear revision history is preferred by some people, but we can do better than heedlessly rebasing everything. This extension aims to provide a middle ground that makes the safe choice automatically.

Note that problems caused by changes in different files still can make your build fail (or cause other bugs or errors), so rebasing is never _entirely_ safe. However, most of us find that it's a good tool for keeping the history graph human-parseable.

A rebase operation is in many senses very equivalent to hg pull --update (or svn update) with local changes. I.e. your local changes are merged with the incoming ones, and you may pray that it still works as intended. If we are pragmatic about it, most hard-to-detect-and-fix errors come from bad conflict resolutions, not unrelated file changes.

The origin for this extension came from this StackOverflow question.

3. Configuration

Configure your .hgrc to enable the extension by adding following lines:

[extensions]
rebaseif = path/to/rebaseif.py

4. Usage

> hg rebaseif

> hg pull --rebaseif

5. See also


CategoryExtensionsByOthers

RebaseIfExtension (last edited 2012-02-15 22:36:20 by ks3095497)