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

Git undo: We can do better

blog.waleedkhan.name

Post reply on HN
Print view View original

441–450 of 490 posts

Re: Git undo: We can do better

#441

Post by lmm »

lisper wrote: post #48
eric4smith wrote: post #12

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…

I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…

> 2. Git's merge is not smart enough to realize that identical changes in two branches are not actually a conflict. I've often ended up in situations where a small bug has been fixed in two branches which then won't merge without manual intervention. This is incredibly annoying. (To be fair, this is not unique to git. But because git encourages branching more than other systems, I encounter it more when using git in idiomatic ways.)

I agree with your other criticisms, but IME git's branching-heavy approach makes this one easier to avoid: it's natural and easy to create a separate branch for that bugfix and then merge it everywhere that it's wanted. Or to just merge your colleague's feature branch that has the fix on into your own feature branch, if you know their branch doesn't contain any dangerous changes / will hit master ahead of yours.

(If the diff is actually bit-for-bit identical I think it doesn't conflict? But obviously that doesn't happen so much in practice. git merge -Xignore-all-space can be helpful in some cases).

Re: Git undo: We can do better

#442

Post by lmm »

Ensorceled wrote: post #271
lugged wrote: post #130

Earlier quoted context omitted.

I don't know what to tell you, commit more code? Branch more? Work in teams? Maybe git isn't the right tool for you? I have a set of commands I use multiple times a day, for everything else there are manuals and docs to reference. Git branch, commit, rebase, merge, clone, check out, pull, push, submodule, remote, and maybe a couple more, are there specific commands you don't use daily? Other than remote and submodule…

I was replying to this part of your comment: > Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Seeking out that training would be useless since I don't use git enough. > Maybe git isn't the right tool for you? Git is definitely the tool for me. It's better than any other available tool f…

> Why the hell would I branch more? Just to get better at git? Sorry, I'm sorry that I work on a small team! Maybe I should go back to CVS?

I have multiple branches on the go in a one-person project. I find that very useful. But if you don't, maybe you should go back to SVN? Using git without merging between branches seems like you're making your life complicated for no gain - like using a distributed system framework to run a single-node system.

Re: Git undo: We can do better

#443

Post by lmm »

npteljes wrote: post #207
rjmunro wrote: post #201

Earlier quoted context omitted.

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you u…

And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.

> And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.

You can fix this by doing `git config --global push.default current`.

Re: Git undo: We can do better

#444

Post by lmm »

globular-toast wrote: post #431
meowface wrote: post #364

Earlier quoted context omitted.

Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory w…

You should change the way you work with git. Commits are cheap. Really, really cheap. Commit all the time. Make "WIP" commits to remind you to squash them later. Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.

> Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.

Which means git is failing to do its whole job: keep the history of my work safe. I'd argue that git actually makes data on your filesystem less safe, because it pointlessly write-protects files in the .git directory, which encourages a bad habit of using rm -rf.

Re: Git undo: We can do better

#445

Post by minusSeven »

eric4smith wrote: post #12

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…

90% of the time all you need from version control system is update-> make your changes-> commit/push your changes

You just don't need to learn unless you really require it. And even if you do learn you will eventually forget if you don't use all the features.

Its not hard to see why people don't even bother.

Re: Git undo: We can do better

#446

Post by OJFord »

oblio wrote: post #433
OJFord wrote: post #319

Earlier quoted context omitted.

Or a success of git? No good GUI exists because they realise they'd just be recreating things that exist, but with a GUI frame? If you wrote git 2.whatever from scratch would you structure rhe commands a bit differently? Yeah, sure, probably; but I always think these threads are way overblown. The common stuff that you use frequently.. well you use it frequently, so either you remember it as a result or you use the a…

> if you have to look it up in the excellent documentation, is that a failing Yes, if we ever want version control to become mainstream. Version control is a very practical, day to day concept. It's just almost unusable for regular folks. And regular folks for sure won't use CLIs (unless you point a gun to their heads).

Version control is mainstream; git isn't, and isn't trying to be? Git is version control for plaintext files, (yes yes I know LFS exists) primarily software, and used by people who like using CLIs and have all kinds of other CLI tools for it to interface with.

Who's trying to make 'regular folks' use git, with or without a gun?

Re: Git undo: We can do better

#447

Post by meowface »

globular-toast wrote: post #431
meowface wrote: post #364

Earlier quoted context omitted.

Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory w…

You should change the way you work with git. Commits are cheap. Really, really cheap. Commit all the time. Make "WIP" commits to remind you to squash them later. Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.

Yes, I do do this. But Dropbox is still a good safety fallback. I'm not committing everything for every line of code, but with VS Code auto-save, Dropbox is basically committing a version for every line of code.

It's useful even if I just refactor some code and change part of the refactor and then change my mind and want to go back to what I was initially trying. And it also helps if my hard drive dies or my laptop gets stolen, etc.

Re: Git undo: We can do better

#448

Post by wstone »

Vinnl wrote: post #261
cerved wrote: post #242

Earlier quoted context omitted.

Git checkout branch means change the entire working tree to the reflect the state of the branch and git checkout file, checkout the state of that file in HEAD. Both commands to the same thing, change the state of your working tree to reflect a point checked into version control. It sounds like you are unaware of git switch branch and git switch -c new-branch

Just a tip: when teaching people, the readable alias is easier to remember and understand, i.e. git switch --create new-branch

Thank you. It seems silly but my first parse was "-c(heckout)" but that comes from not using "switch" yet; I need to rewire my brain from "checkout".

Re: Git undo: We can do better

#449

Post by DemocracyFTW »

cxr wrote: post #74
Filligree wrote: post #42

Earlier quoted context omitted.

Take a look at https://eagain.net/articles/git-for-computer-scientists/ ? Maybe you've already read it, but this is what let me grok the underlying data.

The parent commenter makes it clear that they already grok the underlying data. The problem with Git, as explained so, so many times, is its horribly intuitive mapping from UI to the operations those commands preform on that model. Comments like this, which points to a resource intended to help people "grok the underlying data", has the effect of seizing the focus of conversation and implicitly retargeting it to be c…

But... a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor ... so what is the problem? /s

Re: Git undo: We can do better

#450

Post by approxim8ion »

somethingor wrote: post #241
approxim8ion wrote: post #185

Earlier quoted context omitted.

We still use tortoiseSVN at work. It's crude but shockingly simple to use. Moving to git would be a significant expense just to train people not to break things and to get them used to CLI.

TortoiseGit exists too and is fantastic IMO: https://tortoisegit.org/

Wish they put some screenshots on their site, but I'm glad it does if it does to git what it does to SVN!
Post reply on HN