|
Size: 1550
Comment:
|
Size: 2796
Comment: Clarify intent & aim of extension and provide more discussion
|
| Deletions are marked like this. | Additions are marked like this. |
| 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 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 22: | Line 22: |
| 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 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. |
| Line 24: | Line 24: |
| 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]]. | 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]]. |
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.
Contents
1. Status
This extension is not distributed with Mercurial.
Author: MarcusLindblom
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
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