Reputation: 1367
Say I have revision A that's from a long time ago and made a desirable change.
Then, later on, I had revision B which made lots of changes to lots of files, including wiping out change A.
Now, much later, I want to re-apply revision A. Is there a good way to do this? The merge and cherry-pick commands seem to skip revisions that are ancestors, and I don't see any flags to ignore ancestry.
There's always diff/apply, but are those really the best way? It seems like this could be "lossy" (going through the intermediary patch format) and might not allow git to use all of the tools normally at its disposal... but this is an uninformed hunch on my part.
Upvotes: 14
Views: 4780
Reputation: 53274
git cherry-pick A
will do exactly what you want. It does not look at ancestry - it only looks to see what changes have already been applied.
Here's an example:
git cherry-pick A
git cherry-pick A
git cherry-pick A
will only create one new commit (at most). The second and third commands are no-ops, since the changes of A
have already been applied. However,
git cherry-pick A
git cherry-pick B
git cherry-pick A
git cherry-pick B
will create four new commits. The first and third commits will both do the same thing, while the second and fourth will revert the first and third (even if commit B
made other changes than reverting A
.) In other words, this is the same as
git cherry-pick A
git revert --no-edit HEAD
git revert --no-edit HEAD
git revert --no-edit HEAD
Hope this helps.
Upvotes: 22
Reputation: 2232
You can use git checkout $REVISION to switch back to your Revision (Commit). Then you should create a new branch from there.
git.cmd branch YOURCOMMIT
You can use pickaxe to get the commits you need for your new branch.
Upvotes: -2