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

141–147 of 147 posts

Re: More Productive Git

#141

Post by ofrzeta »

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…

I am also taking a guess: https://codewords.recurse.com/issues/two/git-from-the-inside...

Re: More Productive Git

#142

Post by mathieuh »

XCSme wrote: post #135
mathieuh wrote: post #55

Earlier quoted context omitted.

I honestly can't say I have ever had this problem. I also don't understand how you could forget to revert the revert? And why would new commits matter? Sure you may have conflicts, but you would have had them anyway if you hadn't reverted. We've had to revert commits on our master branch after several commits have been added on top before, and we've never had an issue just checking out a branch off master and reverti…

You can easily forget if someone else (not yourself) did this (they merge the branch and reverted it), later when you try to merge the branch it could be successful, without any merge conflicts, but still won't lead to the expected changes.

OK I suppose that is more likely, but I still think this is easily-avoidable through process. If you're closely-enough involved with a ticket that you were going to be the one merging it, I think it's reasonable to expect that you have an idea of things that have happened in the story.

Re: More Productive Git

#143

Post by chiefalchemist »

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…

> "I need people that can learn things at least as complicated as git, because they’re gonna have to keep up."

Not to get off topic, but it's your #1 job as team leader to put your people in the best position to succeed. Pounding you fist on desk and shouting "keep up" doesn't cut it.

The question here isn't what is or isn't learnable. The question is, why so much tension and friction (i.e., using the CL) when a visual representation is actually the far better representation of the model / data?

Keep up? Why are we tossing rocks in their toolbox?

Re: More Productive Git

#144

Post by finnthehuman »

chiefalchemist wrote: post #143
finnthehuman wrote: post #97

Earlier quoted context omitted.

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…

> "I need people that can learn things at least as complicated as git, because they’re gonna have to keep up." Not to get off topic, but it's your #1 job as team leader to put your people in the best position to succeed. Pounding you fist on desk and shouting "keep up" doesn't cut it. The question here isn't what is or isn't learnable. The question is, why so much tension and friction (i.e., using the CL) when a visu…

I don't pound my fist on my desk like I need more pictures of Spiderman, the nature of the product domain we're working in is demanding.

This is not a defense of the status quo. It's an observation about working within the status quo. If I could choose for everything else to remain equal but git get easier, of course I'd take it. I'd choose for a lot of things to be better, not just software.

My observation is that of all the things a developer might encounter for the first time on our project and be asked to learn, git isn't a standout. This is what I meant by keeping up; there's a lot to learn.

We do what we can to reduce the load, spread it out, and I refine the crash course for new developers every time someone goes through it. But at the end of the day, we have jobs because we can pick this stuff up and get to work with it. Even if git is less than the platonic ideal of version control.

Re: More Productive Git

#145

Post by Seb-C »

GauntletWizard wrote: post #54
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…

Here's mine: [alias] git = !cd -- ${GIT_PREFIX:-.} && git This turns my most common typo (starting to type a git command, thinking about it, typing 'git' again) into what I wanted it to be.

  [help]
      autocorrect = 1
This one is very useful too.

Re: More Productive Git

#146

Post by Seb-C »

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.

I didn't use the staging area until I started to use git add -p. Now I use it very often to properly separate mixed changes into more logical commits.

It makes the staging very convenient to use. But without this command, I agree that it is a pain to use.

Re: More Productive Git

#147

Post by agumonkey »

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…

it's not the DAG per se, it's how git layers operations on top of it
Post reply on HN