Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

391–400 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#391

Earlier quoted context omitted.

> 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.

Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well). Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users. Sometimes dev obsession with tool purity does more damage than good.

You're always one git reflog away of undoing the brainfart. Once you know the CLI well enough, you manipulate the git data model easily. When you're using a code review tool like gerrit, it's impossible to do something you can't undo.

Re: Oh shit, git: Getting myself out of bad situations

#392

The absolute worst situation I've gotten into was just the other day, when my team managed to check in two files with the same name, but different capitalization. The server (Bitbucket) is Linux-based, but all the workstations are Mac or PC, so the names collided on everyone's desktops. This prevented anyone from pulling or checking out a different branch, so even after master was fixed, everyone's environment stayed…

Not really an issue with git, but with OSX. In doing some research of git, I wanted to look at the first git repos. Those are torvalds/git.git and torvalds/linux.git. If you clone linux.git on OSX and run `git status`, you'll see this:

    $ git status --short
    ## master...origin/master
    M include/uapi/linux/netfilter/xt_connmark.h
    M include/uapi/linux/netfilter/xt_dscp.h
    M include/uapi/linux/netfilter/xt_mark.h
    M include/uapi/linux/netfilter/xt_rateest.h
    M include/uapi/linux/netfilter/xt_tcpmss.h
    M include/uapi/linux/netfilter_ipv4/ipt_ecn.h
    M include/uapi/linux/netfilter_ipv4/ipt_ttl.h
    M include/uapi/linux/netfilter_ipv6/ip6t_hl.h
    M net/netfilter/xt_dscp.c
    M net/netfilter/xt_hl.c
    M net/netfilter/xt_rateest.c
    M net/netfilter/xt_tcpmss.c

Re: Oh shit, git: Getting myself out of bad situations

#393

Geez, using `git add .` is the worst thing you can do. Never use this. Tutorials: stop suggesting this. It's just a recipe to getting yourself into a mess (plus, you should never work so blindly!). Add individual files, and, if possible, use `git add -p`, which lets you review each chunk before adding it to the index. Otherwise, diff and add individual files.

Hell, even if you want to stage every change, what you really want is `git add -A`, which stages deletes too (`git add .` ignores any files you've deleted or renamed, it only stages new files and changes to existing files.)

Re: Oh shit, git: Getting myself out of bad situations

#394

Honestly, a lot of what's wrong in git is that people seem to mostly memorize or copy-paste a finite amount of commands, and when something goes wrong they are completely lost unless they can find a way to copy-paste a solution. Instead of saving a 6 command list for some use cases, why not just get used to the simple but kinda unintuitive way of how revisions and branches work? If you know that, you can solve any pr…

Quick quiz, what does 'git checkout x/y' do? I am aware of users hitting at least 3 interpretations.

I'd say it changes your code to match that of a branch in your local copy of the repo.

Re: Oh shit, git: Getting myself out of bad situations

#395
post #11

> Oh shit, I accidentally committed to the wrong branch! I find cherry-picking to be easier in this case. Just checkout the branch and cherry pick commits from 'wrong' branch. https://git-scm.com/docs/git-cherry-pick

I agree that the proposed solution is not the best. If you can fix your problem without dirtying the working tree (i.e. by simply moving changesets around), that's almost always a nicer way to do it.

Re: Oh shit, git: Getting myself out of bad situations

#396
post #193

Earlier quoted context omitted.

I use sourcetree, but I would like a console feature that shows me what commands its running. Similar to sequel pro's "console" feature shows the raw sql being run.

the commands themselves are not actually the lowest level, though! (and in fact, are kind of crazily mixed togther; most of the trouble people have w/ git is bad UX for the cli, imo.)

True. Inconsistent and unintuitive options, oddly named commands (and this is coming from someone who enjoys using Unix clones).

Re: Oh shit, git: Getting myself out of bad situations

#397

Haha. There should be an entry there for 'Oh shit - I just pushed our private keys to the public github repo'.

Just as an FYI, those will likely live in Github forever. Run `git ls-remote` where ever you have had this problem. You'll see that there are refs for every PR in the form `refs/pull/NNNN/head` and `refs/pull/NNNN/merge`; where `NNNN` is the PR number, `head` is the latest commit and `merge` is the final commit.

If any of those commits with confidential information is reachable from any of those commits, then they'll never be garbage collected from Github.

Re: Oh shit, git: Getting myself out of bad situations

#398

Earlier quoted context omitted.

It’s a lot of paperwork to avoid a perfectly safe and normal git command.

To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.

That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream.

When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!

Re: Oh shit, git: Getting myself out of bad situations

#399

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…

Which Git GUI are you using?

The GUI is said to be a major leap forward in human conputer usage, in the context the CLI just strikes me as either (elitist?) jargon, or brogrammer bravado. In either case, not really a step forward but certain macho. I still don't get it.

Re: Oh shit, git: Getting myself out of bad situations

#400

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’m a big fan of Gitkraken. Great for doing common actions in one click, and graphically viewing history. It’s crazy how negatively people judge me for using it though. It’s like telling someone I prefer Microsoft Word as my IDE.
Post reply on HN