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

31–40 of 147 posts

Re: More Productive Git

#31

Post by chiefalchemist »

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 out of the Dark Ages.

It's time for an intervention. It's time to take seriously the friction and frustrations it creates. Yes, it has redeeming qualities. But it's time to stop looking past those and do something about them (other than another article such as this one).

Re: More Productive Git

#33

Post by jordigh »

derwiki wrote: post #11
kyberias wrote: post #9

Doesn't look right if an article starts by introducing git reset and git reset --hard.

What makes you say that? I use that command nearly every day.

I think this exchange between you two perfectly exemplifies why git is hard: everyone has a different interpretation of it.

Re: More Productive Git

#34

Post by kyberias »

derwiki wrote: post #11
kyberias wrote: post #9

Doesn't look right if an article starts by introducing git reset and git reset --hard.

What makes you say that? I use that command nearly every day.

There is something wrong with your workflow if you have to use git reset --hard nearly every day.

Re: More Productive Git

#35

Post by XCSme »

mathieuh wrote: post #27
XCSme wrote: post #15

One mistake that I saw several times is cherry picking or merging another branch into the current one, then realizing later that you didn't need those changes yet, and you revert the merge commit. Later, if you actually want to merge the other branch into the current one you will get in trouble as it's already "up to date", as the current branch is ahead. Even worse, if you instead merge the current branch into the o…

You can just revert the revert commit.

Biggest issue is the first part, when it's "already up to date", so then when you merge the feature into the current branch and think it's merged, it will actually be missing, so you might forget to revert the revert, or not work anymore because of new commits/conflicts.

Re: More Productive Git

#36

Post by kyberias »

jordigh wrote: post #33
derwiki wrote: post #11

Earlier quoted context omitted.

What makes you say that? I use that command nearly every day.

I think this exchange between you two perfectly exemplifies why git is hard: everyone has a different interpretation of it.

It may seem hard if you don't know how to use it.

Re: More Productive Git

#37

Post by anamexis »

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'm guessing that was this article which was on HN 2 weeks ago: https://news.ycombinator.com/item?id=19877811

Re: More Productive Git

#38

Post by butterNaN »

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…

It isn't entirely useless, there's a chance that someone who still has that article can link it here : )

Re: More Productive Git

#39

Post by jordigh »

ChrisSD wrote: post #8
wyldfire wrote: post #6

Earlier quoted context omitted.

> 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 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 don't need an extra intermediate area to review a commit. Commits are flexible and modifiable, so you can review the draft commit, modify it as necessary, and then publish it.

Re: More Productive Git

#40

Post by house9-2 »

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. I think git would be easier if we didn't have it.

Staging area / Index is one of the best features of Git for me.

If I end up having a bunch of semi related changes in-progress; being able to easily group those into individual commits is great.

> The term `checkout` is multiplexed to do more things than I would've guessed.

Agree

Post reply on HN