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

81–90 of 366 posts

Re: Extremely Linear Git History

#81

Post by eurasiantiger »

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…

It is also a security risk. Someone could add whatever unreviewed code and it would get glanced over as a merge commit. Put your payload in an innocuous file not likely to be touched and call a boilerplate-looking function as a side effect from somewhere.

Re: Extremely Linear Git History

#83

Post by simiones »

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 branch, you will only have to resolve the conflict once.

Even though I much prefer a linear history, losing 1h or more to the tedious work of re-resolving the same conflict over and over is not worth it, in my opinion.

Re: Extremely Linear Git History

#85

Post by breck »

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…

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

Re: Extremely Linear Git History

#86

Post by GuB-42 »

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 continously, you completely lose track of what changes were done on the branch and which where done on the mainline.

If you do things correctly, that is by making sure that when you merge changes from a feature branch into the mainline, the mainline is always the first parent, you shouldn't have any problem. Git is designed this way, so normally, you have to go out of your way to mess things up. If did it like that and you don't want to see the other branch commits, git-log has the --first-parent option.

Re: Extremely Linear Git History

#87

Post by robertlagrant »

jrmg wrote: post #76
chrismorgan wrote: post #52

It has been my habit for a while to make the root commit 0000000 because it’s fun, but for some reason it had not occurred to me to generalise this to subsequent commits. Tempting, very tempting. I have a couple of solo-developed-and-publicly-shared projects in mind that I will probably do this for.

How do you make the first commit 0000000? (Without using this project, obviously).

Might be by using that hashcrash tool.

Re: Extremely Linear Git History

#88

Post by breck »

Zoadian wrote: post #31
globular-toast wrote: post #21

Earlier quoted context omitted.

It just means you have to coordinate more. Or just have one person in charge of the master branch. I don't think the post is supposed to be taken so seriously, though.

which just means: lets waste many hours coordinating, for the benefit of having a 'nice looking' history.

Commit once read forever

Re: Extremely Linear Git History

#89

Post by tomtom1337 »

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…

This (plush toy and projector) has “feel good” all over it :)

Re: Extremely Linear Git History

#90

Post by fgeiger »

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…

> it'll end up being used as a worldwide centralized monorepo run by Microsoft, and no one will ever use any of that distributed stuff.

And I thought I use git in a decentralized fashion all the time … at least I don't need to connect to any other machine when committing, switching branches, merging, rebasing, etc. And my colleagues can do the same without any network connection at the same time.

Also, while it has the biggest brand recognition, not everyone is using GitHub for all their repositories, are they?

Post reply on HN