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

291–300 of 490 posts

Re: Git undo: We can do better

#291

Post by u801e »

usr1106 wrote: post #183
fierro wrote: post #146

Earlier quoted context omitted.

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

I don't think using `git pull` is a particular good way of working. A pull is a fetch and merge or a rebase combined. If it's difficult to keep your mental model of some system up to date, I doubt that doing bigger steps at once makes things easier. So 1. run `git fetch` 2. if the textual output does not tell you what has happened, run `gitk -all` 3. Decide what to do. Rebase, merge, whatever. Of course if you know e…

> I don't think using `git pull` is a particular good way of working.

I agree. For a DVCS like git, separating the network transaction from updating the working copy on disk is the best way to go about it. Going in the other direction, this is the default since git add, git commit and git push are executed separately.

Re: Git undo: We can do better

#292

Post by jonnycomputer »

smilekzs wrote: post #145
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 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 El…

So back when I was learning git, I was very shy about using any GUI because I was afraid that it would make learning how git works that much harder. I think that I somehow felt that the CLI was more fundamental, in some way. But I think you are right, and I was wrong. A better interface that puts the graph front and center would have led me to learn it so much faster, especially when it also exposes the command line equivalents, as magit does (or so I've heard).

Re: Git undo: We can do better

#293

Post by skrebbel »

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/

Wow, I'm absolutely blown away, this is what I want a Git UI to be.

But I'm not on Mac, does anyone know of a tool that has a similar design idea behind it that works on Windows or Linux?

Re: Git undo: We can do better

#294

Post by skrebbel »

jldugger wrote: post #214

`git-undo` has been part of git-extras[1] for a while. It doesn't use fancy git magic, so maybe this is better. [1]: https://github.com/tj/git-extras

It only removes the last commit. It's terribly named IMO, actually, cause I think that's seldomly the kind of thing you get into "omg I messed up how do I undo" panic for.

The undo described here is much more powerful and much closer to what people expect from the word "undo" from its functionality in other tools.

Re: Git undo: We can do better

#295

Post by davvid »

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…

There's an ongoing effort to rework core Git so that the hash implementation can be swapped out for eg. SHA256. [1]

jGit is actually a separate project from core Git, but once it gets adopted into core Git we can expect that jGit will follow suite, given that it's critical to Gerrit and other projects.

[1] https://lore.kernel.org/git/20191223011306.GF163225@camp.cru...

Re: Git undo: We can do better

#296

Post by jozvolskyef »

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…

Have you tried reading the manual[1]? I read it cover to cover once and it is invaluable because it gives you the ability to understand and describe what you're trying to achieve. The solution is always one search away if you know how to ask.

[1]: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/us...

Re: Git undo: We can do better

#297

Post by mbeex »

stormbrew wrote: post #169
fierro wrote: post #146

Earlier quoted context omitted.

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

like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/ ` (or really `refs/heads/origin/ `) is just a cached pointer to the last known state of tha…

> (or really `refs/heads/origin/`)

It is worth the time to fully understand refspecs. Once people do, they tend to understand all essential ramifications of branch and repository naming.

Re: Git undo: We can do better

#298

Post by contriban »

float4 wrote: post #22

> novice users are terrified of it. When they make a mistake, many would rather delete and re-clone the repository than try to fix it In my experience most beginners use a GUI like Atlassian Sourcetree or the Github desktop client. It's a lot harder to make mistakes using the GUI in my experience. I still really like this idea though; eventually a subset of the beginners wants to learn the git cli and that sure seems…

I occasionally screwed it up even with a GUI, possibly because I was trying to recover something and then got lost. Once I had to abandon the master branch for a year because I didn’t know how to fix it.

A year later I had probably learned how to force push correctly and took hold of it again.

However I do think the GUI is great for git and that’s why I use GitHub Desktop. It’s super simple. Most other GUIs try to wrap git concepts too closely for comfort.

Re: Git undo: We can do better

#299

Post by ycken »

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…

> The truth is, while we use git every day, most people really don't understand how it works.

It is a tool. One should not need to understand the inner workings of a tool to use it. How many APIs do we use where knowing how it does what it does is required? Whether it's Stripe or Node or Bundler or ..., the user does not have to know what happens inside. The need for incantations makes some people feel powerful or exclusive. I just want my tools to do their job so I can focus on doing mine.

Re: Git undo: We can do better

#300

Post by cerved »

rileymat2 wrote: post #272
cerved wrote: post #251

Earlier quoted context omitted.

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

The use case it frustrates me in is when you want to work on the structure of the repository before you have all the code. For instance, it is nice to think about the repo holistically sometimes before I have say an actual unit test to put in the directory, it is nice to create that structure in the repo.

I see. But then why the record that structure in the index? Isn't it enough to have it remain in the working directory? Or if you need it in the index, just the canonical empty .gitignore?
Post reply on HN