When creating a patch with the "patch" tool or with the built in "patch"-functionality in svn and then applying it to a source tree, is there any way to easily step back from the applied patch to the previous version?
Apply the patch again in reverse (for example patch -R switch).
svn revert? You can revert to the previous revision (before the patch was applied).
Related
I'm porting a layer to kirkstone which as an outdated patch which cannot be applied anymore (to u-boot). Can devtool be used to fix that patch? The problem is that per default devtool modify applies the patches and therefore fails to load the workspace.
The patch refresh is indeed the best method if devtool modify can apply the patches with an offset. When devtool modify fails to apply the patches, one way to update the patches is:
Remove the patches which no longer apply from SRC_URI
Run devtool modify as usual
Port the patches manually and re-commit them
Terminate as usual with devtool finish
Of course, if a patch does not apply because it was integrated upstream, the right solution is to just remove it from SRC_URI.
How could I create patch for staged files with Magit?
I tried "W p", when prompt "Format range or commit(master)", I am not sure what should I put there, I tried HEAD..master, but it doesn't create any patch.
I tried command line: "git diff --cached > my.patch" create what I expected.
How could I create the same patch with Magit?
Magit uses git format-patch (see which for more information) to create patches1, and consequently requires the changes in question to have been committed.
So commit your staged changes, then create your patch based on HEAD.
Note that the metadata for the commit will be used to populate the patch headers.
If you don't want to keep the commit, then simply soft-reset back to HEAD^ (you can type x at that previous commit).
1 Note that this patch format is different to the plain git diff output, and must be applied with git am rather than git apply. At present magit only supports patch files in the format-patch format.
You can still run arbitrary git commands without leaving magit, if you need to create or apply an unformatted patch file. Type ! for the appropriate menu.
I am creating a patch for one of my project in eclipse. I am having eclipse Kepler Release and having installed Subversion client kit(1.7.9.2). After creating patch, I have realized that in patch file, its putting following content related to properties changes.
Property changes on: ao/search_indexes.py
___________________________________________________________________
Added: svn:executable
## -0,0 +1 ##
+*
This is creating a problem when one of my other team member is trying to apply this patch in his environment. He is also having same eclipse and subversion installed on his machine.
Is there a way to tell eclipse to compare only the actual content and ignore any SVN properties related data while applying patch or is there any way to create patch ignoring this SVN properties related changes?
You can manually edit the patch file to remove those lines. The format is pretty easy to follow, it's hard to mess it up, and there is nothing in that patch that will be messed up by removing parts of it. Just be sure to remove entire "hunks" and you'll be fine.
When I make multiple unrelated changes affecting the same set of files, I often create patches with all these unrelated changes mixed together, so I can revert my working copy, split the single patch into multiple, and apply them one by one to commit only one set of related changes at a time.
So far I haven't been able to find a clear answer, though it's possible that the answer is "change your workflow".
I've just started playing around with Mercurial's patch queue and I can see some serious power in it. It seems pretty awesome. In my tests, I've discovered that if you have a patch queue in repo1, and you pull from repo2, you can do some bad things. For example:
Create repos 1, and clone it.
Enable the queue on repo1
Make some commits and some patches on repo1
Pull changes to repo2
On repo1 un-apply(pop?) all your patches
Pull changes to repo2
Now you'll see two different branches - which makes sense from a certain viewpoint. However, since my patches aren't a part of repo1's history (at least until they're applied), it seems like there should be a way to tell mercurial that my patches are off-limits, and only provide what's in the "official history".
Is there a way to do this?
Mercurial phases may be the answer to this.
Starting with Mercurial v2.1, you can configure mq changesets to automatically be marked secret. secret changesets are ignored by incoming/pull and outgoing/push commands.
To enable this behavior, you need to add the following to your config:
[mq]
secret = True
Once enabled, it behaves as follows:
$ hg qpush --all
applying my-patch
now at: my-patch
$ hg phase -r .
16873: secret
$hg outgoing
comparing with https://www.mercurial-scm.org/repo/hg
searching for changes
no changes found (ignored 1 secret changesets)
Normally, Mercurial will abort if I have a dirty working copy when I try to import a patch:
$ hg import x.patch
abort: outstanding uncommitted changes
Is it possible to import it anyway?
With Mercurial 1.9, you can use hg import --bypass to apply a patch without touching the working copy. The patch will be applied on the working copy parent revision by default. Use the --exact flag to apply the patch onto the changeset mentioned in the patch header instead.
If you are using TortoiseHg, you can use Repository > Import, then specify that the patch should be imported to Shelf and finally in the shelf, move the changes to the dirty working repository as you would with any other shelved patch.
I'd love to be able to make right click > "copy patch" in a source repository, then in a cloned repository, right click and "paste patch", hopefully this feature will be implemented in a future version.