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

251–260 of 366 posts

Re: Extremely Linear Git History

#251

Post by couchand »

xxpor wrote: post #246
couchand wrote: post #221

Earlier quoted context omitted.

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

if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.

Totally on board (except the forbidden -a switch).

The last command is:

    cp .git/refs/heads/feature .git/refs/heads/main
No merge needed.

Re: Extremely Linear Git History

#252

Post by cerved »

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.

you get the same, and often more, conflicts using rebase

Re: Extremely Linear Git History

#253

Post by pnt12 »

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

Re: Extremely Linear Git History

#254

Post by xxpor »

couchand wrote: post #251
xxpor wrote: post #246

Earlier quoted context omitted.

if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.

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

Re: Extremely Linear Git History

#255

Post by wirrbel »

com2kid wrote: post #217
sshine wrote: post #92

Earlier quoted context omitted.

> If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We did have an ugly plush animal, but it served more obscure purposes. For blame of broken builds, we had an info screen that counted the number of times a build had passed, and displayed below the name of the person who last broke i…

Thankfully modern development practices should ideally run tests before commiting, the build should never be broken. With good infra, everything from unit tests to integration to acceptable tests get ran before code hits main. The only excuse for builds breaking nowdays. is insufficient automated safeguards.

Our whole practice revolved around not pushing broken code because all code was tested locally prior to the push. In fact we practiced continuous integration as in its original meaning, integrating code multiple times per day. Releases were performed from a release branch so the occasional hiccup wasn’t worse than let’s say a PR that does not build. However fixing the broken build was the TOP priority if it happens (like every two months)

Re: Extremely Linear Git History

#256

Post by bornfreddy »

cfuendev wrote: post #123
sshine wrote: post #92

Earlier quoted context omitted.

> If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We did have an ugly plush animal, but it served more obscure purposes. For blame of broken builds, we had an info screen that counted the number of times a build had passed, and displayed below the name of the person who last broke i…

No joke, a few weeks ago a colleague from university shared a few anecdotes about his mentor-coworker-boss at work with me, and it's similar. Every time they broke the production branch and the boss had to change the code or pull out some AWS magic to restore a database, he would give the fixed commits names like "C gada de [Employee Name]" which roughly translates to "[Employee Name] F* ed Up", since he knew they wo…

Yes, it's all about context. Good intentions matter a lot here.

Additionally, it keeps developers humble, because their mistakes are in the codebase "forever".

That said, it is s fine line - things can easily get toxic very quickly, so it's important that everyone sees it as a (half serious) joke.

Re: Extremely Linear Git History

#257

Post by wirrbel »

couchand wrote: post #167
wirrbel wrote: post #77

I think the sweet spot in Developer productivity was when we had SVN repos and used git-svn on the client. Commits were all rebased on git level prior to pushing. If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We performed code review with a projector in our office jointly looking…

I have my old team's rubber chicken and I'm never giving it up. In-person code review is the only way to do it. Pull requests optimize for the wrong part of code review, so now everyone thinks it's supposed to be a quality gate.

Yep. It makes a lot of sense for open source where gate keeping makes sense (to reduce feature bloat, back doors and an inflated API surface that needs to be maintained almost indefinitely).

Most corporate code bases are written by a smallish team operating under tight time constraints so most contributions are actually improving on the current state of the code base. Then PRs delay the integration, and lead to all kinds of follow up activities in keeping PR associated problems at bay. For example the hours wasted by my team in using stacked PRs to separate Boy Scout rule changes to the code from the feature is just abnormal.

Re: Extremely Linear Git History

#258

Post by pnt12 »

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…

I don't understand the hate for merges, or the love for rrbaded. Let's consider what may happen using a github flow strategy (main branch, feature branches based solely on main):

* If you screw up a merge, you undo the merge commit. Now your branch is exactly as it were. May not happen with a rebase.

* If you push some code to the remote, and later find out it was outdated, you can merge it with main and push again: no need to force, github can distinguish what's already been reviewed and what hasn't. With rebase, you may need to push -- force, and if someone already reviewed the code they're going to be shit out of luck, as github will lose the capability to review "changes since last review", as the reference it has may have been lost.

I also merge these features using squash commits, which provides a very linear history. This also saves some effort (you don't need to be rebase the commits in the feature branch, which can be a pain in the ass for unorganized people and git newbies, and you are pushed towards making smaller, granular PRs that make sense for the repo history).

Re: Extremely Linear Git History

#259

Post by micw »

xxpor wrote: post #246
couchand wrote: post #221

Earlier quoted context omitted.

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

if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.

Rather than switching to "main" and pull it, you can just stay in "feature" and do a fetch followed by "rebase origin/main". Then pull "main" before you merge the feature.

I'd also use "merge --no-ff" to force an empty commit that visualizes where a feature begins and ends.

Re: Extremely Linear Git History

#260

Post by wirrbel »

newswasboring wrote: post #183
wirrbel wrote: post #77

I think the sweet spot in Developer productivity was when we had SVN repos and used git-svn on the client. Commits were all rebased on git level prior to pushing. If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We performed code review with a projector in our office jointly looking…

I am literally in the middle of trying to convince my group from moving away from all this. Would you recommend going back to this system?

In this case I reminisced about the toolset but the work flow is what brought the value so I advise of course against using subversion.

Look up trunk based development and read the continuous integration book published by Addison Wesley (Is it the hez humble book or the Duvall book I always confuse the authors, both books are great though).

The hard part will be to convince people of exploring a different way working mode AND to learn that what is proposed is not an anarchist style of development but a development model that optimizes on efficiency

Post reply on HN