20 ms·

Isn't it a problem then that Git does not expose or visualize its internal model in any comprehensible way to its end users? That and the lack of instant undo s

by johnbm 13y ago

Isn't it a problem then that Git does not expose or visualize its internal model in any comprehensible way to its end users? That and the lack of instant undo seem ridiculous for a program designed to manage change.

to3m 13y ago
gitk --all is excellent for this. I didn't really fully understand what git rebase was for until I worked through a few tests on my repository, refreshing the GUI after each command I typed.
sethrin 13y ago
It has a steep learning curve. It is not optimized for novices. In my opinion, it does exactly what it should do internally, while I consider other tools to be deficient in some respects. In the common case, undo is provided by git commit --amend. For anything more complicated, I don't think that there is an explanation or GUI which could be considered "intuitive". I've used gitk and git-gui, and a variety of other visual interfaces before Reading the Figurative Manual, and while I'll be the first to cry my own ignorance, I have not found any of them to give much information about even the available options. What is cherry-picking? What about reverse cherry-picking? When would you want to use either? It's not impossible to design a user interface which would translate all of git's graph manipulations into a simple visual system. However, its current textual interface is extremely flexible, and it exposes a very useful scripting interface. It is a tool that rewards knowledge and experience, like emacs or vi(m). Which is not to say that it's necessarily a good value proposition to you, but it is (imo) a good time investment. One of these days I need to invest in vim too :(
- johnbm 13y ago
  Eh? "Git undo" should restore the state of the repository to what it was before I typed the last command. How is this not the simplest and most intuitive implementation of this feature? Unix geeks, you make my head hurt with your stockholm syndrome.

by johnbm 13y ago

to3m 13y ago

gitk --all is excellent for this. I didn't really fully understand what git rebase was for until I worked through a few tests on my repository, refreshing the GUI after each command I typed.

sethrin 13y ago

It has a steep learning curve. It is not optimized for novices. In my opinion, it does exactly what it should do internally, while I consider other tools to be deficient in some respects. In the common case, undo is provided by git commit --amend. For anything more complicated, I don't think that there is an explanation or GUI which could be considered "intuitive". I've used gitk and git-gui, and a variety of other visual interfaces before Reading the Figurative Manual, and while I'll be the first to cry my own ignorance, I have not found any of them to give much information about even the available options. What is cherry-picking? What about reverse cherry-picking? When would you want to use either? It's not impossible to design a user interface which would translate all of git's graph manipulations into a simple visual system. However, its current textual interface is extremely flexible, and it exposes a very useful scripting interface. It is a tool that rewards knowledge and experience, like emacs or vi(m). Which is not to say that it's necessarily a good value proposition to you, but it is (imo) a good time investment. One of these days I need to invest in vim too :(

johnbm 13y ago
Eh? "Git undo" should restore the state of the repository to what it was before I typed the last command. How is this not the simplest and most intuitive implementation of this feature? Unix geeks, you make my head hurt with your stockholm syndrome.