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

121–130 of 147 posts

Re: More Productive Git

#121

Post by booleandilemma »

chiefalchemist wrote: post #112
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…

> "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 they occasionally attended data structures and algorithms class." And those can (read:should) have a visual representation, yes? Why are we still typing archaic/cryptic co…

So you're saying you don't know how to use Git then?

Re: More Productive Git

#122

Post by cheerlessbog »

jordigh wrote: post #39
ChrisSD wrote: post #8

Earlier quoted context omitted.

I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).

The staging area is incidental. It's yet another place in which your code can be, and it confuses users. This is why Gitless has removed it. https://gitless.com/#vs You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit. You do…

I didn't know about Gitless. The other interesting thing I see about it is that switching branches also switches out any uncommitted changes. On balance I think I find that less useful.

Re: More Productive Git

#123

Post by booleandilemma »

tbrock wrote: post #102
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.

Same. Came here looking for a comment that would point this out and I was not disappointed.

Trying to learn something from a bad article is worse than reading no article at all.

Re: More Productive Git

#124

Post by cs02rm0 »

nagyf wrote: post #86

> A common workflow is: > Mess up your Git repository. > Google some error messages and read cryptic > > posts. > Try a few fixes. > Tear hair out. > Delete repository and clone again. You don’t have to be a genius to use git, I’ve never experienced anything like this, even though I’ve worked in 15-20 member teams with lots of conflict and all that. Read the docs and use it as it is suggested. I don’t think it is tha…

It totally is, but probably not for people working with as many as 15-20 others who can help out!

Re: More Productive Git

#125

Post by jldugger »

chiefalchemist wrote: post #112
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…

> "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 they occasionally attended data structures and algorithms class." And those can (read:should) have a visual representation, yes? Why are we still typing archaic/cryptic co…

> Why are we still typing archaic/cryptic commands

I mean, you're just describing the act of programming in general here.

Re: More Productive Git

#126

Post by saagarjha »

emmelaich wrote: post #103
saagarjha wrote: post #72

Earlier quoted context omitted.

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/

That seems to be a legacy thing: https://github.com/Homebrew/homebrew-core/blob/master/Formul...

Re: More Productive Git

#127

Post by mohitsingh »

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.

Agreed. Specially, flags of these commands are actual magic when it comes to productivity, at least for me. For example, not all flags of git commit command are used frequently but they perform a lot of different operations and can be easily combined to save the day.

https://git-scm.com/docs/git-commit#_options

Re: More Productive Git

#128

Post by narnianal »

ecma wrote: post #109
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 au…

I see this so often with power user tools. All power user tools are tools that you can only use reasonably well with some basic understanding. They are made not to be understood in the easiest fashion but to handle all complexities of a problemset as efficiently as possible. Therefore it sometimes seems harder to use from the outside, but actually the hardness comes from the problem it solves, not the tool.

So yeah, if you really want to use git well, learn its internals. It takes some time but actually not even hard. After reading the Git Book once I was even able to implement my own git (of course without performance considerations).

Re: More Productive Git

#129

Post by narnianal »

jordigh wrote: post #30
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.

The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people. Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things. Git would be easie…

Sorry, but it seems like you've worked in very low skilled teams. There are sometimes two different solutions to a problem, but they come with different pros and cons and you need to decide which to choose based on balancing reasons, not based on having different understandings of how git works.

For instance, when you have lots of parallel work, you have to decide whether to merge-commit each into the mainline or wether to rebase them. The first is an honest view of what happened, but might be harder to read. The other is easier to read, but might not represent well what actually happened. Git doesn't work one way or the other. Both is fine for git. And you should also be aware what it does under the hood for both options.

Re: More Productive Git

#130

Post by narnianal »

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 term `checkout` is multiplexed to do more things than I would've guessed.

Do you mean `pull`?

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

It's an interesting POV. Especially since you can easily amend and rebase -i before pushing without any consequence. Thanks for the idea. I implement a git-like for a special use case at the moment and will certainly consider this.

Post reply on HN