Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.
You can split hunks manually by editing (hit “e” instead of “s” during staging). I end up doing this fairly regularly.
i think that’s his point? there’s a huge amount of useful, but advanced functionality in the git CLI
I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…
It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model. The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.
This looks fantastic, thanks for mentioning it! I've been looking for a GUI that doesn't mesh poorly with [whatever patterns my team uses] / without always pushing other features or a signup.
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 use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…
The problem, as I see it, is not with the GUIs, it's with the CLI. Just look at the `reset` command: it does several different things, depending on what switches you give it. How would you represent that in a GUI?
A git off my lawn moment: Every time I see someone complaining because they have to dive into the reflog to fix their own mistake, all I can hear is "I was operating my table saw without using a push stick and can't understand why I lost a thumb". Friends don't let friends (especially those who don't learn how to use their tools) rewrite shared git history. If you don't understand rebase, amends, etc can do to your (…
Rewriting shared history fits the metaphor pretty well.
But you can still chop off your thumb in your local history, and that's safe to fix - you just have to know where the duct tape is.
I'm sorry if I sound rude. I don't mean to be. I'm just saying that backing up your git workspace to recover from rebases or merges gone wrong is not necessary. Those are not "surgical tools", they don't modify existing commits. (edit: yes you can "edit commits", but they only create new commits, the old commits are not deleted in the process and they can still be found easily) When you commit in git, that saves the…
> git reset --hard Unless part of your surgery involves files that do not yet live in the history, or you're working on a detached HEAD in a mid-merge state, or... git reset --hard is a very dangerous operation unless you're 100% sure of the entire state of the repository. That is a very rapid way to lose work if you're not perfectly diligent. And sure, you shouldn't have to back up .git or your workspace, but someti…
It's only easier to copy the directory if you haven't done the due diligence of learning git properly. It's a tool to avoid doing the ripcord approach -- ever.
I use https://github.com/jonas/tig for interactive staging and git CLI for everything else. Best of both worlds and I don't have to leave the terminal.
+1, not having to use a mouse is great. I also use zsh's inbuilt git aliases [0] which I can't recommend enough -- I've found using git CLI without them a pain now that I'm used to them. These together have me productive and happy. [0] https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git
Tip for new tig-players: whilst you can use tig perfectly fine with just the keyboard, it does support using the mouse. Just add `set mouse = yes` to `~/.tigrc` :)
> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.
Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.
As mentioned before, manual edits can be made at that point. However I'll add that for this use case, a tool integrated in your editor will often be more adapted to manual staging. I have Tim Pope's vim-fugitive plugin in mind which is a quite wonderful way of using Git.
Yeah the "right way" to do VCS is definitely a lot of overhead for a team like that, but by the time you need to scale up (and by "up" I mean 3-6 people total who are committing code multiple times daily?) the business is likely so busy it's a HUGE uphill battle to implement something like that, especially since most of the people who let an environment like that happen will likely not be super familiar with Git/hg/T…
I dunno if I'd agree that it's a lot of overhead, for what you get back. Hell I'm a one-man team right now and I'm using source control. Some of my little experiments go horribly awry. Some of my deletions are a bit too aggressive/arrogant. Sometimes you need to diff shit. Version control frees me to be bold.
Agree with you here. I use git for literally every coding project, even my quick practice folders. I haven't had an "oh-shit" moment from losing anything in like 5 years, back when I was still learning git.
For me the big thing was learning to 1/ not work on master unless I’m alone and 2/ commit all my work incrementally git pull —-rebase & git log git rebase -i HEAD~n So basically I want to make sure my work is pushed to remote as a separate commit before attempting to run any commands except the ones above. But you can do pretty much anything with the set above.
I generally replace `git pull` with a `git fetch $remote` + `git rebase $remote/branch-name`. It provides the added benefit that I can easily diff changes prior to the rebase so that I know what is going into my branch. The use of the `--rebase` flag isn't bad though and I may start doing that when I know I will not be doing any diff prior to a rebase.
I also use `git merge-base` quite a bit so that I do not have to count commits when working with really simple branches.
I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…
Same here. Regrettably, if you UNDERSTAND git, a GUI won't work for you. If you're interested in understanding it, it won't work for you either. A GUI works fine if you want to get things done. If you like to know what goes on under the hood, it's just confuse you.
I feel this has become a bit of a standard excuse for git. The reason I use a gui isn't because I don't know how git works (while I do forget that too from time to time), but because I can't remember the default behavior and notation of the git cli. I'd be perfectly happy if the cli was actually made to be "low level", but it to a large degree isn't. So if I'm going to have to remember what some abstraction does, it might as well be on a higher level.