Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

371–380 of 821 posts

Re: Git is too hard

#371

Post by jariel »

aulin wrote: post #207
jariel wrote: post #148

Earlier quoted context omitted.

So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for t…

you shouldn't change history once you make it public, how hard is that? that's the golden rule, if you promise something to be immutable, stick to your promise

'Don't shoot yourself in the foot with a gun - how hard can that be to understand'?

And yet people do it all the time.

The 'rule' is easy enough to understand.

But it's not always clear 'why' that is (in many cases, it won't matter), or when exactly it applies.

In the lowest common denominator cases, the rule is not so hard to follow, but it can get messy quickly and there are many ways to break the rule.

Re: Git is too hard

#372

Post by Technically »

enriquto wrote: post #313

I cannot live without git, but somehow I still "hate" it. A very lovely thing is text editors without "save" button. You change the contents of your file, close the program and that's it. The boundary between "changes in memory but not yet saved" and "changes already saved to the hard disk" is an obsolescence and does not really make sense today. Git adds not one, but three layers upon the idiotic save button. Now, a…

Saving is destructive. Why would you want to trigger this automatically?

Re: Git is too hard

#373

Post by rmtech »

lsaferite wrote: post #350
rmtech wrote: post #335

Earlier quoted context omitted.

That only works in some circumstances. For example, suppose I init a new repo and accidentally commit my entire virtual environment, then push, then do some real work, push a few times more and then a colleague notices (after they have pulled, worked on and pushed) that the venv stuff is there. In an ideal VCS, you would have a simple command like git purge /badfolder that would make it as if it never existed. But AF…

Well, first I'd argue that you are misusing the tool if you managed to commit a large chunk of unrelated code, but that's another story. Second, I would tell you that git has a command for just your situation. git filter-branch https://git-scm.com/docs/git-filter-branch You can run a command against every commit and it will then recommit. That would let you remove, for instance, an entire subdirectory. The downside h…

Yes but filter-branch is horrendous and could very easily result in unintended side-effects, as well as potentially being very slow. I think this command is a great example of the problem; what a user really wants is an undo button but what git gives them is this thing.

Re: Git is too hard

#374

Post by krageon »

skywhopper wrote: post #180
krageon wrote: post #127

Earlier quoted context omitted.

> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…

This is a disgusting, harmful take. You should really step back and rethink your assumptions here. Git is a tool that’s meant to make things easier. It’s complex enough, though, that it’s a stumbling block for a lot of folks for a workflow that really shouldn’t be so complicated. If you intuitively grok how git works, that’s great. I’m going to guess you probably don’t really use it in any challenging or new situatio…

It's evident that you think requiring basic competence is toxic, but you don't really compel me to feel differently. You have told me what I think is the case is toxic, wrong, disgusting and harmful. I now know you feel strongly about this.

I don't hugely feel like seeing things from your point of view because the only thing you've really told me that might change my mind is that you lose people when you require a basic amount of capability. I'm sorry to hear that this grievously wounds you on an emotional level, but I don't see that as a loss.

Re: Git is too hard

#375

Post by simiones »

eloisius wrote: post #225
dijit wrote: post #211

Earlier quoted context omitted.

Weird question; have you looked at perforce? My previous and current company use perforce but many people (often those who recently join) are decrying that perforce is less elegant than git, but, realistically and based on your own criteria it would be "better" for the connected case. I'm personally a big fan of 'offline/local-first' being a thing, but I'm a sysadmin not a developer.

I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.

Funny - I used P4 for about 7 years before switching to Git 2 years ago, and Change Lists are what I miss most from P4. For me it is extremely common to work on multiple changes in parallel, on the same branch or different branches, and organizing my changes in different change lists was the best way to handle it.

I also find git's default of rewriting your worktree when you switch to a different branch extremely annoying compared to simply having each branch be a different directory in the FS. Fortunately, digging around I recently discovered git worktree and I'm much happier on this front at least.

The file locking was always a relatively obscure workflow, so I'm surprised that you even had to see it if you didn't use P4 a lot. I've only seen it in 3 occasions: working with binary files, the error message when I didn't actually have write access, and when someone intentionally locked some files to make sure they don't have any merge conflicts while they finish up a huge commit.

Re: Git is too hard

#376

Post by ROARosen »

andrewla wrote: post #364

The author says that the problem is: > I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it. Fundamentally this is the problem. If this is your use case, then git is not for you. But this is not really a use case because…

> You have to understand how it is implemented under the covers.

That's exactly the point the author was trying to make. Make Git so abstracted from the underlying tech it comparable to a simple task as editing a Google doc.

> If this is your use case, then git is not for you. Well google docs can't have testing, it can't have merging as it is inherently "merged" already, etc. so totally not the use case the author was referring to.

Re: Git is too hard

#377

Post by akatechis »

Can't remember the times I've had to google "Pop commit and move to another branch", for when I accidentally commit to `master` when I meant to commit it to `feature-branch`...

Re: Git is too hard

#378

Post by fogetti »

jamil7 wrote: post #365

I get frequent questions from other developers (not all junior) on how to fix weird messes in git they've made which is fine if you're just learning but at some point it's like seeing a developer who can't type properly, just kinda why subject yourself to so much extra work to avoid learning to use something. Yeah it's kinda hard and not very exciting but it's powerful, a part of pretty much every software related di…

But this is not stubbornness at all. There are way better alternatives like mercurial but you have to fight with the pious Git believers because they just don't give a flying...

And I would argue it's the other way around. I haven't seen a Git believer who would give up his blind belief in Git even if there are way better alternatives. So it's the opposite camp which got stuck in their mindset I would say.

Re: Git is too hard

#379

Post by zests »

akatechis wrote: post #377

Can't remember the times I've had to google "Pop commit and move to another branch", for when I accidentally commit to `master` when I meant to commit it to `feature-branch`...

Magit does this natively with git cherry pick harvest. I type `A h`.

I think the real solution is branch protection, however.

Re: Git is too hard

#380

Post by recursive »

larzang wrote: post #343
thrwyoilarticle wrote: post #265

Earlier quoted context omitted.

I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history s…

Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.

I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone.

I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class feature in git, it seems appropriate to be in some layer other than commits, but alas, that doesn't exist.

Post reply on HN