Summary

Update Mercurial to support multi-commit patches via the new Patcher API.

Review Request #14239 — Created Nov. 10, 2024 and updated Nov. 16, 2024, 12:14 a.m.

Information

Owner

chipx86

Repository

RBTools

Branch

release-5.x

Bugs

Depends On

Reviewers

Groups

rbtools

People

Description

Mercurial has some restrictions on how patches may be applied. Unlike
Git, Subversion, etc., hg import will not apply a patch if there are
changes in the working directory. This means that a group of patches
must be applied in one go, and not one-by-one. Our old patching model
didn't allow for this level of control, and this was the reason the new
Patcher API was created.

The Patcher API is now used to apply patches without commits, and with
commits. It supports Git-style and Mercurial-style diffs.

When applying patches without committing, we open all the patches and
then pass their filenames directly to hg import, allowing it to apply
them all without hitting the working directory changes error.

When applying with committing, we use the standard Patcher logic to
manage the patches, and then patch each patch using hg import
individually. While hg import does support committing as part of the
patch operation, we instead use our existing commit-creation
functionality in order to utilize common logic and checks.

Conflicts are tracked, as Mercurial uses the standard patch tool's
output for conflict information. We apply using hg diff --partial,
which will apply what changes it can while leaving the user responsible
for applying the rest, keeping with the behavior in most other SCMs.

Some notable limitations are that we can't revert or squash commits in
Mercurial, and we generally don't have commit message or author
information in the patches (requiring defaults to be used based on the
review request). If applying Hg-style diffs, empty files won't be
represented, so Git-style diffs are recommended.

Squashing may be able to be resolved through further updates to RBTools
(by applying and amending each commit in succession), but would require
additional changes to the API for creating commits. We're leaving it off
for now.

There may be some other peculiarities of Mercurial's patching, and this
will likely need some changes based on usage in production.

Testing Done

Unit tests passed.

Commits

Summary	ID
Update Mercurial to support multi-commit patches via the new Patcher API. Mercurial has some restrictions on how patches may be applied. Unlike Git, Subversion, etc., `hg import` will not apply a patch if there are changes in the working directory. This means that a group of patches must be applied in one go, and not one-by-one. Our old patching model didn't allow for this level of control, and this was the reason the new Patcher API was created. The Patcher API is now used to apply patches without commits, and with commits. It supports Git-style and Mercurial-style diffs. When applying patches without committing, we open all the patches and then pass their filenames directly to `hg import`, allowing it to apply them all without hitting the working directory changes error. When applying with committing, we use the standard Patcher logic to manage the patches, and then patch each patch using `hg import` individually. While `hg import` does support committing as part of the patch operation, we instead use our existing commit-creation functionality in order to utilize common logic and checks. Conflicts are tracked, as Mercurial uses the standard patch tool's output for conflict information. We apply using `hg diff --partial`, which will apply what changes it can while leaving the user responsible for applying the rest, keeping with the behavior in most other SCMs. Some notable limitations are that we can't revert or squash commits in Mercurial, and we generally don't have commit message or author information in the patches (requiring defaults to be used based on the review request). If applying Hg-style diffs, empty files won't be represented, so Git-style diffs are recommended. Squashing may be able to be resolved through further updates to RBTools (by applying and amending each commit in succession), but would require additional changes to the API for creating commits. We're leaving it off for now. There may be some other peculiarities of Mercurial's patching, and this will likely need some changes based on usage in production.	6d3b736fefac72c4f5d8a0ee166f97ea780a46ff

Summary

Update Mercurial to support multi-commit patches via the new Patcher API.

