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

181–190 of 366 posts

Re: Extremely Linear Git History

#181

Post by masklinn »

losvedir wrote: post #129
masklinn wrote: post #58

Earlier quoted context omitted.

I think merge is great, having a “unit” for a feature branch being integrated is nice and not all things can be done in commits which are individually justifiable. The ability to bisect cleanly through the first ancestor is precious. I do agree that resolving conflicts in merges is risky though. It can make sense when merging just one way between permanent branch (e.g. a 1.x branch into a 2.x), but as soon as cross m…

> I do agree that resolving conflicts in merges is risky though. How do you do otherwise, though? Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go?

> Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go?

Yes. You don't usually need "continual" rebasing, most commonly just once just before merging.

In fact a good merge tool can do it for you (and refuse to merge if there are conflicts when rebasing).

Re: Extremely Linear Git History

#183

Post by newswasboring »

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?

Re: Extremely Linear Git History

#184

Post by collinvandyck76 »

broeng wrote: post #91
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…

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's not as contrived as you may think. I, along with what I imagine are many others, do a lot of frequent micro-commits as time goes on and the feature becomes more complete, with a lot of commits in the same area of any given file. Rebasing a development branch in this state is pretty gnarly when a conflict arises.

Sadly, my current approach is to just reset my development branch to the merge base and make one huge commit, and then rebase.

Re: Extremely Linear Git History

#185

Post by masklinn »

jwilk wrote: post #148
masklinn wrote: post #66

Earlier quoted context omitted.

Git also support extra headers in commits. Interesting that neither went with that.

What do you mean by "extra headers"?

Exactly what the name says.

A git commit is composed of a number of headers (key: value fields) and a commit message.

There is a set of "standard headers" (tree, parent*, author, committer, encoding?), but then you can add more. In fact there's a set of semi-standard headers, as in headers git itself will add under some conditions: `gpgsig` and `gpgsig-sha256` if the commit is signed, and I think `mergetag` for signed tags. They are documented as part of the signature format but they're not "baseline" features: https://git-scm.com/docs/signature-format#_commit_signatures

But because of this, a git client should support arbitrary commit headers, and round-trip them even if it does not expose them.

Re: Extremely Linear Git History

#186

Post by thunky »

jonstewart wrote: post #143
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…

I once interviewed a junior-ish developer who told me that his then-current team had a dunce cap to be worn by whomever broke the build. I copied it immediately. There was no toxicity, it was a good laugh, and as manager I wore it more than once being a bit too liberal with my commits. On another team I was on, in 2002 using CVS, we had an upside-down solo cup as a base for a small plastic pirate flag. If you were re…

> I despair about long-lived git feature branches and pull requests

This comes up a lot - multiple people on this thread have even said that it's a bad idea to have a long running feature branch.

This seems like a case of the tool imposing it's will on workflows, rather than enabling them. Not all features are tiny. I don't see anything wrong with a long lived branch if the feature is in fact large. After all it may be completely redesigned multiple times over before being merged into the main branch. Or it may never make it.

And no I don't think it always works to break down a large feature into smaller ones, because your course may change as you go, and it's much easier not to have to revert incremental features when it does.

But people are so worried about having a perfect history. So they rebase. But if it's a long lived (shared) branch you don't want to do that. So now what? A merge would be ugly, can't do that. So now you've painted yourself in a corner for no good reason.

Re: Extremely Linear Git History

#187

Post by breck »

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

Fair point! I would love to use the Extremely Linear Git History of the parent post.

I actually wrote a new layer on top of Git years ago (I called it git4 IIRC) and I pitched it to both GitHub and GitLab but they ignored it.

I guess I should have pitched it to the mailing list. I think I was too afraid it was dumb. Will do that at some point.

Re: Extremely Linear Git History

#189

Post by account42 »

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.

Even multiple appends are not that bad for rebasing - if you put the remote changes before your own then after the first commit the context for your remaining commits will be the same.

If order actually matters then yeah, git can't magically know where each new line should go.

Re: Extremely Linear Git History

#190

Post by geon »

thunky wrote: post #186
jonstewart wrote: post #143

Earlier quoted context omitted.

I once interviewed a junior-ish developer who told me that his then-current team had a dunce cap to be worn by whomever broke the build. I copied it immediately. There was no toxicity, it was a good laugh, and as manager I wore it more than once being a bit too liberal with my commits. On another team I was on, in 2002 using CVS, we had an upside-down solo cup as a base for a small plastic pirate flag. If you were re…

> I despair about long-lived git feature branches and pull requests This comes up a lot - multiple people on this thread have even said that it's a bad idea to have a long running feature branch. This seems like a case of the tool imposing it's will on workflows, rather than enabling them. Not all features are tiny. I don't see anything wrong with a long lived branch if the feature is in fact large. After all it may…

A long lived feature branch is not a problem if you rebase it to master often. Move all refactoring to the beginning of the branch and merge them to master if they become too many.
Post reply on HN