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

231–240 of 366 posts

Re: Extremely Linear Git History

#231

Post by olddustytrail »

michaelt wrote: post #128
broeng wrote: post #91

Earlier quoted context omitted.

In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.

Sounds like you've never worked on a project with a file everyone wants to append to :) If every error in your system needs a separate entry in the error enum, or every change needs an entry in the changelog - loads of changes will try to modify the last line of the file.

Depending on the format of your files, entries like "changelog merge=union" in your .gitattributes file might work for you.

Re: Extremely Linear Git History

#232

Post by tasuki »

blux wrote: post #153

I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history. How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase a…

> I fail to see the point of this

I'm pretty sure the point is that this is a one-person project and the author can play around. He's not suggesting your team of 100 people to adopt this for the development of your commercial product.

Re: Extremely Linear Git History

#233

Post by tasuki »

gyulai wrote: post #67
MAGZine wrote: post #45

Earlier quoted context omitted.

... What are the other reasons?

Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo r…

> I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future.

Sure. The problem is not "distributed version control", some problems are:

- I'm on a train with no internet, finished working on a thing and want to start working on another thing and don't want to mix them up.

- I want to make a branch and don't want to wait for eons while everything gets copied on the server.

- Oops there's a problem with the server now no one can perform any work.

Yes, SVN might simple commands, but its internals are messed up. Git's UI sucks, but just learn about blobs, trees, commits, branches (pointers to commits), and you basically understand how Git works.

Re: Extremely Linear Git History

#234

Post by detaro »

gyulai wrote: post #94
breck wrote: post #85

Earlier quoted context omitted.

Oh we use distributed day in and day out for everything. Once you start battling censorship you’ll get it.

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

Re: Extremely Linear Git History

#236

Post by voxl »

daveguy wrote: post #196
voxl wrote: post #192

Earlier quoted context omitted.

It is literally the definition of toxic. It is the antithesis of making it okay to fail, having the entire team to take responsibility. Instead individual mistakes are highlighted and publicly shamed. How can you possibly not think this is toxic?

Sounds like the definition of making it okay to fail. The only consequence is a plush toy of shame on your desk until the next person fails? Yes, please. Sounds like a great way to lighten the mood about failure.

Uh no, and please never work with me. The definition of "making it okay to fail" is a pat on the back and a retrospective to figure out what went wrong and prevent it from happening again.

Re: Extremely Linear Git History

#237

Post by tjoff »

tasuki wrote: post #233
gyulai wrote: post #67

Earlier quoted context omitted.

Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo r…

> I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. Sure. The problem is not "distributed version control", some problems are: - I'm on a train with no internet, finished working on a thing and want to start working on another thing and don't want to mix them up. - I want to make a branch and don't want to wait for eons while everything gets…

All those things could be done on a centralized version control system as well. Just not on SVN.

Re: Extremely Linear Git History

#238

Post by acchow »

simiones wrote: post #83
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…

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…

Hmmm I think in your scenario you could avoid resolving the conflict 10 times by using `git rebase --onto`

Suppose "masterX+1" is called latest

Suppose "masterX" is the SHA of your mergebase with master (on top of which you have 10 commits)

`git rebase --onto latest masterX`

Re: Extremely Linear Git History

#239

Post by bthater »

HWR_14 wrote: post #197
voxl wrote: post #192

Earlier quoted context omitted.

It is literally the definition of toxic. It is the antithesis of making it okay to fail, having the entire team to take responsibility. Instead individual mistakes are highlighted and publicly shamed. How can you possibly not think this is toxic?

Toxic is not the highlighting of breaking the build with a trophy, it's what gets associated with it. Imagine an "ugliest shirt" trophy, given out to whoever wheres the ugliest shirt of the week. At a fashion magazine, this may be toxic shaming. At a tech-heavy startup it might have people start buying the worst shirts they can to try to win it. If the attitude associated with getting the trophy is condemnation, that…

Oof that hits a sore spot. I was the 2016 Winner of the Ugliest Shirts Award at one of the first technology companies I worked at. Being singled out in front of all your peers for poor fashion sense and then the ensuing obligatory laugh ruined my opinion of that company's leadership. I would strongly encourage anyone in a professional environment (especially those in leadership roles) to keep comments on appearance to yourself.

Re: Extremely Linear Git History

#240

Post by cerved »

GuB-42 wrote: post #86
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 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
Post reply on HN