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

251–260 of 490 posts

Re: Git undo: We can do better

#251

Post by cerved »

saiojd wrote: post #112

Great work. I wish usability/ergonomy was taken more seriously for popular tools that everyone uses (like git). Another stupid pain point with git is the inability to commit empty directories. I mean, come on.

Git takes stability and extensibility seriously. Your demands and expectations on version control may be radically different from mine.

Empty directories do not contain files or information, it's entirely reasonable for a VCS to omit such a feature. Not sure which use case for git is hindered by the inability to check-in empty directories. I would even suggest such a use-case may be a case of DIW

Re: Git undo: We can do better

#252

Post by greenshackle2 »

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

Maybe because like 90% of devs use git; there's no language or framework that is used by so many.

Re: Git undo: We can do better

#253

Post by RichardCA »

rags2riches wrote: post #159
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?

This conceptual overloading of language can be traced back to Linus' first commit.

https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

The original idea was "current directory cache" and that still pops up in the syntax.

I always run "git diff --cached" as a last sanity check before a commit.

Re: Git undo: We can do better

#254

Post by uvesten »

matheusmoreira wrote: post #189
Hamuko wrote: post #78

Earlier quoted context omitted.

> The truth is, while we use git every day, most people really don't understand how it works. Most people don't know how the Internet works and yet it's widely used. You don't need to understand the inner workings of git. You just need to know some commands and some basic concepts.

> Most people don't know how the Internet works and yet it's widely used. Yeah. I've met many developers who have no idea what a cookie even is, people who have never read a single IETF RFC.

Me too, far too often. Those developers are most often negative contributors...

Re: Git undo: We can do better

#255

Post by sam_lowry_ »

stickfigure wrote: post #223
stormbrew wrote: post #105

Earlier quoted context omitted.

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…

I've actually worked on git internals and I'm in the same boat. As part of a security-related project some years ago, my team and I hacked jgit to use SHA256, which required changing the length of pretty much every on-disk data structure. Sadly, there was (probably still is) no HASH_LEN constant, just a lot of magic offsets strewn throughout the code. I had to compare lengths against the git spec at every step. And y…

What a pointless project! U hope you were paid well, at least.

Re: Git undo: We can do better

#256

Post by [deleted] »

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…

[deleted]

Re: Git undo: We can do better

#258

Post by Vinnl »

handrous wrote: post #32
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 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…

I'm the same, but I think that's... Fine? If I understand what I want to do in terms of first principles, there's no harm in searching for the exact incantation if I do that only once every few months.

For the rest, there's shell autocomplete and muscle memory.

Re: Git undo: We can do better

#259

Post by swisspol »

arxanas wrote: post #114
gldnspud wrote: post #77

While GitUp is a GUI app, and only available for macOS, I think it's worth noting that it has some great undo/redo capabilities built in. From what I understand, some of them were more feasible to develop because they implemented their own plumbing (GitUpKit), instead of relying on the official git plumbing. https://gitup.co/

Nice, this is really cool. Similarly, I had to implement extra plumbing on top of Git to make snapshotting possible. I'll update the blog post with a reference.

GitUp uses libgit2 under the hood. GitUpKit is an Obj-C wrapper I wrote at the time to make it much easier to use.

Unlimited undo / redo is achieved by taking a snapshot of the entire repo before and after any operation (e.g. checking out the repo or creating a branch etc...). The inspiration I had at the time was that is it is trivially cheap to take such snapshots: essentially all you need is a list of all the refs.

Then when you need to undo, you have 3 things: 1 - current state of all the refs in the repo 2 - state of all the refs from the before snapshot 3 - state of all the refs from the after snapshot Compute the delta between 3 -> 2 and apply on top of 1.

The same technique allows to do the Time Machine feature.

Re: Git undo: We can do better

#260

Post by j605 »

ryandrake wrote: post #168
zibzab wrote: post #50

Earlier quoted context omitted.

Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know

Although it sounds like a silly reason, compare the names themselves. I don’t even know how to pronounce “mercurial” without looking it up. The word doesn’t exactly roll off the tongue like git does. And then the command itself is “hg”. WTF is up with that? I mean, ha-ha we all get the joke, but was the program made for chemists? Unnecessarily clever. Don’t underestimate the extent to which a difficult/confusing name…

I think for most people, they would encounter it in a science class early in life (at least for English speakers). And Hg is just the chemical symbol for mercury, https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Ide...
Post reply on HN