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

151–160 of 366 posts

Re: Extremely Linear Git History

#151

Post by exabrial »

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…

we did something similar, but everyone knew it was a joke and we all took turns with it. I guess we didn't take ourselves as seriously

Re: Extremely Linear Git History

#152

Post by rfrey »

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…

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

Re: Extremely Linear Git History

#153

Post by blux »

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 and potentially screwing up the integrity of the unit test results in the rebased branch? Both sound unappealing to me.

The problem is not a history with a lot of branches in it, it is in not knowing how to use your tools to present a view on that history you are interested in and is easy for you to understand.

Re: Extremely Linear Git History

#154

Post by gpvos »

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…

> If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it.

I don't get it. If you rebase, you get 20 chances to do the same.

Re: Extremely Linear Git History

#155

Post by jasmer »

jonstewart wrote: post #150
jasmer wrote: post #134

Wouldn't it have been better if we could use something other than SHA1 as the actual name of something? Where in the worst dystopian parts of software do we do this? The SHA1 is kind of a security feature if anything, a side-show thing that should be nestled 1-layer deep into the UI and probably most people are unaware of. Whereas commits and branches should be designed specifically for the user - not 'externalized a…

I don’t want to make up a good name for every commit. Good comments are hard enough. A SHA-1 might not look friendly to a dev who doesn’t understand it, but as someone who works with hash values all the time, having my repo be a Merkle tree gives me a warm fuzzy.

You wouldn't 'make one up' there would be an automatic variation of Semantic Versioning, or something actually useful.

Your 'warm and fuzzy' comes at the cost of confusion (even to yourself), not having any clue what the information really means.

It's not even clear that it's a commit, it could be anything.

This posture is exactly what I'm complaining about: it's objectively bad design engineering, embraced as though somehow it's 'smart'.

Git has a few problems like this.

Re: Extremely Linear Git History

#156

Post by silvestrov »

jordigh wrote: post #142

Mercurial always has had sequential revision numbers in addition to hashes for every commit. They aren't perfect, of course. All they indicate is in which order the current clone of the repo saw the commits. So two clones could pull the commits in different order and each clone could have different revision numbers for the same commits. But they're still so fantastically useful. Even with their imperfections, you kno…

Seems like a design fault in git that commits only have a single id (sha1 hash) and that hashes are written without any prefix indicating which type of id it is.

If all hashes were prefixed with "h", it would have been so simple to add another (secure) hash and a serial number.

E.g. h123456 for the sha1, k6543 for sha256 and n100 for the commit number.

Re: Extremely Linear Git History

#158

Post by informalo »

zegl wrote: post #140

I don't know how stupid this is on a scale from 1 to 10. I've created a wrapper [1] for git (called "shit", for "short git") that converts non-padded revisions to their padded counterpart. Examples: "shit show 14" gets converted to "git show 00000140" "shit log 10..14" translates to "git log 00000100..00000140" [1]: https://github.com/zegl/extremely-linear/blob/main/shit

Other customers also brew-installed: fuck [1]

[1]: https://github.com/nvbn/thefuck

Re: Extremely Linear Git History

#159

Post by michaelmior »

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…

This somewhat depends on how big your features are. Arguably, large long-lived feature branches are the problem themselves. If larger features are broken down and developed/merged piecemeal, then you still have smaller commits you can fall back on.

IIRC, GitHub uses a development model where partially implemented features are actually deployed to production, but hidden behind feature flags.

Post reply on HN