Git is too hard • Hacker News Board

Re: Git is too hard

#701

Post by simiones » Tue, Nov 17, 2020, 9:26 PM UTC

harrisonjackson wrote: post #653

simiones wrote: post #554

Earlier quoted context omitted.

Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? Also, cherry is often needed daily in short bursts around releases. Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investi…

The most important reason imo is making code reviews easier. Enormous PRs = less confidence in merging code on a team. If you are pushing small commits then it is easier for the team to follow the changes and review them. - easier to merge and ship small incremental changes than large ones - easier to revert small commits - better commit messages since you can summarize the smaller change instead of "coded a lot of t…

All of those only make sense to me if a commit is a finished work item. If I'm committing just because I want to switch branches or pull, most likely what I'm committing is not meaningful in any way. If I squash later, it doesn't really matter, the reviewer will see one commit anyway, so committing often or not didn't help.

And sure, it's easier to ship small features than large ones. But it's harder to follow one complex change as a series of short patches than one big, self-consistent change.

So to me, commits should be as often as possible, sure, but that is normally once a day or once every few days for serious features / large bug fixes. I usually want to pull or switch branch much more often than that.

And related to release time: typically we have a single main branch that serves multiple projects. When one of these projects is close to a release, they cut off a release branch that is feature frozen, in order to fix any remaining bugs and thoroughly sanitize it. In the meantime, other teams continue merging features into master as they are ready. Bugfixes normally also go into master first, and they are then cherry-picked into the release branch (or branches, if there are multiple releases overlapping). So for us, during this release window, cherry-picking is something that every team member does constantly.

Re: Git is too hard

#702

Post by macspoofing » Tue, Nov 17, 2020, 9:27 PM UTC

People overthink it. Git has ten million ways of doing anything - pick a subset that works, and stay within it.

Re: Git is too hard

#703

Post by h0l0cube » Tue, Nov 17, 2020, 9:27 PM UTC

sethammons wrote: post #224

h0l0cube wrote: post #182

Earlier quoted context omitted.

I've found it indispensable when tracking and integrating other peoples' branches. I wouldn't use it so much if I was working solo.

I've never worked solo. My teams tend to be around 6-8. Across a dozen teams, myself and nobody on the team save a couple even looked at the graph. One who loved a clean history showed it off, people thought it was pretty, and went back to work as normal. `git commit -am 'slightly helpful message' && git push origin $branch` does about 90%+ of what I've needed. When we merge the branch, squash merge works fine. Histo…

Each to their own. I use it in situations where i want to know what other people are basing their branch from. Which, for projects I've worked on, can have real consequences. For instance, it may prompt me to rebase upon their work sooner, or even give them a heads up that theirs some useful change I'm submitting to the trunk.

Re: Git is too hard

#704

Post by simiones » Tue, Nov 17, 2020, 9:29 PM UTC

dahart wrote: post #669

simiones wrote: post #537

Earlier quoted context omitted.

It's interesting that you mention branching, because that is another workflow where I feel that I constantly have to reach for stashing - when I simply want to move to another branch (either for a quick bugfix or simply to check something). Otherwise yes, I know you can relatively easily lose work with git stash (I actually once lost about 2-4 days of work with a P4 shelve, which is an extremely similar feature), but…

It might be worth really picking apart why you think you need to stash instead of commit, and why stash feels easier. I honestly don’t think committing is any more work than stashing at all, not even more typing. It’s really not more difficult to commit what you have temporarily, go to another branch to work, then come back and continue working, compared to stash. But I don’t doubt that it feels more difficult for so…

I think it's primarily a question of focus: I want to pull or to switch a branch. The fact that I have to do something like committing or stashing is already an annoyance - having to come up with a commit message is even worse.

Perhaps I will give this commit/reset workflow a try as well, to see how it feels. It may also be that committing still feels to much like "an event" for me, from my P4 days.

Re: Git is too hard

#705

Post by mekster » Tue, Nov 17, 2020, 9:31 PM UTC

I can say git is dragging our feet all along. I don't remember subversion being acting this unintuitively.

I always hear problems that someone couldn't clone a repo as the repo got big and it's only 2GB in size and random blogs tell you to run git config command to fix which isn't even available on Windows if the user is only using a GUI tool and the other solution is to edit a .gitconfig file which Windows have problem handing files with dot at the beginning, commits creates a conflicting branch because I pushed before I pulled files I didn't even touch, and push randomly fails on people but it works on a retry etc etc.

