Live data from Hacker News

Git undo: We can do better

blog.waleedkhan.name

141–150 of 490 posts

Re: Git undo: We can do better

#141
post #116
post #60

Earlier quoted context omitted.

Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?

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]

Re: Git undo: We can do better

#142
post #120

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 come across this attitude a lot. 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? Do you treat a new programming language or framework with the same disdain? I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A…

> I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A workflow that hamstrings yourself to git stash as a poor man's branch.

FYI, the branchless workflow linked to in the post is really the opposite of this. It encourages making commits even more often than you would in the traditional branching workflow, and discourages using the staging area or stashes when commits would work fine.

Re: Git undo: We can do better

#143

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

Re: Git undo: We can do better

#144
post #76
post #11

Earlier quoted context omitted.

git reflog is hard enough so that I (a software engineer for 12 years and a git user for 10+ years) have to look up its syntax every time I need it.

Weird, it has no syntax...

I'm not sure what you mean. Typing "git help reflog" brings up a man page that lists commands like "show", "expire", "delete", etc., each with additional options.

Re: Git undo: We can do better

#145

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…

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

First of all, a well-designed Git GUI (examples below) exposes the git's underlying data model to you; in contrast, the CLI obscures it until something breaks and you're forced into it without context. Git operates on a graph and there is simply no way around it. The more you're exposed to the graph, the better you can mentally model it and ask it to do the right things.

While there are many half-baked Electron-based UIs that only unnecessarily complicates things, there are good ones too:

On Windows (and Linux thru Mono), I use GitExtensions. The visualizations are sane and discover-friendly. It will tell you what to expect.

When I work on C++ projects, the one built into CLion (JetBrains family; as mentioned by a sibling comment) is very good on its own. What impresses me the most is that has good visual support of a patch-oriented workflow. You can work with multiple "changelists" offline, shuffle individual changes around, seamlessly convert between changelists and patch files, and (most importantly) still work nice with the vanilla git model as the "actual history". It also works transparently with conceptually monorepo projects that have multiple physical repos, allowing you to do simultaneous commits.

I feel VSCode, GitHub client, Kraken, and several other Electron-based stuff, are too focused on the "polish" than substance, or are too opinionated to be used across repos I don't own.

Re: Git undo: We can do better

#146

Earlier quoted context omitted.

I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…

definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin m…

can you explain the `git pull origin master` thing one more time here?

Re: Git undo: We can do better

#148
This is a great idea. There are well-documented ways to undo things on stack overflow, but almost every way:

1. Has three competing ways available to complete the 'undo'

2. Every way has a scary caveat that the user must be aware of

It would be awesome to simplify the process for new users.

Re: Git undo: We can do better

#149
post #5

> Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes. Here's something that happens when people are encouraged to make more mistakes: they make more mistakes. The piece where people are encouraged to learn from these mistakes is missing from the author's equation. Without that, this tool becomes a crutch at be…

Perhaps it should have been stated outright, but the operative theory appears to be that if mistakes cost less, making more of them becomes the learning exercise.

[deleted]

Re: Git undo: We can do better

#150
post #141
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]

You can also quit the CLI editor, e.g. vim.
Post reply on HN