Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase -i is not that scary

cachebag.sh

Post reply on HN
Print view View original

81–90 of 155 posts

Re: Git rebase -i is not that scary

#81

Post by barrkel »

vivzkestrel wrote: post #36

- i often go back like 5 commits and make changes like this - git rebase -i ^ - select edit - git reset --soft HEAD~ - make some changes - git add . && git commit -m "changes" - git rebase --continue - Am I using git rebase wrong?

No, but you would find jj solves this problem far more elegantly.

Re: Git rebase -i is not that scary

#82

Post by fisensee »

Git rebase isn't scary at all, what's scary is the git rebase cult. I'll probably die never really seeing the tangible benefit a meticulously curated git history provides but at least I saw a few hundred blog posts and hn comments declaring the moral failure that is not having the cleanest commit history. The cynic in me would say that people are over-identifying too much with their recent bikeshedding addiction (just like 10-page vim configs, custom built keyboards or whatever else promises them immense but immeasurable performance gains) but in reality I guess it's just completely different mental models about code. I have yet to look at any code or it's however dirty history and needed to consult a commit message to understand what it's there for but I'm looking forward to the day where one of my rebase colleagues fixes a bug with git bisect that wasn't efficiently fixable any other way.

Re: Git rebase -i is not that scary

#84

Post by skitsofrandom »

zith wrote: post #80

A workflow I was introduced to and have worked with a lot in my teams is, 1. Everyone uses feature branches 2. Everyone cleans up their branch using interactive rebase on top of main before review 3. All merges have been freshly rebase on main I think it works very well and keeps the history clean while preserving "each commit does one thing".

I worked on a team that did this, + required feature branches to get squashed to a single commit before merge. On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR. This made git blame a lot more helpful when debugging issues. I am a big fan of this approach.

Re: Git rebase -i is not that scary

#85

Post by xorcist »

flyingcircus3 wrote: post #9

After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walkin…

This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.

Re: Git rebase -i is not that scary

#86

Post by geon »

fisensee wrote: post #82

Git rebase isn't scary at all, what's scary is the git rebase cult. I'll probably die never really seeing the tangible benefit a meticulously curated git history provides but at least I saw a few hundred blog posts and hn comments declaring the moral failure that is not having the cleanest commit history. The cynic in me would say that people are over-identifying too much with their recent bikeshedding addiction (jus…

I fix bugs will git bisect all the time. But it’s not practical if you don’t have a good commit history to begin with.

Re: Git rebase -i is not that scary

#87

Post by dijksterhuis »

skitsofrandom wrote: post #84
zith wrote: post #80

A workflow I was introduced to and have worked with a lot in my teams is, 1. Everyone uses feature branches 2. Everyone cleans up their branch using interactive rebase on top of main before review 3. All merges have been freshly rebase on main I think it works very well and keeps the history clean while preserving "each commit does one thing".

I worked on a team that did this, + required feature branches to get squashed to a single commit before merge. On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR. This made git blame a lot more helpful when debugging issues. I am a big fan of this approach.

> On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR.

one of the first things i do in a new gitlab repo is set up ff+squash commit merges with the squash commit message template automatically pulling the MR title, link, description, authors etc.

    %{title} 

    -
    ref: %{reference}
    url: %{url}
    authored by: %{merge_request_author}
    merged by: %{merged_by}
    -
    %{description}

Re: Git rebase -i is not that scary

#88

Post by xorcist »

irishcoffee wrote: post #18
nixpulvis wrote: post #7

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

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.

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.

Re: Git rebase -i is not that scary

#89

Post by xorcist »

fisensee wrote: post #82

Git rebase isn't scary at all, what's scary is the git rebase cult. I'll probably die never really seeing the tangible benefit a meticulously curated git history provides but at least I saw a few hundred blog posts and hn comments declaring the moral failure that is not having the cleanest commit history. The cynic in me would say that people are over-identifying too much with their recent bikeshedding addiction (jus…

People are different, and I think we have to respect that. In my role I tend to have to fix problems in other people's code probably on a weekly basis. Commits that do too much, or too little, or are generally hard to understand are the number one reason this takes time. Crafting readable commits takes seconds out of your work day. Please be considerate to all your future colleagues.

Re: Git rebase -i is not that scary

#90

Post by gsliepen »

If you do a rebase -i because you want to squash or fix some commits, then there's git commit --squash and git commit --fixup commands which will mark commits as intending to squash or fixup another commit, and then you can use git rebase --autosquash to automatically do what you want in one go. Of course, often you forget to use the --squash/--fixup options or you can't be bothered to lookup the hash of the commit you want to fix, so you'll end up using git rebase -i anyway.
Post reply on HN