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

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

361–370 of 404 posts

Re: Git rebase, what can go wrong

#361

Post by scme0 »

dkarl wrote: post #136
jimbob45 wrote: post #112

Earlier quoted context omitted.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. This is too much thought put into a VCS. I don’t want to have to think about my VCS at all beyond the commit message. For all of Git’s popularity, I’ve never seen benefits that justify the absurd amount of work and knowledge it takes t…

It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.

But if you're using pull requests, you can just look up the PR to get the reasoning and details of the squash commit. I would argue that if you need it to be separate commits after merging, you should create separate PRs most of the time.

Re: Git rebase, what can go wrong

#362

Post by watwut »

Chris_Newton wrote: post #309
mixmastamyk wrote: post #293

Earlier quoted context omitted.

If a strategy requires humans to be virtuous AND vigilant it is doomed to failure. I rarely use history and prefer merge/squash, with automated CI tools, and tests. "Why" is kept in doc strings, comments, specs, and story tickets. Everything viewable in gitlab with automatic links. All this gets out of the critical path, every day. I submit that, if your code is so complex that diagnosing a bug is a major research pr…

If a strategy requires humans to be virtuous AND vigilant it is doomed to failure. Sorry, but I don’t buy that. By the same principle, there’s also no point in writing unit tests or defining static types or having code reviews, all of which require thought and extra work, yet can yield considerable dividends when done even moderately well. I rarely use history and prefer merge/squash, with automated CI tools, and tes…

> there’s also no point in writing unit tests or defining static types or having code reviews

Not true. I do not do those to have nice clean process. I do unit tests, because without them the code is unstable and it is hard to fix bugs without causing unrelated ones. If the code is super simple and unlikely to break, I don't do test. I like to use static types, because I am much faster when writing them. The code is more readable and I have less bugs. Now, I have seen both useless and useful code reviews.

But, in all of those cases, things are done because they beneficial impact in final code and speed of delivery. Beautiful git history does not have such tangible measurable benefit. Git blame and bissect work without it, you just need one more step once in a while.

Re: Git rebase, what can go wrong

#363

Post by smcleod »

dkarl wrote: post #92
recursive wrote: post #5

Earlier quoted context omitted.

Squash merges cut down the noise considerably.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

Eh, commit history is handy to have but if you spend all your time crafting the perfect commit messages and history you’ve likely lost sight of what matters. Great is the enemy of good and make the tools do the work for you. Commit as many WIPs or whatever then just hit squash and merge - it saves a lot of time and keeps momentum up.

Re: Git rebase, what can go wrong

#364

Post by tomjakubowski »

btilly wrote: post #114
foobarbaz33 wrote: post #104

Earlier quoted context omitted.

> the mess is the actual history. The true history is not recorded in your normal commits either. Every time you modify your source buffer, that is the true sequence of events. This truth is lost already as you undo/rework things before you commit. You're ALWAYS manipulating and telling a false story of history whether you realize it or not. Commits are a tool that give stronger backup/undo protections over simple fi…

I believe that you are confusing "full history" and "true history". Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history. This is not a full history - you don't have every keystroke, abandoned commit, switch between branches and so on. But nothing th…

> Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history.

Committers always have a choice of which of the changes present in their working tree they stage and then commit. The commit history is always a flat approximation of the real evolution of the files in the repo.

Re: Git rebase, what can go wrong

#365

Post by tomjakubowski »

Nullabillity wrote: post #284
foobarbaz33 wrote: post #189

Earlier quoted context omitted.

> As soon as you do a rebase, you're rewriting history. Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch. > You're losing information about points of time and specific states that actually existed If you avoid r…

> Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch. The rebase becomes part of the public branch eventually, inflicting your lies on everyone else. > If you avoid rebase, then you end up "rebasing" without rebas…

Do you consider it lying when a commit doesn't include all changes in the working tree at the time it was committed? How about when a committer adds a file to .gitignore?

Re: Git rebase, what can go wrong

#366

Post by unlikelytomato »

fulafel wrote: post #352
unlikelytomato wrote: post #346

Earlier quoted context omitted.

I read this justification in nearly every thread that pops up git rebase. I feel like a full because I cannot think of a real world example when this information crosses from signal to noise. Generally, branches that are not ready to merge tend to have enormous amounts of noise commits. Is there a blog post or some concrete examples I could work through that illustrate these benefits? I feel like workflows dramatical…

It's a log of what happened in dev and supports reconstructing history to understand why something worked or didn't in retrospect. "It work when we tried it" "oh this dependency was updated in this merge commit that could have changed the behaviour"

