path: root/git-revert-script
AgeCommit message (Collapse)Author
2005-08-30Do not verify reverted/cherry-picked/rebased patches.Junio C Hamano
The original committer may have used validation criteria that is less stricter than yours. You do not want to lose the changes even if they are done in substandard way from your 'commit -v' verifier's point of view. Signed-off-by: Junio C Hamano <>
2005-08-29Redo "revert" using three-way merge machinery.Junio C Hamano
The reverse patch application using "git apply" sometimes is too rigid. Since the user would get used to resolving conflicting merges by hand during the normal merge experience, using the same machinery would be more helpful rather than just giving up. Cherry-picking and reverting are essentially the same operation. You pick one commit, and apply the difference that commit introduces to its own commit ancestry chain to the current tree. Revert applies the diff in reverse while cherry-pick applies it forward. They share the same logic, just different messages and merge direction. Rewrite "git rebase" using "git cherry-pick". Signed-off-by: Junio C Hamano <>
2005-08-24Audit rev-parse users again.Junio C Hamano
Some callers to rev-parse were using the output selection flags inconsistently. Signed-off-by: Junio C Hamano <>
2005-08-10git-revert: revert an existing commit.Junio C Hamano
Given one existing commit, revert the change the patch introduces, and record a new commit that records it. This requires your working tree to be clean (no modifications from the HEAD commit). This is based on what Linus posted to the list, with enhancements he suggested, including the use of -M to attempt reverting renames. Signed-off-by: Junio C Hamano <>