Mercurial has some restrictions on how patches may be applied. Unlike Git, Subversion, etc., `hg import` will not apply a patch if there are changes in the working directory. This means that a group of patches must be applied in one go, and not one-by-one. Our old patching model didn't allow for this level of control, and this was the reason the new Patcher API was created. The Patcher API is now used to apply patches without commits, and with commits. It supports Git-style and Mercurial-style diffs. When applying patches without committing, we open all the patches and then pass their filenames directly to `hg import`, allowing it to apply them all without hitting the working directory changes error. When applying with committing, we use the standard Patcher logic to manage the patches, and then patch each patch using `hg import` individually. While `hg import` does support committing as part of the patch operation, we instead use our existing commit-creation functionality in order to utilize common logic and checks. Conflicts are tracked, as Mercurial uses the standard patch tool's output for conflict information. We apply using `hg diff --partial`, which will apply what changes it can while leaving the user responsible for applying the rest, keeping with the behavior in most other SCMs. Some notable limitations are that we can't revert or squash commits in Mercurial, and we generally don't have commit message or author information in the patches (requiring defaults to be used based on the review request). If applying Hg-style diffs, empty files won't be represented, so Git-style diffs are recommended. Squashing may be able to be resolved through further updates to RBTools (by applying and amending each commit in succession), but would require additional changes to the API for creating commits. We're leaving it off for now. There may be some other peculiarities of Mercurial's patching, and this will likely need some changes based on usage in production.

6d3b736fefac72c4f5d8a0ee166f97ea780a46ff

Issues

Description	From	Last Updated
svn patch -> hg patch	david	Nov. 13, 2024, 4:29 p.m.
if -> If	david	Nov. 13, 2024, 4:29 p.m.
hg import is the real command, patch is just an alias. Help: import	brennie	Nov. 13, 2024, 4:28 p.m.
Missing docs.	maubin	Nov. 16, 2024, 12:13 a.m.

flake8 passed.

JSHint passed.

rbtools/clients/mercurial.py (Diff revision 1)
The issue has been resolved. Show all issues
```
svn patch -> hg patch
```
rbtools/clients/mercurial.py (Diff revision 1)
The issue has been resolved. Show all issues
```
if -> If
```

You technically can squash hg commits. The rebase extension ships with Mercurial, but it is not enabled by default. However, you can enable it during a single hg invocation by doing hg --config extensions.rebase=.

So you can squash the range a::b into a single commit based on c with hg --config extensions.rebase= rebase -r a::b -d c --collapse

Rebase extension docs

chipx86 Nov. 12, 2024, 11:21 p.m.

Is this safe for us to hard-code this support in there?

So we'd need to apply individual commits and then rebase that range of commits, correct?

brennie Nov. 13, 2024, 7:32 a.m.

Yes you would have to apply individual commits and then rebase at the end.
Alternatively and probably more safe is to use commit --amend to apply subsequent commits, e.g.,

hg import --no-commit /tmp/patch1.diff
hg commit -m "message"
hg import --no-commit /tmp/patch2.diff
hg commit --amend
hg import --no-commit /tmp/patch3.diff
hg commit --amend


Although it looks like hg import also supports supplying multiple patch files on the command line so you should be able to do

hg import --no-commit /tmp/patch1.diff /tmp/patch2.diff /tmp/patch3.diff ...
hg commit -m "message"

chipx86 Nov. 13, 2024, 2:24 p.m.

Ah yeah that'd work. Worth considering, though it may skip 5.1 just due to scheduling and other work.

rbtools/clients/tests/test_mercurial.py (Diff revision 1)
The issue has been resolved. Show all issues
```
hg import is the real command, patch is just an alias. Help: import
```

Change Summary:


Switched hg patch to hg import everywhere.
Fixed typos in the docs.

Description:

		Mercurial has some restrictions on how patches may be applied. Unlike
~		Git, Subversion, etc., `hg patch` will not apply a patch if there are
	~	Git, Subversion, etc., `hg import` will not apply a patch if there are
		changes in the working directory. This means that a group of patches
		must be applied in one go, and not one-by-one. Our old patching model
		didn't allow for this level of control, and this was the reason the new
		Patcher API was created.

		The Patcher API is now used to apply patches without commits, and with
		commits. It supports Git-style and Mercurial-style diffs.

		When applying patches without committing, we open all the patches and
