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

211–220 of 366 posts

Re: Extremely Linear Git History

#211

Post by benatkin »

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…

Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.

Re: Extremely Linear Git History

#212

Post by thunky »

tcoff91 wrote: post #205
thunky wrote: post #198

Earlier quoted context omitted.

> A long lived feature branch is not a problem if you rebase it to master often. Yes but if it's a shared branch then you may have problems with this. The safer way is to merge from master into the branch but nobody wants to do that because it's ugly.

For long-lived feature branches that are the target of multiple smaller PRs, history should never be rewritten. I call these branches integration branches. I agree with you wholeheartedly that master should be merged into the branch. It's also so much easier to resolve merge conflicts all at once in the merge commit rather than iteratively for each commit. Also, the information on how merge conflicts are resolved is…

I agree with you here.

But what you are describing still isn't good enough for a lot of people, because even though `--first-parent` hides the noise it's still there and just knowing there's a mess under the rug is enough to be problematic.

I don't think it's really the fault of the tooling, moreso with what is a common interpretation of what is a mess and what isn't. If the github commit history allowed you to show `--first-parent` maybe it would be less of a problem.

Re: Extremely Linear Git History

#213

Post by avar »

chrismorgan wrote: post #138
avar wrote: post #103

Earlier quoted context omitted.

Git hasn't used "seven-character prefixes when there are no collisions" in a long time. It's a combination of the "repo size" (as in, estimated number of objects) and a hard floor of seven characters. You can see this by running "git log --oneline=7" on any non-trivially sized repository (e.g. linux.git). There's plenty of hashes that uniquely abbreviate to 7 characters, but they're currently all shown with 12 by def…

There may be some extra trigger that causes it to go beyond seven for everything, I don’t know (never worked on a repository anywhere near that large), but there’s certainly still at least some form of collision logic in there (and this is why I said what I said, because I’ve used lucky_commit enough to experience it): $ git init x Initialized empty Git repository in /tmp/x/.git/ $ cd x $ git commit --allow-empty -m…

Yes, there's also a collision check, but it's not truncating to 7 characters and adding as needed to get past collisions. Rather it's truncating to N and then adding as needed. N=7 for a new repository, but it'll relatively quickly bump that to 8, then 9 etc

You don't need a very large repository to start bumping it up to 8 etc. E.g. my local redis.git is 9, some local few-thousand commit (partially automated) that I've only ever added to are at 8 etc.

This changed in v2.11 released in late 2016[1], but because the observable default on a new repository is 7 the "it's 7 unless collisions" has persisted in various places online.

All of which is to say that if you brute-force the first commit to be 0000001..., it'll start being displayed as , where is a random 0..9a..f character, unless you brute force to 8, 9 etc.

1. https://github.com/git/git/commit/e6c587c733b4634030b353f402...

Re: Extremely Linear Git History

#214

Post by housel »

ccbccccbbcccbb wrote: post #210

But what's the carbon footprint and contributed sea level rise of this frivolity?

This is a serious criticism... even if it's not likely to catch on enough to have a real effect on the sea level, it is a complete waste of energy to accomplish something that could be done much more efficiently some other way, if it is indeed worth doing at all.

Re: Extremely Linear Git History

#215

Post by xeyownt »

HWR_14 wrote: post #202
mamcx wrote: post #130

Earlier quoted context omitted.

I was converted to rebase by my current team, and this hit every time. I wish it works like merge, or exist a way to merge, resolve conflict, rebase?

Can I asked how they converted you (or do you mean by dictate, as opposed to becoming convinced it was better)? I find myself loving merges and never using rebases. It's not that I cannot describe technically what's happening, but I just don't understand the love.

In my case, I switched rapidly to git-rebase because it produces history that is much cleaner and easier to understand. I only do merge if there is a good reason to preserve history (e.g. some other branches depend on it, or some test reports refer to a given commit).

Re: Extremely Linear Git History

#216

Post by mamcx »

HWR_14 wrote: post #202
mamcx wrote: post #130

Earlier quoted context omitted.

I was converted to rebase by my current team, and this hit every time. I wish it works like merge, or exist a way to merge, resolve conflict, rebase?

Can I asked how they converted you (or do you mean by dictate, as opposed to becoming convinced it was better)? I find myself loving merges and never using rebases. It's not that I cannot describe technically what's happening, but I just don't understand the love.

Mostly is about the way they do things, and I always adopt the team ways (also: my initial PRs look weird to them!).

Re: Extremely Linear Git History

#217

Post by com2kid »

sshine wrote: post #92
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…

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

Re: Extremely Linear Git History

#218

Post by spyremeown »

nsajko wrote: post #169

Gitlab supports an option called "Fast-forward merge": > No merge commits are created. > Fast-forward merges only. > When there is a merge conflict, the user is given the option to rebase. The maintainer can enable this for a project.

So does almost every PR-based workflow tool for (bitbucket, GitHub etc). It's very common.

Re: Extremely Linear Git History

#219

Post by tcoff91 »

thunky wrote: post #212
tcoff91 wrote: post #205

Earlier quoted context omitted.

For long-lived feature branches that are the target of multiple smaller PRs, history should never be rewritten. I call these branches integration branches. I agree with you wholeheartedly that master should be merged into the branch. It's also so much easier to resolve merge conflicts all at once in the merge commit rather than iteratively for each commit. Also, the information on how merge conflicts are resolved is…

I agree with you here. But what you are describing still isn't good enough for a lot of people, because even though `--first-parent` hides the noise it's still there and just knowing there's a mess under the rug is enough to be problematic. I don't think it's really the fault of the tooling, moreso with what is a common interpretation of what is a mess and what isn't. If the github commit history allowed you to show…

The github history view is garbage and people should stop using it.

Re: Extremely Linear Git History

#220

Post by actuallyalys »

ChrisMarshallNY wrote: post #25

I find tags to be a fairly useful way of providing a linear progression, but I guess that's no fun. > but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project. That sounds like the Mainline Model, championed by Perforce[0]. It's actually fairly sensible. [0] https://www.perforce.com/video-tutorials/vcs/mainline-model-...

Yeah, I think tags are a more practical way of accomplishing this. If you’re really interested in having a linear history, it might also make sense to switch to an alternative. Mercurial has linear version numbers and can even push to Git repositories.

At risk of coming across as a humorless Hacker News commenter, I will add that I enjoyed this post. It’s a neat hack!

Post reply on HN