Hacker News Reader

Comment by nixpulvis | Hacker News Reader

I feel like if you're scared of rebasing, you don't actually understand git.

My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)

If all I'm doing with git rebase is reorganising my commits, and I have to deal with conflicts, after I'm done, I always git diff my pre-rebase head with post rebase head commit hash. I can quickly see I've messed something up if the diff isn't empty. For more complex tasks it's best to leave the rearranging until last, but where not possible, the diff is still pretty useful to double check my work.

range-diff can be useful for that too.

Setting:

    merge.conflictStyle = zdiff3

made most of my fears regarding conflict resolution go away, as it right away gives me the stuff that I used to look for manually to understand the context of the conflict, which was probably the most error prone part of the process.

Like all git operations that destroy history, it's a bit less scary than rm or unlink, because you can undo obvious fuckups using the reflog. Non-obvious fuckups will (by Murphy's law) only be detected long after the reflog has been GC'd, so it still risks losing work.

Git was written with Linux in mind, where curating a clean commit history is more important than the code itself and warrants the extra hassle.

An actually usable rebase would probably require something like a meta history. But then the meta history would accumulate fixup "commits" and typos in commit messages so the OCD people will want to change that and we're back to square one. In practice, the two times per decade it actually makes business sense to dig through the history to find when a bug was introduced instead of just writing the 5-line fix, you can live with a couple of imperfect commits and merges.

Reflog is, as the article says, the permission to do all kinds of crazy things, including rebasing. Once you realize any committed state is recoverable for a good period of time it really frees you.

Plus you can always take a note of the commit hash before you do anything crazy. But reflog means you don't have to.

Git really does have all the features you need. I wouldn't argue with anyone complaining about the UI to get there. But it's all in there somewhere.

I think the only missing thing for me would be to group commits, essentially squashing them for a clean history while allowing to unsquash them in case you need it.

git reflog can only help if the reflog history hasn't expired and been removed by a maintenance run.

The part where git needs to be “understood” is the entire problem. “Do one thing and do it well” was the whole mantra, which was completely ignored with the disaster that is git. It’s objectively awful.

It could be so much better. At the same time, it’s one of the core tools for a developer. You’ll learn it eventually. You’re going to be using version control for decades. I’ve met devs many years into their careers who don’t understand rebase. It’s like going to a metal shop and they’re complaining about the learning curve on their welder and half the tradesmen are still at a novice level.

I still don't know it very well, and it's been well over a decade. I think it's a combination of a few things:

- I find it uninteresting. My version control needs are very simple.

- Most teams I have been in use a small subset of it.

- It's confusing terms and inconsistent cli are huge warning signs to not go down that rabbithole. Today instead of learning Git I read some Tony Hoare, much better.

I've been at once place where they rebased, and it was awful. Complete waste of time. (great place otherwise though)

Give it an hour or two. It is really not that complicated. A little bit of investment will pay huge dividends. Do yourself the favor.

I could say the same for reading Tony Hoare.

Have you ever read any of the introductory material that the git project itself maintains for teaching how to use the tool?

- https://git-scm.com/docs/gittutorial

- https://git-scm.com/docs/giteveryday

- https://git-scm.com/docs/gitworkflows

- https://git-scm.com/docs/gitfaq

- https://git-scm.com/cheat-sheet

Or if you want to sit down and really learn the nuts and bolts

- https://git-scm.com/book/en/v2

Looks like an incredibly dull way to waste hours of my finite life for microscopic benefit.

The first five links (i.e. not the book) are each only a few printed pages worth of text each or less. All together they are equivalent to like a single chapter of text in a book.

It really won't take hours. You probably read more than that just looking at HN for like 20 minutes.

yeah I would really love to see a subset of git with a sane cli. would switch in a heartbeat.

Fossil?

Git has been re-designing their tooling over the last few years. Nowadays there exist really pleasant, easy to use versions of the main tools.

switch and restore replaced checkout. history is being developed to replace rebase for most common use cases. maintenance replaces gc. etc.

