5 ms·

Do you mean literally deleting your last commit? That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everyth

Do you mean literally deleting your last commit? That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. I think undo is too ambiguous in the context of vcs that it would be risky to introduce as a part of the cli api. What would you expect undo to do?

masklinn 3y ago
git reset —hard HEAD~1 It is already part of the CLI API. Or it could use the ref log (possibly augmented) as a literal undo log, and follow that. > That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. The graph is really not append-only.
- wtallis 3y ago
  > The graph is really not append-only. The commit graph is effectively append-only, but the named pointers into that graph can be reassigned at will, which means some commits can become (more or less) unreachable and eligible for garbage collection.
  - masklinn 3y ago
    > The commit graph is effectively append-only, but […] some commits can become (more or less) unreachable and eligible for garbage collection. Sound to me like the commit graph is not append-only.
- maleldil 3y ago
  > The graph is really not append-only. Yes, it is. You can't change a commit: you have to create a new one, and create copies of any child commits, which are also different commits. This generates a different graph. What changes are things like tags, branches and HEAD, but they're just pointers, not part of the graph itself.
  - masklinn 3y ago
    Mate go @ the GP they’re the ones who asserted a git undo would break assumptions. > Yes, it is. You can't change a commit You can remove commits from the graph. That’s not append only in my book.
howinteresting 3y ago
No, I mean undoing your last action performed with git. Can be a commit, an amend, a reset. whatever.
- robertlagrant 3y ago
  What about a push :)
  - masklinn 3y ago
    That you can undo some actions doesn’t have to mean you can undo all actions. In the same way you can’t rollback a db rollback, you can’t undo a git gc which cleaned up a bunch of unreachable objects.
    - robertlagrant 3y ago
      Sure, but there's no generic "db rollback" command that reverses the last thing you did. This command would have to decide what to do for every previous command, no?
      - howinteresting 3y ago
        Yes, it would have to decide what to do for every previous command. Still less complicated than git rebase -i. edit: there's even prior art. Sapling has undo: https://sapling-scm.com/docs/overview/undo/ https://sapling-scm.com/docs/overview/undo/ and is GPLv2 licensed. Just look at what Sapling does.
      - masklinn 3y ago
        > Sure, but there's no generic "db rollback" command that reverses the last thing you did. Technically nothing prevents the database automatically creating a subtransaction / savepoint for every operation you perform. > This command would have to decide what to do for every previous command, no? Yes? Not sure I see what the issue with that is. And technically much of the information is already encoded in the reflog. The two big additional informations you’d need are: 1. Tracking changes to refs as they’re not necessarily tracked by the reflog, but there should only be a small number of plumbing operations manipulating refs so it’s not really a concern. 2. Tracking changes to the index, would likely be a lot more difficult.

masklinn 3y ago

git reset —hard HEAD~1 It is already part of the CLI API. Or it could use the ref log (possibly augmented) as a literal undo log, and follow that. > That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. The graph is really not append-only.

wtallis 3y ago
> The graph is really not append-only. The commit graph is effectively append-only, but the named pointers into that graph can be reassigned at will, which means some commits can become (more or less) unreachable and eligible for garbage collection.
- masklinn 3y ago
  > The commit graph is effectively append-only, but […] some commits can become (more or less) unreachable and eligible for garbage collection. Sound to me like the commit graph is not append-only.
maleldil 3y ago
> The graph is really not append-only. Yes, it is. You can't change a commit: you have to create a new one, and create copies of any child commits, which are also different commits. This generates a different graph. What changes are things like tags, branches and HEAD, but they're just pointers, not part of the graph itself.
- masklinn 3y ago
  Mate go @ the GP they’re the ones who asserted a git undo would break assumptions. > Yes, it is. You can't change a commit You can remove commits from the graph. That’s not append only in my book.

howinteresting 3y ago

No, I mean undoing your last action performed with git. Can be a commit, an amend, a reset. whatever.

robertlagrant 3y ago
What about a push :)
- masklinn 3y ago
  That you can undo some actions doesn’t have to mean you can undo all actions. In the same way you can’t rollback a db rollback, you can’t undo a git gc which cleaned up a bunch of unreachable objects.
  - robertlagrant 3y ago
    Sure, but there's no generic "db rollback" command that reverses the last thing you did. This command would have to decide what to do for every previous command, no?
    - howinteresting 3y ago
      Yes, it would have to decide what to do for every previous command. Still less complicated than git rebase -i. edit: there's even prior art. Sapling has undo: https://sapling-scm.com/docs/overview/undo/ https://sapling-scm.com/docs/overview/undo/ and is GPLv2 licensed. Just look at what Sapling does.
    - masklinn 3y ago
      > Sure, but there's no generic "db rollback" command that reverses the last thing you did. Technically nothing prevents the database automatically creating a subtransaction / savepoint for every operation you perform. > This command would have to decide what to do for every previous command, no? Yes? Not sure I see what the issue with that is. And technically much of the information is already encoded in the reflog. The two big additional informations you’d need are: 1. Tracking changes to refs as they’re not necessarily tracked by the reflog, but there should only be a small number of plumbing operations manipulating refs so it’s not really a concern. 2. Tracking changes to the index, would likely be a lot more difficult.