Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More Productive Git

increment.com

Post reply on HN
Print view View original

101–110 of 147 posts

Re: More Productive Git

#101

Post by AlexCoventry »

tunesmith wrote: post #25

I found one article, only one, that did more than anything to help me understand git. Can't find it anymore. :-( But it had to do with reflog and how any command could be undone since nothing was truly destructive, and how reflog actually had the edges in the graph and you just needed to know how to repoint them to the right nodes. Or something. This is probably one of my least helpful HN comments. edit: It might hav…

> any command could be undone since nothing was truly destructive

As the article mentions,

    git reset --hard
will blow away uncommitted changes in your working tree.

Re: More Productive Git

#102

Post by tbrock »

wincent wrote: post #83

The very first factual claim in the article is wrong: "The most basic usage is: git reset useful_func.clj This will replace the useful_func.clj in the current working directory with the last committed version in the repository HEAD." Not a good start. What it actually does is reset the path "useful_func.clj" in the index (AKA staging area) to the HEAD state. It doesn't touch the working directory.

One would idiomatically use “git checkout ” for the functionality described by the author: “get some file back to the latest version committed in HEAD”.

Stopped reading after I saw this.

Re: More Productive Git

#103

Post by emmelaich »

saagarjha wrote: post #72
no_gravity wrote: post #28

Put this in your bashrc: source /usr/share/bash-completion/completions/git And you can type "git br " to write "git branch", "git checkout fun " to write "git checkout funky-feature", "git log --na " to write "git log --name-only" etc. Pretty much every time you press somewhere while writing a git command, it does the right type of completion. And hitting multiple times lets you toggle through the options. So you lea…

If you're on macOS, update your bash and install bash-completions and git. The path above is likely wrong if you're using a package manager: for MacPorts you want to source /opt/local/etc/profile.d/bash_completion.sh, and for Homebrew it's $(brew --prefix)/share/bash-completion/bash_completion (the install process will tell you what to use).

My brew has it in /usr/local/etc/bash_completion.d/

Re: More Productive Git

#105

Post by dTal »

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

Interesting choice of analogy. Remember Neal Stephenson's "Hole Hawg" essay [0]? He compares UNIX to this ludicrously, dangerously over-powerful hand drill with no safety features and all the ergonomics of a chunk of steel pipe. And by this he means praise! The implication in that essay was that a powerful, dangerous, unfriendly tool is in some way better than a user-friendly tool that lacks the power to remove limbs.

My takeaway from that essay was that in the real world, you will never see a contractor using a Hole Hawg, or anything like it, and hackers have a uniquely fucked-up attitude to human factors. Hackers will excuse the most tragic of user interfaces, with some kind of macho "rite of passage" bullshit. Yes, "macho":

"Now I view them all with such contempt that I do not even consider them to be real drills--merely scaled-up toys designed to exploit the self-delusional tendencies of soft-handed homeowners who want to believe that they have purchased an actual tool."

See? It's all about self-inflicting pain, because if you can't tolerate the pain of a crappy user interface, you're not a real hacker [1]. I see it in the defense of git's crappy user interface ("the reason you can't remember the 50 semi-orthogonal cryptic commands is because you haven't grokked its perfect model of directed acyclic graph theory"). I also see it in the perpetual defense of Emacs' crappy user interface (infuriating, because it is a powerful piece of software). Hell, I even see it in the defense of the command line interface itself (and associated scorn of GUIs) - many of its design decisions have been baked in since 1969, yet to listen to many apologists its perfection is such that it might as well have been carried down the slopes of Mount Sinai by Moses himself.

This is a major cultural problem with our community. Maybe, if we actually could bring ourselves to admit that our interfaces suck, we might start to make a little progress towards fixing them. Because right now, "tolerance for unreasonable bullshit" is a major filter for who gets to do programming.

"...when I got ready to use the Hole Hawg my heart actually began to pound with atavistic terror. But I never blamed the Hole Hawg; I blamed myself."

Yes. Blame yourself. Blame yourself for using a stupid tool with a bad user interface.

[0] http://www.team.net/mjb/hawg.html [1] https://xkcd.com/378/

Re: More Productive Git

#106

Post by aasasd »

finnthehuman wrote: post #97
chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

Git's structures are fine. Git's command-line tools are shit.

Re: More Productive Git

#107

Post by klyrs »

wyldfire wrote: post #6
jc_sec wrote: post #2

There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.

> Git isn't that hard. It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it. The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it. The term `checkout` is multiplexed to do more things than I would've guessed.

> The staging area is totally unnecessary IMO

Honestly, I think that 'stash' is the more problematic concept for me. Not that it's particularly bad, just that it's extra. Make a new branch for your awful code, check out your old head and keep going. I learned hg and then git, and IIRC stash was more comfortable for my team's established workflow.

And maybe I have good reason to hate it. One of the only times I've ever broken a repo is by attempting to stash partway through a messy merge. Never did figure out if that was pebcak or a bug, or if I could gracefully recover, because I was in the middle of something. I shed a tear, nuked the repo and found a better direction to merge.

Ever since that happened I've gotten much more comfortable making and deleting branches. Among other things, they're easier to clean up and have proper histories.

Re: More Productive Git

#108

Post by jjdjr0odo7 »

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

You’re assuming all of us need these weekly articles.

Got works fine for me and my teams. Has for a decade now.

I mean I’m down to check out your version control system.

Otherwise this is just old man shouting at a cloud, waiting for someone else to make it rain

Re: More Productive Git

#109

Post by ecma »

wincent wrote: post #83

The very first factual claim in the article is wrong: "The most basic usage is: git reset useful_func.clj This will replace the useful_func.clj in the current working directory with the last committed version in the repository HEAD." Not a good start. What it actually does is reset the path "useful_func.clj" in the index (AKA staging area) to the HEAD state. It doesn't touch the working directory.

It's not clear to me if the author actually understands how staging works and how that affects the commands they suggest. They claim that stashing takes staged changes and then note that after stashing the working tree will be clean. That suggests the post is being dumbed down or the author is misunderstanding things.

Git guidance should almost always start with a brief introduction to the concepts you believe the audience doesn't know or fully understand. To begin with reset and not properly explain the index will just end up being confusing, especially with brief references to hard, soft and mixed resets later on!

Re: More Productive Git

#110

Post by nlawalker »

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

> Git is a corded drill in a battery-powered drill world

Git isn't a corded drill in this analogy, it's an electric motor: the potential foundation of many different tools for different problems. There's nothing wrong with it, it's just that it would make more sense to use it as the basis of a more complete, ergonomic tool, rather than just sticking a drill bit into the spinning part.

/usr/bin/git is like curl: a command line tool for precise manipulation of an underlying data model/protocol. It's complex, but it works great - if you want to interact with the underlying data model/protocol on its terms. Many people want something that automates a more complex workflow to help them accomplish a higher-level task. For HTTP, we have browsers; for git, we don't have much yet.

Post reply on HN