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

151–160 of 490 posts

Re: Git undo: We can do better

#151

Post by nexuist »

thewebcount wrote: post #128

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certa…

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases.

Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either.

In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.

Re: Git undo: We can do better

#152

Post by rags2riches »

OhNoMyqueen wrote: post #70

The most painful mistakes beginers endure with git are irrevocable code removal from the current working directory because of bad usage of `git clean`, `git reset` (or `git merge` if you're brutish enough). This problem cannot be solved by using git, because git doesn't have any reference to such code.

Don't forget `git checkout`!

When I help people get started with git, I tell them several times to commit as often as they can. If they committed it, I can probably save them when they think they lost something.

Re: Git undo: We can do better

#153

Post by chriswarbo »

klyrs wrote: post #141
lugged wrote: post #116

Earlier quoted context omitted.

Git init inits a git repo. Git submodule runs commands on submodules. What is hard about this UX? And it's not punishing you, its doing what you asked, to pull into a non matching head, how does it know you're not using git in the intended and distributed way? Btw, just quit the editor without saving, it aborts.

[misunderstanding removed]

Git invokes an editor, for writing commit messages, etc. (it looks in the VISUAL and EDITOR env vars). That could be a GUI text editor, or something running in the CLI (personally, I use emacsclient to open a new buffer in an existing Emacs window)

What they're saying is: if you quit that editor without saving the commit message, git will abort.

Re: Git undo: We can do better

#154

Post by quickthrower2 »

thewebcount wrote: post #128

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certa…

I feel that I only understand git because I’m forced to use it for years, but the experience could have been a lot less painful. I use a GUI for sure. Do people really diff and resolve big conflicts at a command line? I never figured out how.

Re: Git undo: We can do better

#155

Post by handrous »

klyrs wrote: post #141
lugged wrote: post #116

Earlier quoted context omitted.

Git init inits a git repo. Git submodule runs commands on submodules. What is hard about this UX? And it's not punishing you, its doing what you asked, to pull into a non matching head, how does it know you're not using git in the intended and distributed way? Btw, just quit the editor without saving, it aborts.

[misunderstanding removed]

I think they mean the commit message editor, which git will use to open a temp file to save the message to if you don't specify a message in-line with the "-m" flag when committing, including when a merge commit is initiated by a "pull". This happens on the CLI, it's just usually (though doesn't have to be!) a command line editor that it opens. I think vim's a common default.

AFAIK whatever's opened does need to block the CLI, so you can't use a command that opens a GUI editor then returns immediately or git will interpret that as your having closed the file without saving, but otherwise any editor should work, CLI or GUI, and can be assigned in your git config.

Re: Git undo: We can do better

#156

Post by urxvtcd »

gpanders wrote: post #139
professoretc wrote: post #122

From the article: > How is it so easy to “lose” your data in a system that’s supposed to never lose your data? I think the author is mistaken; git isn't "a system that’s supposed to never lose your data". One of its features is the ability to "lose" data in a controlled way; i.e., to rewrite history. If you want a version control that is supposed to never lose data, use Fossil.

Even if you rewrite history, the data is not lost. The old commits are still in the reflog and can be recovered. It’s extremely difficult to lose anything in Git once it’s been committed. You’d have to do something pathological or intentional.

It's also possible (if difficult) to recover files which have been git-added and not commited. The only files git can't recover are the ones that it hasn't registered in the first place.

Re: Git undo: We can do better

#157

Post by muststopmyths »

overgard wrote: post #127
pizza234 wrote: post #37

Earlier quoted context omitted.

Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.

I find GUI's to be very helpful; most of my commits happen through VSCode's commit panel. For my home Unity3D project I use sourcetree because my commits unfortunately end up being to a lot of unrelated files (blame unity), and having a UI to stage them saves a lot of typing. I avoid anything like rebasing (never got the point of that), but I use branches liberally. I find with this setup, I only need to use a handfu…

If you are on Windows, Visual Studio's GUI is actually quite good for staging, merging and diffing. I tend to use it for most of those simpler kinds of things while still doing commits, rebase etc. from the command line.

Same for VSCode on non-Windows.

I only mention this because I came to hate Sourcetree in its newer iterations on Windows so much that I tried out Visual Studio's support and was pleasantly surprised.

Re: Git undo: We can do better

#158

Post by gbear0 »

phkahler wrote: post #86
gitgitgit wrote: post #49

Earlier quoted context omitted.

I use Git via the GitHub Desktop client ( https://desktop.github.com ) and find it _very easy_ to use Git without issue by following a simple rule: don't be clever. I have branches, I commit, I squash merge via a Pull Request. No rebasing, no moving commits around. There might be workflows where rebasing etc. are important and certainly in those cases, using a GUI is probably not a great idea -- but it's certainly po…

I squash locally, but learning to do that required learning vim. Fortunately vimtutor. Then my distro changed the default text editor launched from git... fortunately I knew enough to get by with that one - which might be emacs but I haven't verified. Git is really weird but useful.

The default editor is usually configurable (of course you'd have to learn all the different contexts you can do this from first to know this is a thing ... discoverability is hard).

For example in ubuntu you can do

  sudo update-alternatives --config editor
Some programs will use the environment variable $EDITOR, so you can add this to your shell startup configs

  export EDITOR=vi
Or specifically for git cli you can run

  git config --global core.editor vi

Re: Git undo: We can do better

#159

Post by rags2riches »

gerbilly wrote: post #140

What makes git really complicated is that for every command you type, there are two things that may be affected: * the working copy * the graph And it gets better, if any file gets disconnected from the graph, it can be hard to locate. (Yes I know, it can be found in the reflog)

Let's not forget about the index. Or is it called the staging area?

Re: Git undo: We can do better

#160

Post by adamrezich »

sloucher wrote: post #143
thewebcount wrote: post #128

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certa…

Last time I checked, 5 of the top 10 questions on StackOverflow were about Git...

still true! but that isn't a great metric necessarily, as #10 is "What is the “-->” operator in C/C++?" https://stackoverflow.com/questions/1642028/what-is-the-oper... which is just a novelty rather than a common question
Post reply on HN