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

261–270 of 366 posts

Re: Extremely Linear Git History

#261

Post by wirrbel »

thewebcount wrote: post #174
titzer wrote: post #108

Earlier quoted context omitted.

Commit queues are so far superior to shaming broken builds that I think it's only nostalgia that makes you miss it.

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

Re: Extremely Linear Git History

#262

Post by ludwigvan »

mjochim wrote: post #180
entropy_ wrote: post #55

Earlier quoted context omitted.

It's a hash of everything that goes into a commit, including the commit message. The idea is that nothing that makes up a commit can change without changing the hash.

> It's a hash of everything that goes into a commit, including the commit message ... and, very notably, the hash of the parent commit. That is also part of the commit, which means that changing a parent commit would also imply changing the hashes of all later commits. This is sort of the whole point of git/version control.

Poor man’s blockchain it is, then :)

Re: Extremely Linear Git History

#263

Post by rfrey »

voxl wrote: post #192
rfrey wrote: post #152

Earlier quoted context omitted.

It's not toxic because every single developer knows that it could be them next time around.

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?

What I meant is that we know, inside our blood cells, that breaking the build can happen to anyone, and probably will. The trophy is not public shaming, it's the camaraderie that comes from shared humility.

You say to somebody downthread "remind me never to work with you". I would find it difficult to work with someone as hyper sensitive -- on other people's behalf, yet! -- as you seem to be in this thread.

Re: Extremely Linear Git History

#264

Post by frant-hartm »

Beltalowda wrote: post #200
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.

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

Doesn't git's rerere help here?

Re: Extremely Linear Git History

#265

Post by Biganon »

whoooooo123 wrote: post #53
oneeyedpigeon wrote: post #43

Earlier quoted context omitted.

Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)

Only works if your commit message is written in hexadecimal characters

"it" (in "it matches the hash") = "the next sequential number", not "the commit message", afaict. Not very clear, I agree.

Re: Extremely Linear Git History

#266

Post by Biganon »

mjochim wrote: post #180
entropy_ wrote: post #55

Earlier quoted context omitted.

It's a hash of everything that goes into a commit, including the commit message. The idea is that nothing that makes up a commit can change without changing the hash.

> It's a hash of everything that goes into a commit, including the commit message ... and, very notably, the hash of the parent commit. That is also part of the commit, which means that changing a parent commit would also imply changing the hashes of all later commits. This is sort of the whole point of git/version control.

This might be a stupid question, but does anyone call git history a blockchain, then? A centralized blockchain, without proof of work or proof of anything really of course, but still, it sounds like the basic blockchain idea is there

Re: Extremely Linear Git History

#267

Post by MaxBarraclough »

adgjlsfhk1 wrote: post #93
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…

you can often solve this by squashing before rebasing.

That has its own problems. Separating whitespace-only reformatting commits from substantive commits makes it much easier to inspect the real changes, for instance.

Also, more fine-grain commits can help you trace down a bug, perhaps with the help of git bisect. Once you've tracked down the commit that introduced the bug, things will be easier if that commit is small.

Fortunately you can just merge from master, bringing your code back in sync with master without touching master itself. I see Beltalowda has mentioned this.

Re: Extremely Linear Git History

#268

Post by cerved »

wnoise wrote: post #227
u801e wrote: post #115

Earlier quoted context omitted.

What I would like to see is a way to enforce fast-forward only merges along with the forced creation of a merge commit that references the same git tree as the HEAD commit of the branch that was just merged. This way, you know which set of commits was in the branch by looking at the parent commits of the merge commit, but the merge commit itself did not involve any automated conflict resolution.

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

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

Re: Extremely Linear Git History

#269

Post by cerved »

breatheoften wrote: post #127
u801e wrote: post #115

Earlier quoted context omitted.

What I would like to see is a way to enforce fast-forward only merges along with the forced creation of a merge commit that references the same git tree as the HEAD commit of the branch that was just merged. This way, you know which set of commits was in the branch by looking at the parent commits of the merge commit, but the merge commit itself did not involve any automated conflict resolution.

I've wanted this for awhile as well. Squash only merges, which are enforceable in github, get you close but leave you without any automated way to determine if a given branch was ever merged to main or not ...

merge is the only way to reliable determine if a branch is merged ¯ \ _ ( ツ ) _ / ¯

Re: Extremely Linear Git History

#270

Post by cerved »

danwee wrote: post #71
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 usually do `git merge --no-ff development` when working on my feature branch. We do not leave feature branches "open/live" for too much time, so merge conflicts are not usually a problem, but sometimes they do happen. I like cherry-pick, but I barely use it (e.g., I need to cherry-pick one commit from branch X into my branch). I don't like rebase much because it requires force-push.

rebase only require force push if you're rebasing something already pushed
Post reply on HN