In choose your own adventure style: http://sethrobertson.github.io/GitFixUm/fixup.html
Oh shit, git: Getting myself out of bad situations
321–330 of 520 posts
Re: Oh shit, git: Getting myself out of bad situations
#322Earlier quoted context omitted.
> I'm not 100% sure what's going on under the covers. This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.
Even GUI based SQL tools show you a log of commands used... Git GUI clients don't even show you beforehand or after what the heck just happened... Sad.
It's definitely not true.
I'm not sure what kind of gui did you use but both sourcetree and gitextensions show you the command log.
Re: Oh shit, git: Getting myself out of bad situations
#323In 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.
When in doubt either: * commit to an itermediate branch as storage * git stash && git stash apply (repeat last to recover stuff)
git stash pop is often nicer for temporary stuff.
Re: Oh shit, git: Getting myself out of bad situations
#324Earlier quoted context omitted.
You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.
I've found Sourcetree to be way too slow. My team is currently using the GitFlow model, for various reasons, and that involves switching between branches fairly regularly. It also means that any commit to master involves a lot of steps. From the command line, this isn't a big deal because each of those steps takes a half second or so, but Sourcetree multiplies that by an order of magnitude, and the Sourcetree users a…
Source tree is the slowest software that I ever used.
Git extensions is much much faster and I never had any performance problem with it.
Re: Oh shit, git: Getting myself out of bad situations
#325Earlier quoted context omitted.
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…
You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.
Not available for Linux, which is a damn shame.
Re: Oh shit, git: Getting myself out of bad situations
#326Earlier quoted context omitted.
Well, I see you're adding more and more constraints to suit your point of view. First you attacked git by pointing out some flaws that were only just about people not knowing how it worked. Then you gave a more specific example, where actually, it was in the company's best interest to hire a novice developer who didn't have time to learn git, because he was pressured into focusing on whatever the CEO wanted. Then you…
This is simply untrue: " The issue you have with git, is that untrained developers have a hard time using it. " Please re-read my first post, up above, which started this thread. I wrote: " But all of that stuff is trivial compared to the major flaw: Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion. "
Ok, I agree, attacked your weakest argument, which you specifically marked as being trivial flaws. So to address your actual issue:
> Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.
Why is it hard for them to use git? For simple use cases, git can be as easy as commit & push. No need for branches. There are even UIs which allow you to easily make commits and see the log [1]. If more people work together and conflicts arise, I honestly don't know how SVN is better at solving them.
Re: Oh shit, git: Getting myself out of bad situations
#327Earlier quoted context omitted.
`git add -p` adds by the hunk, which is a unit of quantization bigger than a line. E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk". (Waiting for someone to chime in with how to split a hunk and change my life).
Within 'git add -p' when you get to the hunk that you want to edit (split down to single lines), press 'e'. This will open an editor (vim in my case) which lets you edit the diff manually. In there you can remove added lines (prefixed by '+') by removing them, and re-adding removed lines (prefixed by '-') by replacing the '-' with a space ' '.
And how is this faster/better than selecting a line with the mouse and pressing s without opening any other editor?
Re: Oh shit, git: Getting myself out of bad situations
#328Earlier quoted context omitted.
rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous deployment environment, where you may need to quickly revert something.
You already have git-revert, for reverting commits without rewriting history.
Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you.
After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch.
In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.
Re: Oh shit, git: Getting myself out of bad situations
#329Adopted 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…
Past experience with GUI frontends and other sorts of simplifying interfaces for version control tools has left me extremely reluctant to use anything more than git's out-of-the-box command line, despite its execrably wretched, unlearnable inconsistency. When things don't make sense with git, I can at least compare notes with coworkers, or search the web and find many discussions where other people have been similarly confused, and received useful advice. If I'm using some custom frontend interface, on the other hand, there are inevitably going to be situations it doesn't handle where I have to fall back to the command line, which I won't remember anything about because I will not have been using it, nobody else on my team is likely to be familiar with the tools I'm using, and discussions on the web are likely to be scarce. Better to just absorb the ongoing pain of git's terrible interface for day-to-day tasks so that I'm not completely hosed when things inevitably go wrong.
Re: Oh shit, git: Getting myself out of bad situations
#330Adopted 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.
I use SmartGit.
Way faster and more stable than SourceTree and GitKraken, in my experience.