People just figured Linus' work is a magic bullet to everyone's problem but I guess people jumped on it with no evaluation and we're all bleeding from this.

We need a better tool than git.

I miss tools like bazaar when they mention their goal was being user friendly which is important.

Re: Git is too hard

#706

Post by mekster » Tue, Nov 17, 2020, 9:36 PM UTC

It's about time we should get off of git to something new by creating a bridge like "git svn" for easier migration that's targeted at more general audiences than hackers of the hackers only.

There's no way kernel devs would want to change the course of git to target different audiences. It was meant to be as their tool which is a niche and we should've known better.

Re: Git is too hard

#707

Post by rmtech » Tue, Nov 17, 2020, 9:45 PM UTC

wegs wrote: post #698

rmtech wrote: post #609

Earlier quoted context omitted.

> A tool you use every day definitely falls into the category of Stuff You Ought to Know, in a way that understanding how quantum tunneling is used in an SSD is in the category of Stuff You Don't Need to Know. I use an SSD every day though, as well as an LCD display and a laser in my mouse. So by this reasoning, I need to study quantum mechanics; it would only take a few weekends of focused study to understand the Sc…

With that attitude, I would never, ever, ever, hire you. As a footnote, I would expect you to be able to understand things like SSD performance and reliability, and how it's affected by complex algorithms in the drive controller (e.g. wear leveling, garbage collection, write block size, etc.). I would also expect you to be able to understand things like how subpixel rendering works, how rendering engines coordinate w…

> With that attitude, I would never, ever, ever, hire you.

There are two separate issue here though.

(A) How much work does a given person want to put in

(B) How much work does a given tool require.

It can simultaneously be the case that git is bad/overcomplicated AND that you should only hire people who bother to learn it really well.

Why?

Well, learning hard things is a reliable signal of diligence and hard work, which are generally useful traits.

But at the same time, forcing everyone to learn something annoying and time-consuming just as a test of grit isn't maximally efficient. The same effort could be put into more productive tasks.

> Why did you go into software engineering?

Well, I'm not a software engineer - in the Data/ML area so I am much more interested in the properties of data than the properties of code. But having said that I certainly like clean, efficient code and I care about languages (maybe just spoiled by python?!).

I can't see myself as a software engineer so I think your instinct is right. My passion is data and ML.

Re: Git is too hard

#708

Post by mytailorisrich » Tue, Nov 17, 2020, 9:54 PM UTC

Git is a distributed version control system and does not add complexity beyond what is required for the task at hand.

This is a highly technical tool not for the average person, but it is neither designed for nor used by the average person.

Re: Git is too hard

#709

Post by rmtech » Tue, Nov 17, 2020, 10:09 PM UTC

wegs wrote: post #617

rmtech wrote: post #416

Earlier quoted context omitted.

But for each one of these, the less I have to know about its internals, the better. The ideal option for each of these things is that it "just works". When you have to think about the internals of your package manager or your CI or your virtual environment, that's a flaw in it, not a reason to celebrate.

You want simple internals, and one would expect programmers to understand those internals. You want the userspace to do obvious things with those internals. You don't want magic in between. Understanding internals is a feature, not a bug. I picked Debian over Red Hat since, at the time, I could understand how .deb packages worked, and look over the state of the system. Red Hat had more opaque internals. If something…

I take the view that developers shouldn't be spending their time fixing their VCS.

I use PyCharm. I don't know how PyCharm works internally. I don't even know what language it is written in. I know that it provides syntax highlighting, smart replace, code completion, etc.

Similarly, my car mechanic has a bunch of tools that he doesn't understand in detail; they have interfaces (like a gauge on a pressure sensor).

Progress requires these interfaces, it requires these abstractions, and over time I'm pretty confident that we'll get a better VCS than git that has better, more user-friendly abstractions and it will take over the market.

Re: Git is too hard

#710

Post by kontxt » Tue, Nov 17, 2020, 10:09 PM UTC

I LOVE how the article used highlights.

And it seems that all the posts on the changelog.com platform use highlights. I wish more people and articles did this. I actually built Kontxt (https://kontxt.io) so everyone can add highlights to websites they visit or own, but it has more interactivity with inline comments, polls, mentions, tags, and smart navigation.

Please everyone, highlight everything! It's so useful!