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

331–340 of 821 posts

Re: Git is too hard

#331

Post by hvidgaard »

thdrdt wrote: post #50
dimgl wrote: post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

Imho Mercurial is much easier than Git. I have seen team members who lost data with Git but never with Mercurial. I still miss Mercurial. Unfortunately most people moved to Git so I also moved to it.

Quite some years ago we switched from git to Mercurial and the amount of VSC mentoring and unfucking the "VCS guys" had do became almost zero. People seriously just got it. Some argued that is was because they had to learn with git, but... since then we've made the switch back to git for other reasons and we've back at wrangling with the tool again. I'd much much rather use Mercurial with Evolve extension - that is really good.

Re: Git is too hard

#332

Post by Debug_Overload »

thaumasiotes wrote: post #294
detaro wrote: post #262

Earlier quoted context omitted.

The git book explains the internals very well, so you can easily verify it for yourself. Files are referenced as objects in trees, which are pointed to by commits. editing a file creates a new object for it. (edited for tone)

From the book: > You have two nearly identical 22K objects on your disk (each compressed to approximately 7K). Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? > It turns out that it can. The initial format in which Git saves objects on disk is called a “loose” object format. However, occasionally Git packs up several of these objects in…

That's just for compression. Commits aren't diffs, and when you checkout stuff, git doesn't do diffs to give you the working directory at that point. See https://stackoverflow.com/a/25028688/8272371 for detailed explanation.

Re: Git is too hard

#333

Post by karatinversion »

strken wrote: post #304
skohan wrote: post #243

Earlier quoted context omitted.

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get t…

I think viewers like gitk or tig, or more powerful tools like magit/sourcetree/etc. when used purely to see your repo's history, are not only acceptable but are the quickest and most intuitive way of understanding what's going on. I'd hate to be restricted to `git show --oneline --abbrev-commit` or similar commands that don't show branches and merges.

In case you don’t know, there’s also git log --oneline --graph

Re: Git is too hard

#334

Post by saurik »

lmm wrote: post #185
leobakerhytch wrote: post #172

Earlier quoted context omitted.

I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes. Sure, if you’re really…

> I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? No, I'd say the opposite. The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit. When I didn't know about the staging area and just com…

That's how you get good commits... you do a bunch of changes to understand what you should have done and then you retell the story by carving it into commits. I have been doing this constantly for like a decade now and almost never "give up"... in contrast, Subversion, which doesn't have a staging area, is almost impossible to use as it requires you to somehow code in order the first time, which is ridiculous: no one is that perfect.

Re: Git is too hard

#335

Post by rmtech »

lsaferite wrote: post #319
rmtech wrote: post #252

Earlier quoted context omitted.

Probably the biggest problem with the git interface is that the interface exposed to the user isn't sufficiently abstracted from the implementation. Insanely complicated commands to undo things are one symptom of this. As a user, you want to "save" some code and you also want to "share" it with others. You also want a historical record of what you did. But obviously you will occasionally save and share things you did…

You mostly lost me at "point-and-click", but I'll bite. git rebase -i {hash before your changes} git push -f And since you talked about point and click, you could easily enough use github permissions on branches to prevent this on protected branches or you could configure your git repo to disallow force pushes. To get specific branch protections on a normal git repo you would need to use a hook to validate the update…

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 AFAIK that doesn't exist, or at least the ways to accomplish that are pretty gnarly and dangerous.

Re: Git is too hard

#336

Post by magicalhippo »

leobakerhytch wrote: post #172
jasode wrote: post #144

Earlier quoted context omitted.

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…

I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes. Sure, if you’re really…

> porcelain without it encourage overly large commits?

Not for me. When using Mercurial back in the day I would manually split up commit, usually by copying over sets of files into a clean repo and committing there.

In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped.

I want the stuff on disk to be what I commit, I want the "staging area" to be the changes that I've made that are not yet committed. This way I can pick a set of changes, compile, run tests and commit.

With Mercurial you could sorta do this with stashing I think, but I swore off it after losing changes a few times.

Re: Git is too hard

#337

Post by lsaferite »

ajuc wrote: post #99
ghayes wrote: post #85

Earlier quoted context omitted.

I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `…

The problem is - if you're not using some feature every month you won't remember how to do it anyway when you finally need to use it. So there's little point reading about exotic features upfront other than to know they exist. And which features are exotic depends on your workflow. It would help if git interface was consistent enough to make remembering this stuff easier. For example I never remember the exact option…

> For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again.

I would argue the value is in knowing that something is possible using the `git reset` command so you know to go looking for the exact option to do what you want. And more likely you'll remember the operation if it's one you find yourself using frequently.

Re: Git is too hard

#338

Post by fs111 »

cabirum wrote: post #143

Git should have been a library to create multiple compatible CLI/GUI implementations. The Git CLI has become too bloated to use. It will take a month to read through the manual and learn all available commands. A well-designed VSC should not take that long to learn.

nobody has to read all man pages for all commands. In day2day operations, you maybe use 2 handful of commands, if at all. Everything else can be looked up on demand.

You also don't read all of the documentation of the standard library of your programming language before you start using it.

Re: Git is too hard

#339

Post by detaro »

thaumasiotes wrote: post #320
detaro wrote: post #301

Earlier quoted context omitted.

Which is explicitly a lower-level optimization applied to files well-suited for it and not related to the concept of a commit . A commit does not reference a diff.

Fair enough. The blob stores a diff. The commit stores a reference to... the diff. This is a division between the concept of the object and the implementation. But it's not an example of a diff-storing model failing to model git as it is; git as it is is storing diffs. If a commit references a "blob", and the "blob" that it references is, in fact, a diff, why would we say that the commit "does not reference a diff"?

I would understand "a commit is/contains a diff" as the commit referencing the difference to its parent commit(s), whereas in a packfile the diff might be against a blob belonging to an entirely different branch of the repository, if that's a better diff. Which might be different for each file. And the blob doesn't have to be a diff, it only is if the packer found a good candidate.
Post reply on HN