~		then pass their filenames directly to `hg patch`, allowing it to apply
	~	then pass their filenames directly to `hg import`, allowing it to apply
		them all without hitting the working directory changes error.

		When applying with committing, we use the standard Patcher logic to
~		manage the patches, and then patch each patch using `hg patch`
~		individually. While `hg patch` does support committing as part of the
	~	manage the patches, and then patch each patch using `hg import`
	~	individually. While `hg import` does support committing as part of the
		patch operation, we instead use our existing commit-creation
		functionality in order to utilize common logic and checks.

		Conflicts are tracked, as Mercurial uses the standard patch tool's
		output for conflict information. We apply using `hg diff --partial`,
		which will apply what changes it can while leaving the user responsible
		for applying the rest, keeping with the behavior in most other SCMs.

		Some notable limitations are that we can't revert or squash commits in
		Mercurial, and we generally don't have commit message or author
		information in the patches (requiring defaults to be used based on the
		review request). If applying Hg-style diffs, empty files won't be
		represented, so Git-style diffs are recommended.

	+	Squashing may be able to be resolved through further updates to RBTools
	+	(by applying and amending each commit in succession), but would require
	+	additional changes to the API for creating commits. We're leaving it off
	+	for now.
	+
		There may be some other peculiarities of Mercurial's patching, and this
		will likely need some changes based on usage in production.

Commits:

	Summary	ID
	Update Mercurial to support multi-commit patches via the new Patcher API. Mercurial has some restrictions on how patches may be applied. Unlike Git, Subversion, etc., `hg patch` will not apply a patch if there are changes in the working directory. This means that a group of patches must be applied in one go, and not one-by-one. Our old patching model didn't allow for this level of control, and this was the reason the new Patcher API was created. The Patcher API is now used to apply patches without commits, and with commits. It supports Git-style and Mercurial-style diffs. When applying patches without committing, we open all the patches and then pass their filenames directly to `hg patch`, allowing it to apply them all without hitting the working directory changes error. When applying with committing, we use the standard Patcher logic to manage the patches, and then patch each patch using `hg patch` individually. While `hg patch` does support committing as part of the patch operation, we instead use our existing commit-creation functionality in order to utilize common logic and checks. Conflicts are tracked, as Mercurial uses the standard patch tool's output for conflict information. We apply using `hg diff --partial`, which will apply what changes it can while leaving the user responsible for applying the rest, keeping with the behavior in most other SCMs. Some notable limitations are that we can't revert or squash commits in Mercurial, and we generally don't have commit message or author information in the patches (requiring defaults to be used based on the review request). If applying Hg-style diffs, empty files won't be represented, so Git-style diffs are recommended. There may be some other peculiarities of Mercurial's patching, and this will likely need some changes based on usage in production.	a1c2f56f08c23d1e67bb1421e72652b867d8b722
	Update Mercurial to support multi-commit patches via the new Patcher API. Mercurial has some restrictions on how patches may be applied. Unlike Git, Subversion, etc., `hg import` will not apply a patch if there are changes in the working directory. This means that a group of patches must be applied in one go, and not one-by-one. Our old patching model didn't allow for this level of control, and this was the reason the new Patcher API was created. The Patcher API is now used to apply patches without commits, and with commits. It supports Git-style and Mercurial-style diffs. When applying patches without committing, we open all the patches and then pass their filenames directly to `hg import`, allowing it to apply them all without hitting the working directory changes error. When applying with committing, we use the standard Patcher logic to manage the patches, and then patch each patch using `hg import` individually. While `hg import` does support committing as part of the patch operation, we instead use our existing commit-creation functionality in order to utilize common logic and checks. Conflicts are tracked, as Mercurial uses the standard patch tool's output for conflict information. We apply using `hg diff --partial`, which will apply what changes it can while leaving the user responsible for applying the rest, keeping with the behavior in most other SCMs. Some notable limitations are that we can't revert or squash commits in Mercurial, and we generally don't have commit message or author information in the patches (requiring defaults to be used based on the review request). If applying Hg-style diffs, empty files won't be represented, so Git-style diffs are recommended. Squashing may be able to be resolved through further updates to RBTools (by applying and amending each commit in succession), but would require additional changes to the API for creating commits. We're leaving it off for now. There may be some other peculiarities of Mercurial's patching, and this will likely need some changes based on usage in production.	7203be5ee101f08fc3280d5d0392510e3c75169e