Absolutely everything in computing needs to be 'understood' to be used.

Really? How familiar are you with how inodes work on a spinning platter vs an eMMC? Can you speak intelligently about how virtual machines segregate their ram boundaries whilst still maintaining decent performance? What is your familiarity with FIPS?

You’re very incorrect.

And you were born with an understanding of how a keyboard and mouse worked or how windows seperated different GUI contexts and what all those symbols around them meant? I'm not saying you have to understand the nuts and bolts because abstractions exist but those abstractions still present you with a model and you need to understand that model to use them. People often present git's model mixed in with its nuts and bolts, which I think is unhelpful because the model is actually really simple and the nuts and bolts are not so important.

Have you never seen a toddler touch a non-touch screen and be like “wtf?” Or watch a child holding mom’s phone swipe away a text message alert?

Yes, good software is absolutely intuitive. Git is garbage.

Because they've already learned a model of how devices with screens work, albeit an imperfect one. Children are pretty good at learning. Software and systems should be easy to learn, but it's not a case of no learning.

So you agree then. People have been saying from inception that git isn’t intuitive.

I agree that git's UI is not particularly easy to learn, and it could be better in that regard (which is frustrating because its underlying model is about as simple as you can come up with, and I essentially can always think of what I want in that model easily but then have to google how to tell git to do it). What I object to is the idea that needing to understand something to use it is a problem.

You only have to learn three things to use a computer: Your shell, your editor, and your version control system.

That's it. That basic knowledge will carry you far, and will be useful a decade from now. Those are the three best afternoons you can spend. Do it out of respect for the computer.

I am gainfully employed because I’m decent at those 3 things. I’m not sure why you assume I’m not. Fair point though.

sounds like someone accidentally delete your repo because they didn't understand git and did a dumdum :P

When I interview someone and they are scared of `git rebase -i` it's a huge red flag.

Git rebase has such foundational data structures and concepts that you couldn't pass a serious college programming course without grokking it.

The only reason someone would be scared of git rebase is:

  a) they don't know the basics of programming/software engineering
  b) they are not intellectually curious enough to look into how tf the software they use every day works

You probably shouldn't have engineers like that on your team.

I'm genuinely unsure why rebase interactive is more scary than rebase

Yeah I never use non-interactive rebase. Even if I don't need to edit the todo list, reading it gives me a confirmation of what git will do.

An interviewer asking me about git rebase is the huge red flag

Genuine question, why? It seems like a reasonable knowledge check that can be answered in a few sentences.

Understanding git rebase is important. You aren't expected to rebase mainline branches regularly but if your team operates on a merge/patchset workflow and isn't just squashing everything down onto main each PR you need to understand how to rebase your changes.

You do your development and use rebase to organise your code into logical commits/patches that can each be reviewed separately. This way when you do your review in github or on the mailing list or whatever you can review each logical change by going through and reviewing the commits separately (which you can do in github by selecting the commit in the dropdown for the review window).

And of course via email based workflows or "stacked patchset" workflows like what tangled provides then you can get deltas between revisions so that you can see what changed in a given commit between rev 1 and rev 2 so that you don't have to re-review the entire patchset/PR, only the stuff that matters (but still broken up into logical changes).

I wonder if it's because it opens in the default visual editor (typically vi/vim) and while I'm primarily a (neo)vim user now, it is certainly not the most intuitive editor to get started with without guidance.

You can always set the editor in your --global or --local config though:

  git config core.editor "vim"

I do agree that using the default editor is a mostly a bad choice due to it being vi/vim rather often.

I know, but as you say that still presents a barrier to entry.

A lot of talented developers that I've worked with use visual git clients exclusively, so imagine their horror when presented not only with an editor they don't use, but also a text-based menu (`git rebase -i`).

This notion that `git rebase -i` is some scary unusual thing is totally alien to me. Doing some minor cleanup on local history with rebase is a *basic* operation that I would have thought everyone would be using regularly.

I'm not scared of rebasing I'm scared of force pushing

Correct on both counts.

Reply on news.ycombinator.com