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

Extremely Linear Git History

westling.dev

Post reply on HN
Print view View original

271–280 of 366 posts

Re: Extremely Linear Git History

#271

Post by cerved »

sidlls wrote: post #141
larschdk wrote: post #49

I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…

Rebasing is a tool of last resort, when something has so fowled up the code that merging a large-scale refactor is even more time consuming. Rebasing takes longer and is actually more prone to error because of the clunky interface. There is absolutely nothing wrong with squashing commits in a feature branch and merging that into master/main. In fact, it's generally better for the health of the repo and the mental hea…

in my experience, rebase works great if the commits are structured and much more painful with lots of overlapping changes, say by continiusly doing _wip_ commits every hour

Re: Extremely Linear Git History

#272

Post by MaxBarraclough »

couchand wrote: post #224
Beltalowda wrote: post #200

Earlier quoted context omitted.

> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase…

> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

  > If you have multiple long-lived branches, there's no technical
  > solution to preventing rot -- you must actively keep them in sync.
Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync.

  > Regularly merging in main is the opposite of the proper solution.
  > Constantly rebasing on top of main is the proper solution.
Why? You've given no justification for your preference.

Re: Extremely Linear Git History

#273

Post by couchand »

MaxBarraclough wrote: post #272
couchand wrote: post #224

Earlier quoted context omitted.

> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

> If you have multiple long-lived branches, there's no technical > solution to preventing rot -- you must actively keep them in sync. Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync. > Regularly merging in main is the opposite of the proper solution. > Constantly rebasing on top of main is the proper solution. Why? You've given no justification for your preference.

> Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync.

I never said it was, I said it was the right way to keep them in sync.

> Why? You've given no justification for your preference.

I don't need to, the GGGGP said it perfectly: https://news.ycombinator.com/item?id=33705026

Re: Extremely Linear Git History

#275

Post by couchand »

cerved wrote: post #240
GuB-42 wrote: post #86

Earlier quoted context omitted.

> I want the 'merge' function completely deprecated. I simply don't trust it anymore. Merge is perfectly fine and it is the only way to synchronize repositories without changing the history, which is very important for a decentralized system. It certainly has the potential to make a mess if used improperly, but so do rebase, cherry-pick, and basically every other command. > If you use merge to sync two branches conti…

way easier to mess up a rebase

way easier to tell that you've messed up a rebase

Re: Extremely Linear Git History

#276

Post by couchand »

xxpor wrote: post #254
couchand wrote: post #251

Earlier quoted context omitted.

Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.

Touching files in .git (outside of like, .git/config) directly gives me the heebee jeebees

Fair point, and I would not advocate that specific workflow! My point was just to illustrate that we can live without merge.

Re: Extremely Linear Git History

#277

Post by cerved »

couchand wrote: post #275
cerved wrote: post #240

Earlier quoted context omitted.

way easier to mess up a rebase

way easier to tell that you've messed up a rebase

it's actually way easier to accidentally mess up a rebase, especially if rearranging commits.

I can recommend git diff @{1} post rebase I alias it to d-

Re: Extremely Linear Git History

#278

Post by couchand »

cerved wrote: post #277
couchand wrote: post #275

Earlier quoted context omitted.

way easier to tell that you've messed up a rebase

it's actually way easier to accidentally mess up a rebase, especially if rearranging commits. I can recommend git diff @{1} post rebase I alias it to d-

I'm not sure if you misread my comment, but my point was that it's far too easy to accidentally introduce bugs in merge commits that go unnoticed for a long time.

I've never seen a rebase gone awry introduce production bugs, but I've known multiple gnarly bugs caused by errant merges. YMMV.

Re: Extremely Linear Git History

#279

Post by couchand »

infogulch wrote: post #245

Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies: All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash. If you want more detail about the development of the PR…

What's weird about most of these discussions is how they're always seen as technical considerations distinct from the individuals who actually use the system.

The kernel needs a highly-distributed workflow because it's a huge organization of loosely-coupled sub-organizations. Most commercial software is developed by a relatively small group of highly-cohesive individuals. The forces that make a solution work well in one environment don't necessarily apply elsewhere.

Re: Extremely Linear Git History

#280

Post by loeg »

jstimpfle wrote: post #39
gyulai wrote: post #29

Sane revision numbers are among the many reasons I prefer SVN to GIT.

You could automatically tag each uploaded commit with a number drawn from a sequence - using a git post-update hook. The only problem is that this centralizes the process. It's not possible to have fully "blessed" commits without pushing them first. And that's how SVN works, too.

For local repositories, you can do it as a post-commit hook.

In the hook:

  prefix=whatever
  old=$(git rev-parse HEAD)
  new=$(brute force $prefix)
  git update-ref -m "chose prefix $prefix" --create-reflog HEAD "$new"
Of course, it's pretty silly and slow.
Post reply on HN