Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


    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.


> 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.


> 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.


> 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.


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.


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


What about a push :)


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.


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?


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/ and is GPLv2 licensed. Just look at what Sapling does.


> 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.


> Yes? Not sure I see what the issue with that is.

The issue is that it sounds even more confusing in practice than status quo.

If you don't understand git, you can't rely on `git undo` cause you don't know what's undoable and what isn't. And if you do understand git, you don't need `git undo` in the first place, you can already undo things by yourself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: