3 ms·

Looking at the new git range-diff command, it looks like they're doing something like: diff -u <(git log -p master..fix-typos@{3}) <(git log -p master..fix

by u801e 8y ago

Looking at the new git range-diff command, it looks like they're doing something like: diff -u <(git log -p master..fix-typos@{3}) <(git log -p master..fix-typos) We actually have a program at my job that posts links to diffs like this in Github PRs whenever someone rebases the branch associated with the PR and force pushes it up to the remote.

yosito 8y ago
What does this do, exactly?
- jwilk 8y ago
  It's more or less equivalent to: git log -p master..fix-typos@{3} > tmp1 git log -p master..fix-typos > tmp2 diff -u tmp1 tmp2 except that pipes are used instead of temporary files.
  - jolmg 8y ago
    Perhaps, yosito meant what the purpose of the whole command was, rather than what <() meant. It looks like a diff of diffs and commit info, but I've never used branch@{n} before. Looking into gitrevisions(7), it gives the nth prior value of branch, so doing a regular commit would be represented as an addition of a commit and its changes and doing a `git reset @~` in that branch would be shown as a deletion. Doing a `git commit --amend` appears as a modification of that commit. It seems useful.
  - yosito 8y ago
    So what does it do?
    - u801e 8y ago
      git log -p start-commit-sha1..end-commit-sha1 will display the commit log including diffs associated with each commit from the commit after start-commit-sha1 up to the end-commit-sha1. If you make changes to your code and/or commit messages and subsequently rebase the branch, then the end-sha1-value will change (since you now have a different set of commits). If you run the same git log -p command with the new end-commit-sha1 value, then the log output will differ based on the changes you made when you rebased. So if run a diff between the two git log -p outputs (one with the original end-commit-sha1 and the other with the new end-commit-sha1), you'll be able to see the difference between the two logs which includes the changes you made to the code and/or commit messages).
JoshTriplett 8y ago
The algorithm is much more sophisticated than that; it can match up commits that get reordered, and notice commits inserted in the middle of the series.
- jordigh 8y ago
  How effective is this? hg has added extra metadata on top with what we call "changeset evolution", which tracks this renaming information explicitly. git seems to like to track stuff like this implicitly, such as renaming files. How effectively can you track commit rewriting if you don't have explicit metadata to help you?
  - JoshTriplett 8y ago
    Quite well, via well-established graph assignment algorithms that look for the best fits/matches between pairs of commits.
- u801e 8y ago
  I think you can some of that by copying the two git log -p outputs to separate files and then running vimdiff on both of them. At least in my experience, one can see commit re-ordering, commit addition, or commit removal. You could also get some of that by using the -y parameter to diff instead of -u. I'll definitely try it out and see how it compares to what we're doing now.

by u801e 8y ago

yosito 8y ago

What does this do, exactly?

jwilk 8y ago
It's more or less equivalent to: git log -p master..fix-typos@{3} > tmp1 git log -p master..fix-typos > tmp2 diff -u tmp1 tmp2 except that pipes are used instead of temporary files.
- jolmg 8y ago
  Perhaps, yosito meant what the purpose of the whole command was, rather than what <() meant. It looks like a diff of diffs and commit info, but I've never used branch@{n} before. Looking into gitrevisions(7), it gives the nth prior value of branch, so doing a regular commit would be represented as an addition of a commit and its changes and doing a `git reset @~` in that branch would be shown as a deletion. Doing a `git commit --amend` appears as a modification of that commit. It seems useful.
- yosito 8y ago
  So what does it do?
  - u801e 8y ago
    git log -p start-commit-sha1..end-commit-sha1 will display the commit log including diffs associated with each commit from the commit after start-commit-sha1 up to the end-commit-sha1. If you make changes to your code and/or commit messages and subsequently rebase the branch, then the end-sha1-value will change (since you now have a different set of commits). If you run the same git log -p command with the new end-commit-sha1 value, then the log output will differ based on the changes you made when you rebased. So if run a diff between the two git log -p outputs (one with the original end-commit-sha1 and the other with the new end-commit-sha1), you'll be able to see the difference between the two logs which includes the changes you made to the code and/or commit messages).

JoshTriplett 8y ago

The algorithm is much more sophisticated than that; it can match up commits that get reordered, and notice commits inserted in the middle of the series.

jordigh 8y ago
How effective is this? hg has added extra metadata on top with what we call "changeset evolution", which tracks this renaming information explicitly. git seems to like to track stuff like this implicitly, such as renaming files. How effectively can you track commit rewriting if you don't have explicit metadata to help you?
- JoshTriplett 8y ago
  Quite well, via well-established graph assignment algorithms that look for the best fits/matches between pairs of commits.
u801e 8y ago
I think you can some of that by copying the two git log -p outputs to separate files and then running vimdiff on both of them. At least in my experience, one can see commit re-ordering, commit addition, or commit removal. You could also get some of that by using the -y parameter to diff instead of -u. I'll definitely try it out and see how it compares to what we're doing now.