Hacker News Reader

Comment by dirtydroog | Hacker News Reader

The thing is, git is a tool, it should be pretty easy to use. If someone has to write an entire book about rebasing then, in my opinion, there's something wrong.

I just push/pull/merge. I've never had any issues, a monkey could do it and would have to go out of their way to screw it all up.

"Noob! You don't understand how git works"... maybe true. I understand how source control should work. I have far more important things on my day-to-day plate then to dig into the internal workings of git. The branching setup described in the git-flow thing has been around far longer than git.

View on HN

I agree with Git being a (too) complex tool. However, I do not agree with the conclusion.

> I just push/pull/merge. I've never had any issues

If you're working alone or in a very small team, this may be true. But personally I am constantly (like monthly) helping my team mates fixing their Git issues. Last week our build job went rougue and created 400 commits with 60MB of data. We could have ignored it and lived with it for the rest of the repository's life - instead we just did a reset and rebased open pull requests. As if nothing ever happened.

And it's not only about issues. Knowing more then push/pull/merge makes the work more efficient. Example: not knowing how to amend changes (or not knowing that something like this even exists) will lead to useless commits ("Fix typo", "Add missed file"). In a git log, I don't really care. When doing a git blame (at least weekly), I would have to go through those useless commits to get to the commit I am looking for. Sure, it does take only a few minutes, but on the other hand amend is no Git internal black magic either.

I also remember a lot of situations where people "lost" (or maybe actually lost) their changes and had to redo them by hand. A one-liner might be fine, a full day of work is not.

> I have far more important things on my day-to-day plate then to dig into the internal workings of git.

You don't have to know the internal workings. But the fundamental knowledge on commit level (what is a commit? what is a branch? what does reset/checkout/rebase actually do?) makes most "advanced" features really easy. Spending a couple of hours to properly learn the tool I'm using daily gives a great ROI.

I’m torn on this one, because I firmly believe that git is way too complex. But I also don’t think “and entire book for one [technique]” is the litmus test we are looking for.

As a profession we are going on 80 years, and we need to start looking at what maturity looks like in other professions instead of trying to define it for ourselves... believing we can out think everyone, even people who have been thinking about things for a couple thousand years.

There are whole books describing how to use chisels. There are shelves of books on how to play Go, a game with really only a couple rules (and one of those is just to keep a game from going infinite turns).

But what these books are about is getting everything you possibly can out of a deceptively simple process. There is nothing deceptively simple about git.

Hi, Pascal the author here.

I'm probably not very good at expressing that the book is not only about rebasing. While it is the main focus, the book covers a lot of other things that aim to give you a really good understanding of the tool (which I believe is necessary to make sense of (interactive) rebasing).

And just like you said, you can totally get around with adding/committing/pushing changes without ever touching the rebase command. Perfectly fine.

If you want to be more flexible and productive with your work, you might want to learn how to rebase though.

Reply on news.ycombinator.com