Git is too hard • Hacker News Board

Re: Git is too hard

#711

Post by sethammons » Tue, Nov 17, 2020, 10:13 PM UTC

h0l0cube wrote: post #703

sethammons wrote: post #224

Earlier quoted context omitted.

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.

ah, that is likely part of it. We always branch from master and merge back to master. Builds prevent failing code from merging. It is rare that we branch from a branch, and that 2nd branch would never be merged before the first.

Re: Git is too hard

#712

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

rmtech wrote: post #707

wegs wrote: post #698

Earlier quoted context omitted.

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

It's not a test of grit. git happens to exemplify -- as well as any system I know -- many aspects of good data engineering. If you're into data and ML, those are things you ought to know too.

For a data/ML position, in most cases, I'd expect you to be able to handle data cleanly and efficiently.

If you can't, there are jobs far over on the data side, but:

1) As a business data analyst, you're fine with Excel and PPT, but you'll be paid roughly 1/3 of an ML/SWE position, and you should have excellent communication skills.

2) There are primary mathematical positions, where you work with a data engineer, but you'd better be awesome at math. AND it still helps to be able to handle data cleanly.

Even so, good data workflows require knowing what you did, when, and to which version of data. Properly used, git provides an archival log of some of that. I use very similar data structures when I build some of my own data pipelines too, with data stored under its hashes, Merkle trees, DAGs, and similar. If you find that "annoying and time-consuming," I'd hire you for a business data analyst, and not much more.

It sounds like you find that stuff boring, though. It's a test of interest, passion, and drive, much more so than diligence and grit. Although those are important too.

Re: Git is too hard

#713

Post by kubanczyk » Tue, Nov 17, 2020, 10:29 PM UTC

JeremyNT wrote: post #695

chokolad wrote: post #538

Earlier quoted context omitted.

> As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

> I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there. I never work on a checked-out version of a branch that's currently being updated. I always check out a new branch for my work and rebase or merge off the branch others are working on. I'm fully aware of stash, and every now and then I use it, but it's pretty infrequent. Seeing as you need to learn branching anyway…

Exactly. For some busy repos I tend to remove local master (and develop) branches altogether. It's less moving parts that way.

    git branch feature1 origin/master   # create
    ...
    git fetch --all
    git rebase -i origin/master feature1

Also, use emacs's magit as a better ui. Even if you don't use emacs, seriously. It's fantastically easy and fast.

Re: Git is too hard

#714

Post by h0l0cube » Tue, Nov 17, 2020, 10:31 PM UTC

sethammons wrote: post #711

h0l0cube wrote: post #703

Earlier quoted context omitted.

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.

ah, that is likely part of it. We always branch from master and merge back to master. Builds prevent failing code from merging. It is rare that we branch from a branch, and that 2nd branch would never be merged before the first.

During rapid mobile and frontend development, occasionally I'll be working on someone where there's co-depending feature branches, but for the most part the team usually follow something like git-flow. But I take your point that viewing the graph isn't essential, and those aliases might look scary on a one-page crash course. (I really think `git lol` and `git lola` should be first class citizens of a git installation though)

Re: Git is too hard

#715

Post by greggturkington » Tue, Nov 17, 2020, 10:33 PM UTC

bollu wrote: post #192

anotherevan wrote: post #139

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does no…

Ah, so just a file space with a rooted DAG where each node is a diff with paths manipulable by queries where diffs can use a groupoid action to produce a new file or conflict, resulting in an API to interact with a torsor.

Re: Git is too hard

#716

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

wegs wrote: post #712

rmtech wrote: post #707

Earlier quoted context omitted.

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

It's not a test of grit. git happens to exemplify -- as well as any system I know -- many aspects of good data engineering. If you're into data and ML, those are things you ought to know too. For a data/ML position, in most cases, I'd expect you to be able to handle data cleanly and efficiently. If you can't, there are jobs far over on the data side, but: 1) As a business data analyst, you're fine with Excel and PPT,…

A good data management system (with hashes of datasets etc) is great. Data mess is not fun.

Merkle trees are also fun and have applications elsewhere like cryptocurrency/blockchain.

I don't have a problem with computer science in general, it's a fascinating subject.

Re: Git is too hard

#717

Post by harrisonjackson » Tue, Nov 17, 2020, 10:42 PM UTC

simiones wrote: post #701

harrisonjackson wrote: post #653

Earlier quoted context omitted.

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

Interesting - thanks for the extra info.

I think the habit of committing more frequently stems from working remotely across different timezones and still making code review a daily habit. It is part of our async communication. If someone hasn't committed code for a few days I'd be concerned they were going down a bad path or getting stuck.

I may not even communicate with that team member outside of a PR for the whole week so that's where most of our communication happens if I don't see them in slack or zoom - which would be the case if our work hours don't overlap.

But hey! As long as what yall are doing works for you then no worries. No team manages their code the same way - which I'd say is another plus for git.

Re: Git is too hard

#718

Post by AlchemistCamp » Tue, Nov 17, 2020, 10:43 PM UTC

ivanhoe wrote: post #381

rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

It says a lot about your temperament that status, log and reset didn't make your list!

I use the first two so much that I've dedicated a keyboard macro key to each.

Re: Git is too hard

#719

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

krageon wrote: post #579

rmtech wrote: post #422

Earlier quoted context omitted.

That doesn't matter, the way people actually use git is that almost all repositories have someone or some small group who rule them, so nothing is really lost by having an easy option to purge things from history. And an inconvenient option (possibly more than one!) does exist.

It matters a lot, because the use cases you've seen aren't the only ones that exist. In a tool so widespread as git, that is really not surprising. By removing it's decentralised nature you've fundamentally built a different VCS. Perhaps SVN is acceptable for your use case, that's great! It's definitely not git though - basic expected use cases were lost as predicted at the start of this thread.

Any system will get dragged down by the need to support all sorts of legacy use-cases. I think there's an xkcd cartoon about this?

The core task of a VCS is versioning and collaborating on text of some kind. Git doesn't do this in an optimal way, so eventually it will get replaced by something better. In the meantime we'll all get on with learning its ins and outs, just like previous generations learned how to use punchcards.

Re: Git is too hard

#720

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

lsaferite wrote: post #546

rmtech wrote: post #368

Earlier quoted context omitted.

I use an x86 CPU every day for work and I have no idea how it works in detail, and thanks to the magic of separation of concerns I don't have to (perhaps apart from a few specific things like vecorizing instead of loops that I really do need to know about). Git demanding a large chuck of user mindspace isn't an advantage for git, it's a signal that git is bad and needs replacing.

It comes down to your distance from a specific 'tool' or system. You aren't writing x86 assembler. You are presumably writing some other, higher-level language. I would fully expect you to know that language in detail and even better to understand the performance implications of the choices you make in that language. Knowing the lower level details helps there, but it's not 100% required. With git, it's something you…

> With git, it's something you _directly_ interact with so I would expect you to understand it in great detail.

Yes, you are describing what is broken about git: its abstractions are leaking too much so people who touch it have to know all its internals.

I touch x86 assembler every time I run high-level code, it's just that other kind folks have gone to a lot of effort to make it so that I don't have know how the internals of that low-level stuff work.

Abstractions allow people to be productive without knowing in great detail how absolutely everything in the universe works. A good tool has simple, non-leaky abstractions with a simple interface. Git is not a good tool.