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

301–310 of 821 posts

Re: Git is too hard

#301

Post by detaro »

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…

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.

Re: Git is too hard

#302

Post by ziml77 »

mcintyre1994 wrote: post #114
zingermc wrote: post #83

Earlier quoted context omitted.

I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate…

I have a horrible feeling your answer to this is going to stress me out, but does that work even without a force push?

Probably because removing branches from the remote doesn't make the commit history inconsistent with any copies made before the push. That seems to be the only case where git second-guesses what you tell it to do.

Re: Git is too hard

#303

Post by lmm »

the_imp wrote: post #256
lmm wrote: post #191

Earlier quoted context omitted.

Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't? If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it? Why can't I pull without fetching? Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"? Why is there no way to…

> Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't? But git stash does keep track of what it added? > If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it? If your current changes apply to files which haven't changed between said branches, you don't need to stash your changes when switchin…

> But git stash does keep track of what it added?

Added as in staged

> If your current changes apply to files which haven't changed between said branches, you don't need to stash your changes when switching between them.

Yeah, I know. So why do I have to stash when I've changed an unrelated part of the same file?

> The command for that is `git merge`.

But that doesn't know which branch is upstream, I have to tell it explicitly each time.

> The command for that is `git push origin HEAD`.

I want "git push" to just do that.

> The option for that is `--no-track`.

Yeah, I know, but I wish I could just turn it off for when I forget, or when I'm doing it from an IDE or similar.

Re: Git is too hard

#304

Post by strken »

skohan wrote: post #243
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.…

> 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.

Re: Git is too hard

#305

Post by baq »

x87678r wrote: post #247
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.…

Wait what? How come nobody told me about gitk.

let me tell you about

   gitk --all
PS.

   git gui
allows you to stage changes line-by-line, not just by hunk

Re: Git is too hard

#306

Post by lentil_soup »

dijit wrote: post #211
rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

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 use Perforce everyday since it aligns better to the needs of the games industry.

I have my problems with it, but once you understand it I find the workflow quite simple.

If you don't really need the decentralization I think it aligns quite well with how people expect version control to work. You make edits to your data, once you're done, you send them to the server to be shared with other people.

Re: Git is too hard

#307

Post by user5994461 »

skohan wrote: post #243
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.…

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

>>> if I want to do something more complex

If you want to do something more complex, the reasonable answer is usually to delete the directory and clone again.

Re: Git is too hard

#308

Post by lsaferite »

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…

> 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.

That sounds like a personal discipline problem and not a poor tool.

Re: Git is too hard

#309

Post by toopok4k3 »

willis936 wrote: post #291
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…

How is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?

Nothing has stopped anyone from creating this perfect GUI(or better CLI) for Git that a lot of people seem to be missing.

"Show me the code". Or in this case show me the GUI.

Maybe the problem is just actually hard and the Git we have is the best current solution.

Re: Git is too hard

#310

Post by jgilias »

Git is as hard as you make it.

It's a bit like raising kids. You don't bash them with the intricate model of the world that you have developed at an age when they are not ready for it. The police are the good guys, the criminals are the bad guys. Sure, there are places where it's the other way around, but you don't really go about telling them about corrupt police departments or authoritarian governments when they are three years old. The goal is to build a mental model that is a good and usable first approximation of the world that they live in. There will be plenty of time to get into the details and edge cases later on.

Similarly with git, you can very much give someone a good and usable first approximation that lets them be productive with it quickly, and then go deeper as needed.

If, however, your normal git workflow involves using a lot of git features that were originally implemented to solve certain edge case situations, then this is not really git being complicated. It's people making it complicated for various good and not so good reasons.

Post reply on HN