I am not sure how this is unique to a merge commit. The commit with the dependency change still exists in the main branch. The commit should never have gotten into main branch of it failed tests. If I take a positive action to rebase, I am accepting my fate from master anyway. If I merge into my working branch instead of rebase, that historical context issue only useful for that moment in time of reconstructing history and is not useful anymore. Once a branch goes into master, I want commits to main to have a 1:1 ratio of committed code for a task to positive action taken by a human.

Re: Git rebase, what can go wrong

#367

Post by Chris_Newton »

watwut wrote: post #362
Chris_Newton wrote: post #309

Earlier quoted context omitted.

If a strategy requires humans to be virtuous AND vigilant it is doomed to failure. Sorry, but I don’t buy that. By the same principle, there’s also no point in writing unit tests or defining static types or having code reviews, all of which require thought and extra work, yet can yield considerable dividends when done even moderately well. I rarely use history and prefer merge/squash, with automated CI tools, and tes…

> there’s also no point in writing unit tests or defining static types or having code reviews Not true. I do not do those to have nice clean process. I do unit tests, because without them the code is unstable and it is hard to fix bugs without causing unrelated ones. If the code is super simple and unlikely to break, I don't do test. I like to use static types, because I am much faster when writing them. The code is…

But, in all of those cases, things are done because they beneficial impact in final code and speed of delivery. Beautiful git history does not have such tangible measurable benefit.

I respectfully disagree. In my experience, a tidy history directly benefits both efficiency and outcomes of code reviews, speeds up investigations of both bug reports and sometimes general background before starting new development, makes development much easier in situations where changes may need to be isolated and deployed to specific environments (not all software is a web app using CI/CD…), makes it much easier to back out a problematic change without causing unnecessary collateral damage, and helps to verify which development has actually been completed and deployed to which stages/environments, which can be useful for general awareness around the team but is particularly important if you’re operating in any kind of regulated field. All of that in exchange for usually spending less time in `git rebase -i` than it’s taken me to write this comment seems like a bargain to me, but YMMV.

Re: Git rebase, what can go wrong

#368

Post by naasking »

seba_dos1 wrote: post #335
naasking wrote: post #71

Earlier quoted context omitted.

"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.

The principal reason for VCS has nothing to do with "history" at all. It has all to do with "versions". What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. When you hack on some codebase and throw things at wall to see what sticks, you want to be able to go back to the previous attempt should your next one turn out to be…

> What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time.

In other words, the history.

> It's not a useful information and it never becomes a "version" of a shared project, because why would it?

Because the real world doesn't match your ideal of how software development works. You need the full history because sometimes innocuous looking "simple fixes" are neither innocuous nor fixes, and because obscuring the history makes auditing and merges more difficult, not less.

> It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use.

So blame and bisect are poorly written therefore you should hack around them using a convoluted process that obscures the true history and raises the risk of requiring people to redo weeks worth of work by overwriting branch histories on shared repos. Great idea.

The authors of Fossil and Sqlite did a complete breakdown of everything wrong with rebase and what a proper tool should do, so I won't belabour the point further:

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

Re: Git rebase, what can go wrong

#369

Post by jarek83 »

PaulDavisThe1st wrote: post #197
jarek83 wrote: post #187

"Don't make me think" has been the best principal of coding for me for a long time. Looking at how much thinking overhead rebase is producing, I'd prefer to avoid it.

One day you can suddenly get rebase, and then you almost never need to think about it ever again. Different people take longer/shorter to get to that point, and some people never make it.

I'm maintaining few projects and had really bad experience with rebase - it's about making sure that everyone in your team does rebase well and according to team rules, but it's just one mistake away to get into some drama, which I had been through few times. Once rebase has been disallowed, I never had to solve similar issues again.

Re: Git rebase, what can go wrong

#370

Post by lolinder »

leptons wrote: post #351
lolinder wrote: post #316

Earlier quoted context omitted.

> not committing until the feature is working and ready to commit is also a thing That leaves you prone to losing work if you have a false start that you need to back out of. I prefer to commit early and often on my private branches, then before submitting a pull request I clean up the history to where there are a few good commits that form useful, standalone chunks (ideally the test suite fully passes on each commit…

>That leaves you prone to losing work if you have a false start that you need to back out of. Hasn't happened to me in over 20 years of using version control. I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same. If I wanted to try a new direction I'd just clone the repo again and do the work there. Littering the git histo…

> Littering the git history with dozens of superfluous commits just seems pointless.

This is where the final rebase comes in—you should be combining all the small commits into one.

> Having to stop and think about writing a commit comment is also just a waste of time

Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later.

> I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same.

You've never started down one path for solving a subproblem only to realize 30 minutes in that it's not going to work?

Post reply on HN