3 ms·
> I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. I don't quite understand the use of the command line for gi
by jobigoud 8y ago
> I would hate to be restricted to a GUI tool to achieve what git add can do from the command line.
I don't quite understand the use of the command line for git or hg.
In my typical workflow before I commit I want to quickly review all the changes I just made. With the GUI you have a list of files and when a file is selected a diff of that file, without opening a new window. That means you can browse all the diffs in a few seconds just by moving the cursor along the changed files. If you see an unrelated change that doesn't have an impact you can just uncheck these lines to remove these changes from the commit. Or uncheck the file itself if all its changes are unrelated. I feel I'm much more confident of what ends up in the commit than using the cli.
- maxxxxx 8y agoSounds like how I work.
- chousuke 8y agoI often find GUIs restrictive because they don't lend themselves well to ad-hoc scripting. I also don't use GUI editors, so that may be a part of it. I can see how a TUI/GUI for being able to quickly stage things from the UI is useful, but it doesn't make the concept of the index useless on the command line either. Using git from the command line is second nature to me at this point, and the index is a large part of my workflow. When I use git for revision control (as opposed to eg. Subversion. Or anything that doesn't have lightweight branching, something akin to an index, and rebases), it feels like the tool is helping me organize my commits instead of just being a place to shove things after I'm done coding.
- Shorel 8y agoWhat you describe is achieved by using git diff, and then git commit -p. I use that everyday. Whatever you imagined we command line people use, it is just not accurate, IMO.