81–90 of 108 posts
So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.
Or just use gitx (or git-cola on Linux, or git gui if there's nothing better) and get a much better visual reference and easy of use. Not everything needs to be done from the command line.
Earlier quoted context omitted.
I never advocate GUIs as the primary means by which a developer works with version control. Sure it might be OK for some things like browsing history (GitX) but most GUIs often abstracts away much of the underlying complexity, which is absolutely great if you're a designer without much command-line experience, but absolutely a disservice to your in-depth knowledge as a developer and the tools you rely on every day. I…
I think denying beginners the GUI is particularly cruel. The command line is much more of an abstraction in this case, I think! - gitk displays the actual tree of this graph that git manipulates, but the command line just prints text ;) It's especially illuminating (or I found it so, anyway) to keep gitk --all open as you do merges, rebases, pushes, fetches, etc., refreshing the display after each operation - it make…
beats any gui imho, although tig is technically a gui.
for those that don't know it, compile: http://jonas.nitro.dk/tig/
and type 'S'
Or just use gitx (or git-cola on Linux, or git gui if there's nothing better) and get a much better visual reference and easy of use. Not everything needs to be done from the command line.
At least for OS X, SourceTree is way better than any flavour of gitx. It provides a very nice interface for `git add -p`; I use it several times daily to craft tidy commits.
So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.
I guess you learn something new every day. I thought this was the only way people use git and I was actually surprised to find out it wasn't made the default.
Or you could just use a GUI app and save yourself a lot of time. SourceTree (OS X only, free - http://sourcetreeapp.com ) has changed the way I use git since I started using it a few weeks ago. The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option o…
I never advocate GUIs as the primary means by which a developer works with version control. Sure it might be OK for some things like browsing history (GitX) but most GUIs often abstracts away much of the underlying complexity, which is absolutely great if you're a designer without much command-line experience, but absolutely a disservice to your in-depth knowledge as a developer and the tools you rely on every day. I…
I've used CVS, Subversion and Mercurial in the past and never needed or wanted a GUI, but with git, I don't even want to be bothered by all the inane commands and switches. I love git for all it does, but I despise the CLI because it simply is downright evil: inconsistent, incoherent, convoluted, allows you to shoot yourself in the foot in too many ways, terrible user messages, and so on.
I still feel like detailed commit messages and fine grained commits are just too much busy work. I think that there must be a better, more automatic way. I'd love to start with a system that just let you easily drag back and forth history. I feel like the future may well still be built on top of git, but I don't think that we need to be so meticulous with our code.
While the idea of a "Time Machine" style history is probably quite desirable when working on your own, it's totally useless for practice of checking in self contained "features", having them reviewed and potentially rolling them back even after many other "features" have been added that you want to keep.