On Mon, Aug 20, 2018 at 9:30 PM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Hi, > > Nguyễn Thái Ngọc Duy wrote: > > > So many times I have carefully cherry picked changes to the index with > > `git add -p` then accidentally did `git commit -am ....` (usually by > > retrieving a command from history and pressing Enter too quickly) > > which destroyed beautiful index. > > > > One way to deal with this is some form of `git undo` that allows me to > > retrieve the old index. > > Yes, I would love such an undo feature! > > How would you imagine that this information would get stored? We can > start with adding that and a low-level (plumbing) interface to it, to > avoid being blocked on getting the user-facing (porcelain) "git undo" > interface right. (Or we can go straight for the porcelain. It's fine > for it to start minimal and gain switches later.) Yeah I'd love to see "git undo" too, but unfortunately I don't have a clear model how it should operate. Which is why I still hesitate to implement one. :P All I have is something close to how undo is done in an editor, where we could save a list of actions and corresponding undo ones, but editors are wysiwyg and we can't just let the user undo, see the result elsewhere and redo if they're not happy. > > Instead, let's handle just this problem for now. This new option > > commit.preciousDirtyIndex, if set to false, will not allow `commit -a` > > to continue if the final index is different from the existing one. I > > don't think this can be achieved with hooks because the hooks don't > > know about "-a" or different commit modes. > > I frequently use "git commit -a" this way intentionally, so I would be > unlikely to turn this config on. That leads me to suspect it's not a > good candidate for configuration: > > - it's not configuration for the sake of a transition period, since some > people would keep it on forever > > - it's not configuration based on different project needs, either > > So configuration doesn't feel like a good fit. I think it falls under personal preference (yes some people like me will keep it on forever in fear of losing staged changes). > That said, I lean toward your initial thought, that this is papering > over a missing undo feature. Can you say more about how you'd imagine > undo working? There is not much to say. But at least to be able to undo changes in the index, I made two attempts in the past [1] [2] (and forgot about them until I got bitten by the lack of undo again this time). I guess I could push for one of those approaches again because it will help me and also lay the foundation for any git-undo in the future. Once we have can restore index, undoing "git reset --hard" is also possible (by hashing everything and putting them in a temporary index first). [1] https://public-inbox.org/git/1375597720-13236-1-git-send-email-pclouds@xxxxxxxxx/ [2] https://public-inbox.org/git/1375966270-10968-1-git-send-email-pclouds@xxxxxxxxx/ -- Duy
