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

Git rebase in depth

git-rebase.io

Post reply on HN
Print view View original

111–120 of 248 posts

Re: Git rebase in depth

#111

Post by brandmeyer »

V-2 wrote: post #30
Amorymeltzer wrote: post #24

The warning regarding "public, shared, or stable branches" is always warranted, but I think those warnings end up reverberating where they needn't. Before interacting with anything public or shared — when working solo or locally — `rebase` can be hugely helpful. When starting out with something complicated, I often make separate commits for different files or steps; using rebase to reorder commits or amend can make t…

I'd use rebase --interactive quite aggressively on a public branch when it's a feature branch that's not yet been merged. As I'm the only owner of it, the way I see it I owe no guarantees to anyone. You're welcome to watch it, but it's work in progress in every aspect.

My team does this for branches during the code review process all the time, and it works great.

Re: Git rebase in depth

#112

Post by cryptonector »

I've a script I need to publish that does a bisect-like thing to rebase across thousands of commits quickly and ensuring that when there are conflicts you are asked to resolve them at the commit that caused them. It was original written by @vdukhovni (GitHub).

Also, I've this gist on how to think about git: https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...

Re: Git rebase in depth

#113

Post by ZeroGravitas »

dahart wrote: post #68
dan00 wrote: post #51

Earlier quoted context omitted.

It is right that the previous commits are still there in the repo, but from the point of git they are garbage now and going to be removed. The point are the commits reachable now from the branch.

What’s the matter with reachable and unreachable commits? Commits no longer needed should be unreachable and cleaned eventually, that’s a feature. Git is fantastic about keeping the unreachable commits for long enough that should I actually need them for any reason, they’re usually there. The default is 90 days. The number of times I need to dig into the reflog for any reason is very low, and always because I made a…

> The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake.

A good UI should allow you to recover from mistakes. Like the trashcan vs rm example everyone is using.

It's good that git doesn't permanently delete stuff, it's bad that you need to be a relative expert to know that. If git branch showed rebased branches and told you they would disappear in x days then beginners might feel less fear and embrace the power of git faster.

Re: Git rebase in depth

#114

Post by nacho_weekend »

gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

Yes, I agree. Rebase has the ability to obfuscate and rewrite commits if you so choose. Rebasing to just re-order commits is totally viable and perhaps encouraged. We did this at a previous company and it made the commit history very clean to read. However, with great power comes great responsibility in a rebase, and a junior dev can easily mess things up if you don’t educate them properly.

Re: Git rebase in depth

#115

Post by dahart »

Buttons840 wrote: post #102
Chazprime wrote: post #58

Earlier quoted context omitted.

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's more advanced features (especially in a team environment).

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

> git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch.

Yeah, completely unreachable commits have 30 days, even when you run git gc. The default reflog for a branch is even longer: 90 days!

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

Re: Git rebase in depth

#116

Post by mixmastamyk »

zemo wrote: post #106
mixmastamyk wrote: post #99

Earlier quoted context omitted.

History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.

it's not "inspecting grains of sand". If you have any number of developers worth talking about, merge-oriented workflows can create incredibly unwieldly git histories very quickly. I'm talking about, at a very high level, just understanding the history of the project. If you have five feature branches going on, and your developers are all committing on a regular basis, understanding the history and cadence of your pr…

It's easy enough to select commits from one user, or squash whole branches. Our devs are judged on completed features they deliver at acceptable quality, not their commit history.

I'm not saying you shouldn't care, just that I don't believe this strategy will become mainstream unless it gets much easier to understand and use.

Re: Git rebase in depth

#117

Post by fulafel »

Sir_Cmpwn wrote: post #27
jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."

PRs are a good unit of changes for examining meaningful units of changes. No reason to lose info about how the sausage was actually made, it is also a valuable record

Re: Git rebase in depth

#118

Post by zemo »

Git rebase is great. Honestly I think the argument that "if you have to push -f that means rebase is wrong" is making a huge assumption about how people use branches and why people are force pushing branches.

Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket have taught people to conduct PR's.

If your immediate reaction is that "rebase is bad UX", ask yourself whether or not pull requests are good UX. I honestly think rebase is great, but that pull requests are extremely bad UX, and the UX blame is misplaced on rebase when where it really belongs is on pull requests.

Re: Git rebase in depth

#119

Post by dahart »

AlexTWithBeard wrote: post #104
pmiller2 wrote: post #86

Earlier quoted context omitted.

Git has very good safety even if you don’t know how to use it, provided you commit when you want something to be saved and you don’t rm the whole repo at the first sign of trouble.

I think my issue is that most people should not even know how this safety net works. But every other question about git on stack exchange seems to be "how do I recover from a failed rebase".

You have your wish: most people already don't even know how the safety net works. :P The existence of questions on a site designed to ask questions is not any indicator of how often rebase causes problems. Nobody posts to stack exchange every time it works and they're not confused. Aren't the questions on stack exchange a good thing, if what you want is for people to not have to learn the safety net? Just commit and rebase until there are problems, then if you get confused, go look up the answer on stack exchange or post a question if you don't see one already. Seems like the system is working?

Re: Git rebase in depth

#120

Post by anamexis »

nacho_weekend wrote: post #114
gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

Yes, I agree. Rebase has the ability to obfuscate and rewrite commits if you so choose . Rebasing to just re-order commits is totally viable and perhaps encouraged. We did this at a previous company and it made the commit history very clean to read. However, with great power comes great responsibility in a rebase, and a junior dev can easily mess things up if you don’t educate them properly.

OP's point was that rebasing cannot rewrite commits. It can only make new commits and change branch pointers to them.
Post reply on HN