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

311–320 of 821 posts

Re: Git is too hard

#311

Post by lmm »

acdha wrote: post #221
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? What do you mean by this? It sounds like how stash already works. > If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it? This is how git has worked for years: you can checkout a non-conflicting branch without stashing. > Why can't I pull…

> What do you mean by this? It sounds like how stash already works.

I want to switch branches when I have some added (staged) changes and some unstaged changes, and keep the same set of staged and unstaged changes afterwards.

> This is how git has worked for years: you can checkout a non-conflicting branch without stashing.

Only if none of the changes are to the same file, even if they don't conflict.

> Have you customized Git to not support this?

If I do "git pull" it does a fetch and then something else. I'd like to do just the part that's not a fetch (because I fetched the same remote recently).

> When does it make sense to do this? I can understand deleting a remote branch (which doesn’t require this) but deleting the current local branch doesn’t seem to make sense in any normal workflow.

When I've finished working on something and aren't going to work on that repo again for a bit, I'd like to delete the feature branch that I just merged remotely, but I don't want to check out anything else in particular. So I usually end up doing a git checkout --detach just so that I can delete the branch, which feels cumbersome.

Re: Git is too hard

#312

Post by thrwyoilarticle »

varispeed wrote: post #7

To be fair I have seen a company who had a dedicated git guy who was committing, merging, pushing whatever on behalf of the developer after nth time some of them screwed the repo completely. When I started learning how to use I had people telling me it is difficult, but were not able to explain why they think it is difficult and I started learning having this in mind and that made it unnecessarily complicated. I thin…

I have this view with calculus. Basic integration and differentiation is just simple arithmetic.

Re: Git is too hard

#313

Post by enriquto »

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, after saving your changes, you still need to add them, commit them, and finally push them. What I want is less stuff, not more. All my keypresses and states of files at any moment should be automatically saved forever, without action by my part. Then, if I want, I can "tag" a state of the file tree to refer to it later. The perfect git interface should only have two commands: "git init" and "git tag". All the rest of saving and bookkeeping could take place automatically.

Re: Git is too hard

#314

Post by lmm »

lsaferite wrote: post #308
lmm wrote: post #185

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

The whole point of a tool like git is so that I don't have to expend personal discipline.

Re: Git is too hard

#315

Post by AshamedCaptain »

edflsafoiewq wrote: post #259
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.…

checkout -b seems more logical to me, but not even close to 1000x more logical. Whether it should go on branch or checkout is just an opinion. You're blowing some tiny disagreement up to ridiculous levels.

I actually dislike Git profusely but these arguments are very, very poor. git checkout --branch vs git branch --chekout ? Depending on how the wind blows I could see myself leaning on one or the other. WHO CARES? This is not even a paper-cut level of annoyance.

Re: Git is too hard

#316

Post by 3np »

thrwyoilarticle wrote: post #217
3np wrote: post #175

Earlier quoted context omitted.

Maybe what we really need is not a new VCS, just a new CLI frontend for git.

If it was easy to create a frontend that worked seemlessly on a git repo then it would have been done already.

Buzzkill! I think it's more a matter of that those who are in a position to do so are used enough with git-cli that they are happy with the status quo.

Re: Git is too hard

#317

Post by aeyes »

secondcoming wrote: post #189
pelasaco wrote: post #157

Earlier quoted context omitted.

I use git daily. I never use merge. I use git rebase, and its interactive version all day.

Ya, I'm the opposite, I never use rebase. Horses for courses...

You should, or do you just merge updated remote branches into your stale local branches? A lot of new developers seem to do that here until we explain to them how it messes up the history.

Re: Git is too hard

#318

Post by dkdk8283 »

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

When I first started writing software I would often rewrite third party libraries I didn’t understand to reduce complexity.

After growing up and becoming wiser I came to understand I did this all because I didn’t invest the time to learn how these complex things worked. It also made me feel smart to write more code. Big mistake.

I can’t help but think a little bit of this pattern rears it’s head as the motivation for things like git GUIs.

There will be a maintenance burden and no matter how careful you are there will be bugs.

I write scripts for complex but infrequently used operations and drop them in ~/bin

Re: Git is too hard

#319

Post by lsaferite »

rmtech wrote: post #252
thrwyoilarticle wrote: post #218

Earlier quoted context omitted.

>I could say more about what you would do to make a better version but a comment isn't the place for that. I'd be very interested because it's rare for me to see anyone attempt and, when I do, they break a basic use case.

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 before it's accepted.

Re: Git is too hard

#320

Post by thaumasiotes »

detaro wrote: post #301
thaumasiotes wrote: post #294

Earlier quoted context omitted.

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.

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"?

Post reply on HN