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

321–330 of 366 posts

Re: Extremely Linear Git History

#321

Post by bpugh »

pnt12 wrote: post #253
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…

I wholeheartedly agree! With this, you can also push people towards smaller PRs which are easier to review and integrate. The downside is that if you és o work on feature 2 based on feature 1,either you wait for the PR to be merged in main (easiest approach) or you fork from your feature branch directly and will need to rebase later (this can get messier, especially if you need to fix errors in feature 1).

Git recently added a --update-refs option to rebase that makes dealing with this scenario a lot easier. This post does a good job explaining how to use it: https://andrewlock.net/working-with-stacked-branches-in-git-...

Re: Extremely Linear Git History

#322

Post by couchand »

Beltalowda wrote: post #320
couchand wrote: post #311

Earlier quoted context omitted.

Always surprising when folks are confused about how to collaborate on git branches... I'd expect the recursive solution to be more obvious! > The "proper" solution is the one that allows me to get stuff done. Yeah, but the stuff that needs to get done doesn't end with your commit, it starts there. Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't.

> Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't. How so? If I make an error with a rebase then I risk losing my changes. You can fetch it from the local reflog, but that's not so easy. With a merge I have a merge commit which records what was merged.

We're talking past each other. You're describing issues that come up during the git workflow. I'm talking about production bugs.

Re: Extremely Linear Git History

#323

Post by GauntletWizard »

palata wrote: post #298
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?

If you let Github do the rebase, yes, you do. But you can do so manually yourself, taking the commit down to a single squashed commit, that you then sign.

This is a tooling issue that needs to be solved client-side (i.e. where the signing key lives). It's an important one but actually really simple.

Re: Extremely Linear Git History

#324

Post by benatkin »

couchand wrote: post #221
benatkin wrote: post #211

Earlier quoted context omitted.

Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.

Then you don't actually need merge? Am I missing something? If you always rebase the branch, the commits can be applied directly.

You're missing the merge commits. `git log` is a key feature and merges belong there, at least in my workflow.

Re: Extremely Linear Git History

#325

Post by andreareina »

scubbo wrote: post #319
HWR_14 wrote: post #303

Earlier quoted context omitted.

> what was the codebase like at this point in time // immediately prior to some point?", you shouldn't need to ask clarifying questions I would assume that such a question would talk only about the main branch. However, I will point out that "what was the state of feature X" is only answerable with a non-linear story. > The practical reason is that it discourages a bad-practice - long-lived branches. Wait, long-lived…

> long-lived branches are _bad_? Merging in partially-done features is _good_? ...uhhh, yes? I've never heard anything to the contrary. Can you explain why you think the opposite? For long-lived branches: The longer a branch exists separately and diverges from main, the more pain you'll create when you try to merge it back in - both because of changes that someone else has made in the meantime (and so, conflicts you'…

Maintaining orphaned code has a cost. Keeping a change you've made to a function (and its callers) that's no longer needed obscures both the history and probably what it does.

Not saying trunk-based is wrong, but to say abandoning a feature is as cheap as in branch-based development fails to account for everything.

Re: Extremely Linear Git History

#326

Post by z3t4 »

kzrdude wrote: post #116
BiteCode_dev wrote: post #113

Earlier quoted context omitted.

This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.

Merge and conflict resolution is a minefield if unexperienced developers do it too. Fortunately it can (often) be arranged that those with some understanding of the issues involved can do the resolution.

Always clone to another folder before merging ;)

Re: Extremely Linear Git History

#327

Post by HWR_14 »

scubbo wrote: post #319
HWR_14 wrote: post #303

Earlier quoted context omitted.

> what was the codebase like at this point in time // immediately prior to some point?", you shouldn't need to ask clarifying questions I would assume that such a question would talk only about the main branch. However, I will point out that "what was the state of feature X" is only answerable with a non-linear story. > The practical reason is that it discourages a bad-practice - long-lived branches. Wait, long-lived…

> long-lived branches are _bad_? Merging in partially-done features is _good_? ...uhhh, yes? I've never heard anything to the contrary. Can you explain why you think the opposite? For long-lived branches: The longer a branch exists separately and diverges from main, the more pain you'll create when you try to merge it back in - both because of changes that someone else has made in the meantime (and so, conflicts you'…

I'm not advocating branches should be made longer for no reason, but I see no reason to avoid them. I do think they should be made long if they need to be to encapsulate a feature. I don't think that the pain of resolving conflicts scales super-linearly and that idea doesn't make sense to me. In fact, I think the opposite is true. I admit, that could be a taste issue.

I mistyped at one point by saying to avoid a partial-feature commit when I meant partial-feature merge onto the main branch. Yes, commit to the feature branch often. Hopefully clarifying that resolves most of the issues that you raised as advantages.

Meanwhile, managing partially built features by feature flags seems worse. It has orphaned code migrate into the main codebase and stay there. You brought up a broken dependency. What happens if a dependency is broken and not likely to get fixed for a month? Just leave that code in the main codebase orphaned for a month? Further, having multiple partial feature commits complicates bisecting or simple reading a feature's history.

I concede feature flags for deployment has some advantages, especially for feature specific elevation through testing.

Re: Extremely Linear Git History

#328

Post by cerved »

charcircuit wrote: post #283
cerved wrote: post #274

Earlier quoted context omitted.

All hail centralized version control, make life slow again!

Decentralized version control is slower than centralized version control since it requires downloading and working with the entire repository.

True, but at least you don't have to download on every checkout

Re: Extremely Linear Git History

#329

Post by cerved »

wnoise wrote: post #297
cerved wrote: post #268

Earlier quoted context omitted.

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.

you can do this

git rebase -r target source && git checkout target && git merge --no-ff target

since what your asking for is not a merge, you'd have glue it together by yourself. Perhaps, add it as a script

Re: Extremely Linear Git History

#330

Post by gyulai »

detaro wrote: post #234
gyulai wrote: post #94

Earlier quoted context omitted.

...so you are among the 1% who use the functionality that causes 99% of what makes git's mental model so convoluted and hard to learn (for everyone , not just the one-percenters).

That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them... Or maybe it's not as binary, and Gits model with its complexity has more useful properties making the trade off worth it.

> That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them...

Computing history is full of examples where technologies that are objectively not the best technologies end up being dominant. It's more about economics. (Network externalities, switching costs, ...)

Although I will admit that, with version control, there isn't even an alternative out there that is anything like an "objective winner". Each one has its problems, and it's a matter of choosing the least of the evils. -- I haven't tried any of the commercial ones though.

Post reply on HN