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

291–300 of 366 posts

Re: Extremely Linear Git History

#291

Post by titzer »

wirrbel wrote: post #261
thewebcount wrote: post #174

Earlier quoted context omitted.

Absolutely. In my experience, it’s only “not toxic” to a few people, and for most others it is toxic, but the people who like it won’t ever be able to see that.

For the record: I am not recommending people to adapt a toxic culture. What I would like people to take away from these discussions is the curiosity to question established practices and processes and re-evaluate the cost-benefit ratio of process steps just like the manufacturing people I write software for continue to optimize their working mode again and again

I think CI (even better, commit queue) is pretty much table stakes for a 3+ person project at this point.

Re: Extremely Linear Git History

#292

Post by jzer0cool »

I had in past some teammates merging master into a very old branch. This get's pushed back into master with every past history already committed. Could someone suggest series of command so that only their latest updates are separately moved to latest version of master on current or new branch?

Re: Extremely Linear Git History

#293

Post by jamespwilliams »

TheRealPomax wrote: post #290
simiones wrote: post #83

Earlier quoted context omitted.

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…

To be fair, if you have 10 commits that all change the same file: squash with respect to your first commit, _then_ rebase. If you have lots of commits, always first squash-rebase to your own first commit, and only rebase to current main once that's done. Rebase is being annoying here mostly because it's doing exactly what you want it to do: warn you about merge conflicts for every commit in the chain that might have…

If you squash you decrease the granularity of your git history, though.

Re: Extremely Linear Git History

#294

Post by anderskaseorg »

zegl wrote: post #140

I don't know how stupid this is on a scale from 1 to 10. I've created a wrapper [1] for git (called "shit", for "short git") that converts non-padded revisions to their padded counterpart. Examples: "shit show 14" gets converted to "git show 00000140" "shit log 10..14" translates to "git log 00000100..00000140" [1]: https://github.com/zegl/extremely-linear/blob/main/shit

You may want to take a look at the monotonic commit numbering scheme that Git already has, before trying to hack one into the hashes:

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

Re: Extremely Linear Git History

#295

Post by couchand »

jacobsenscott wrote: post #288
couchand wrote: post #273

Earlier quoted context omitted.

> 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

A rebase and a merge result in the same code. A rebase is more error prone though. Just because someone "feels" a merge isn't as safe doesn't make it so.

> A rebase and a merge result in the same code.

If done correctly, that's true, but it's beside the point. The reason to prefer one over the other is the failure mode.

> A rebase is more error prone though.

On what metric? In my experience, a merge is far, far more likely to silently introduce a production bug. I've never seen a rebase fail that way.

Re: Extremely Linear Git History

#296

Post by Beltalowda »

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.

> 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.

Well, merge actually works much smoother and rebase gives a lot more grief, so the problem is with rebase.

> Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

The "proper" solution is the one that allows me to get stuff done. The only thing that matters is how the main branch ends up looking in the end, and what I do before that isn't really all that important.

Another problem with rebase is when multiple people are working on the branch; it requires careful coordination if you don't want to lose work. Overall, just merge in main is usually the best strategy here.

Re: Extremely Linear Git History

#297

Post by wnoise »

cerved wrote: post #268
wnoise wrote: post #227

Earlier quoted context omitted.

Yes, it is a shame that you can't combine git merge --ff-only --no-ff .

git rebase && git merge --no--ff

(a) Because rebase is run on the branch to be rebased, but merge is run on the branch being merged to, that reverses the parents of the merge commit and puts it on the rebased branch rather than the parent. (b) Even if that were fixed, it alters the rebased branch, rather than stopping and warning in an unexpected case.

I really do want the natural semantics of merge --ff-only --no-ff.

Re: Extremely Linear Git History

#298

Post by palata »

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 about commit signatures? If you rebase, you lose the original signature, don't you?

Re: Extremely Linear Git History

#299

Post by palata »

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…

What about the commit signatures? Only merge keeps them, right?

Re: Extremely Linear Git History

#300

Post by TheRealPomax »

jamespwilliams wrote: post #293
TheRealPomax wrote: post #290

Earlier quoted context omitted.

To be fair, if you have 10 commits that all change the same file: squash with respect to your first commit, _then_ rebase. If you have lots of commits, always first squash-rebase to your own first commit, and only rebase to current main once that's done. Rebase is being annoying here mostly because it's doing exactly what you want it to do: warn you about merge conflicts for every commit in the chain that might have…

If you squash you decrease the granularity of your git history, though.

If you have ten different commits all touching the same part(s) of the same file(s), dial down your granularity a little: you've over-committed.

Either that, or you lobbed 10 different issues into the same branch, which is a whole different barrel of "no one benefits from this, you're just making it harder to generate a changelog, can you please not" fish.

Post reply on HN