Diff:

Revision 2 (+2110 -418)

Show changes

	rbtools/clients/mercurial.py
	rbtools/clients/tests/test_mercurial.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

rbtools/clients/tests/test_mercurial.py (Diff revision 2)
The issue has been resolved. Show all issues
```
Missing docs.
```

Change Summary:

Added missing docs for setUp().

Commits:

	Summary	ID
	Update Mercurial to support multi-commit patches via the new Patcher API. Mercurial has some restrictions on how patches may be applied. Unlike Git, Subversion, etc., `hg import` will not apply a patch if there are changes in the working directory. This means that a group of patches must be applied in one go, and not one-by-one. Our old patching model didn't allow for this level of control, and this was the reason the new Patcher API was created. The Patcher API is now used to apply patches without commits, and with commits. It supports Git-style and Mercurial-style diffs. When applying patches without committing, we open all the patches and then pass their filenames directly to `hg import`, allowing it to apply them all without hitting the working directory changes error. When applying with committing, we use the standard Patcher logic to manage the patches, and then patch each patch using `hg import` individually. While `hg import` does support committing as part of the patch operation, we instead use our existing commit-creation functionality in order to utilize common logic and checks. Conflicts are tracked, as Mercurial uses the standard patch tool's output for conflict information. We apply using `hg diff --partial`, which will apply what changes it can while leaving the user responsible for applying the rest, keeping with the behavior in most other SCMs. Some notable limitations are that we can't revert or squash commits in Mercurial, and we generally don't have commit message or author information in the patches (requiring defaults to be used based on the review request). If applying Hg-style diffs, empty files won't be represented, so Git-style diffs are recommended. Squashing may be able to be resolved through further updates to RBTools (by applying and amending each commit in succession), but would require additional changes to the API for creating commits. We're leaving it off for now. There may be some other peculiarities of Mercurial's patching, and this will likely need some changes based on usage in production.	7203be5ee101f08fc3280d5d0392510e3c75169e
	Update Mercurial to support multi-commit patches via the new Patcher API. Mercurial has some restrictions on how patches may be applied. Unlike Git, Subversion, etc., `hg import` will not apply a patch if there are changes in the working directory. This means that a group of patches must be applied in one go, and not one-by-one. Our old patching model didn't allow for this level of control, and this was the reason the new Patcher API was created. The Patcher API is now used to apply patches without commits, and with commits. It supports Git-style and Mercurial-style diffs. When applying patches without committing, we open all the patches and then pass their filenames directly to `hg import`, allowing it to apply them all without hitting the working directory changes error. When applying with committing, we use the standard Patcher logic to manage the patches, and then patch each patch using `hg import` individually. While `hg import` does support committing as part of the patch operation, we instead use our existing commit-creation functionality in order to utilize common logic and checks. Conflicts are tracked, as Mercurial uses the standard patch tool's output for conflict information. We apply using `hg diff --partial`, which will apply what changes it can while leaving the user responsible for applying the rest, keeping with the behavior in most other SCMs. Some notable limitations are that we can't revert or squash commits in Mercurial, and we generally don't have commit message or author information in the patches (requiring defaults to be used based on the review request). If applying Hg-style diffs, empty files won't be represented, so Git-style diffs are recommended. Squashing may be able to be resolved through further updates to RBTools (by applying and amending each commit in succession), but would require additional changes to the API for creating commits. We're leaving it off for now. There may be some other peculiarities of Mercurial's patching, and this will likely need some changes based on usage in production.	6d3b736fefac72c4f5d8a0ee166f97ea780a46ff

Diff:

Revision 3 (+2120 -418)

Show changes

	rbtools/clients/mercurial.py
	rbtools/clients/tests/test_mercurial.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.