views:

76

answers:

2

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.

A: 

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.

Andreas Rehm
I don't understand. I don't want a new branch; I want to re-apply a revision from the past, within the same branch.
mackstann
I've got that point. But it is easier to do this with a new branch. You can safely delete it - once your pickaxe process is finished and you've merged it back in. Branching is cheap and easy in git.
Andreas Rehm
But then how do I get the revision into master in the future when I'm in my back-to-the-past branch?
mackstann
It might be easier to use WinMerge if your Revision is not just one commit. The question is - what do you mean with a Revision?
Andreas Rehm
You can get it back in with a merge - you will get merge conflicts, that you need to solve by hand.
Andreas Rehm
+2  A: 

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.

Mark Lodato