0

I have 2 commits: A and B. B is said to revert A. i.e. the assumption is that B was created using "git revert A"

In order to verify the above I could:

  1. git checkout A
  2. git cherry-pick B
  3. git diff A~1 (should return 0 lines of difference)

Is there a diff tool that can do the same without using git?

Thank you in advance.

jazurin
  • 1
  • 1
  • It's obvious by inspection. If some changeset *C* modifies initial input state *I* to output state *O*, the reversion changeset is *-C* because it modifies output state *O* to input state *I*. In other words, if *C* says "add file F1, remove file F2, remove line 12 of F3" then *-C* says "remove file F1, add file F2, put back line 12 of F3". – torek Mar 08 '17 at 00:38
  • Incidentally, you say that you have two *patches* A and B, but then you say `git checkout A` and `git cherry-pick B`, which implies that A and B are two *commit IDs*. These are not the same thing. Which do you have, commit IDs, or patches? – torek Mar 08 '17 at 01:01
  • Isn't it more obvious to do a real cherry-pick? If you don't need the commit made by the cherry-pick afterwards, just run `git reset HEAD^ --hard`. – ElpieKay Mar 08 '17 at 06:48
  • @torek I'm working with commit IDs from an upstream source (I edited the question). The commits vary in size and some may change dozens of files. I'm trying to write a tool that can verify these reverts before applying them to our downstream repo. Thanks. – jazurin Mar 08 '17 at 16:38
  • @ElpieKay Thanks, yes that's my current plan, but I'm exploring to see if there are other options. – jazurin Mar 08 '17 at 16:41
  • Well, see VonC's answer; but in general I would just do this in a spare side work-tree, if you have the repository and it already has the commits. You can (well, "will"!) use a detached HEAD by checking out commit `A`, so that after cherry-picking `B` you still have a detached HEAD, so you can abandon the commit and let Git clean it up during a later automatic gc. If you use `git worktree add --detach A`, all this happens in a new work-tree, which you can then simply `rm -rf` and go back to the original repository and `git worktree prune` it away. – torek Mar 08 '17 at 21:38

1 Answers1

0

You could generate a diff from those commits (that part still needs Git)

git format-patch -1 A
git format-patch -1 B

So you would still need Git to extract something to inspect.

Then you can use combinediff from patchutils to see if the combination result in an empty patch.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283