Maybe it's not worth being in there because of how simple it is, but I guess it would be useful for newcomers: # Oh shit, I've changed 200 files and want to revert to the state of this morning $ git add . && git commit # often. Very often. $ git reset --hard commit_id
Wait, aren't you committing and immediately orphaning that commit? I think you should create a new branch or tag before the reset, otherwise how are going to get it back?
I guess you could rely on the reflog, but I don't think that's good practice.
I think git provides a sane level of abstraction. I don't think it provides the most consistent UI or helpful help, though. Once you move away from "learning git commands" to "learning how git works" and kind of figuring out which parts the commands refer to has helped also. That's still terrible though.
Most of the abstraction is fine. The staging area model is a total mess though. The way that staging interacts with other commands (e.g. stash) is constantly surprising.
Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we?
I had trouble with Git until I discovered "git add -p".
I'll grant that Git could do with a revision of its commands and args.
Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.
A well made GUI conveys those semantics more clearly than the default command line interface. Automation is easier from the CLI, but I wouldn't be surprised if a GUI turned out to be best for manual interactions.
In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.
If by "designed" you mean "picking a content-addressable DAG as an underlying data structure", then yes, it is really beautiful. If you mean "provide a sane level of abstraction over said data structure", then hell no!
Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
> Oh shit, I did something terribly wrong, please tell me git has a magic time machine!?! Shouldn't it be easy for Git to remove objects created after a given time, and then remove all objects that refer to those objects iteratively?
Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.
> What GUI do you recommend?
I really like Magit, which is a git GUI you can use without leaving Emacs. It handles 90% of my git needs and is very tightly integrated into my IDE (Emacs). I still use some shell commands (like git mv) occasionally but those are simply m-! away.
Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.
The Git GUI that ships with git is very good. It also shows how Git thinks (workspace/staging/commit) that most other gui's struggle with (they try to make it look more like a SVN workflow). For diffs and blame I use TortioseGit. I also extensively use the CLI for most branch actions.
What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.
Magit in emacs. Probably one of the killer applications for emacs.
Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.
Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.