3 ms·

Honestly, just being able to "tick" each commit would be great. On https://github.com/bitcoin/bitcoin/ https://github.com/bitcoin/bitcoin/ it is common practice

Honestly, just being able to "tick" each commit would be great. On https://github.com/bitcoin/bitcoin/ https://github.com/bitcoin/bitcoin/ it is common practice to include the commit hash in your approval comment so you can easily review where you were up to if a rebase occurs.

rcaught 10y ago
A rebase would change all commit hashes, all the way to the base branch. Your commit hash in the comment would not be relevant.
- couchand 10y ago
  Git UIs should expose the tree hash as well to mitigate that issue.
  - cyphar 10y ago
    That wouldn't help. If you needed to rebase (there was a conflict) then the tree hash will necessarily be different. In fact, unless you are rebasing on a commit and it's reversion then you'll probably get a different tree hash.
    - couchand 10y ago
      Indeed. What I'm looking for isn't the tree hash it's the hash of the patch itself. I don't think that's explicit anywhere.
      - cyphar 10y ago
        Patches in git are generated on-the-fly. This is actually one of the critical things that made git so much better than conventional version control systems at the time -- it doesn't need to track diffs (which means it doesn't have to handle the infinite fractal of problems that spiral out of rebasing diffs). It can just compute them when it needs them. Think of git like a snapshotting filesystem that has a VC interface added on top.
        couchand 10y ago
        Where does that leave rebasing, then? That's explicitly an operation on diffs: take these diffs and apply them to that.
        cyphar 10y ago
        Rebasing is implemented by generating diffs, yes. But git doesn't actually store these diffs -- they're all generated on the fly from tree snapshots. If your VC stores diffs rather than the actual contents of files then you can't be sure that you'll get out exactly the same data as you put into it. There are also a bunch of other problems that happen as a result.

rcaught 10y ago

A rebase would change all commit hashes, all the way to the base branch. Your commit hash in the comment would not be relevant.

couchand 10y ago
Git UIs should expose the tree hash as well to mitigate that issue.
- cyphar 10y ago
  That wouldn't help. If you needed to rebase (there was a conflict) then the tree hash will necessarily be different. In fact, unless you are rebasing on a commit and it's reversion then you'll probably get a different tree hash.
  - couchand 10y ago
    Indeed. What I'm looking for isn't the tree hash it's the hash of the patch itself. I don't think that's explicit anywhere.
    - cyphar 10y ago
      Patches in git are generated on-the-fly. This is actually one of the critical things that made git so much better than conventional version control systems at the time -- it doesn't need to track diffs (which means it doesn't have to handle the infinite fractal of problems that spiral out of rebasing diffs). It can just compute them when it needs them. Think of git like a snapshotting filesystem that has a VC interface added on top.
      - couchand 10y ago
        Where does that leave rebasing, then? That's explicitly an operation on diffs: take these diffs and apply them to that.
        cyphar 10y ago
        Rebasing is implemented by generating diffs, yes. But git doesn't actually store these diffs -- they're all generated on the fly from tree snapshots. If your VC stores diffs rather than the actual contents of files then you can't be sure that you'll get out exactly the same data as you put into it. There are also a bunch of other problems that happen as a result.