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

131–140 of 490 posts

Re: Git undo: We can do better

#131

Post by chalst »

globular-toast wrote: post #85

> 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. Agreed. When I was learning to climb the instructor told me I would never reach my full potential until after the first fall. You cannot work at your limit until you trust the rope. However, I think this is still avoiding the rope. Git is really simple and…

The easiest way to make mistakes cheap is to have your working directory on a filesystem with automatic snapshots, such as nilfs.

Re: Git undo: We can do better

#132

Post by jahnu »

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…

Can I give a shout out to Fork here for being another great GUI for git. I'm not affiliated with them in any way. Just a happy customer.

https://git-fork.com/

Re: Git undo: We can do better

#133

Post by rileymat2 »

zach_garwood wrote: post #56
simias wrote: post #31

Earlier quoted context omitted.

Hard disagree, git's docs and UI have improved over the years but every time I have to teach it to a beginner I realize how arcane and scary it is, especially when compared to old school centralized VCSs like subversion. Not that I'd trade git for subversion mind you, in the hands of a trained individual git is a godsend, but the training part can be arduous. Even among DVCSs I'd argue that mercurial for instance is…

If it's an issue of having to read the docs or the man, well I've been at work like this for a little over a decade and I still have to pull up a reference when I want to do something nontrivial in, not only git, but pretty much every cli tool I use on a regular basis. Cli tools, frameworks, libraries, languages... I have to pull up a reference for everything I do as a programmer, so it's hard for me to muster up the…

`git add `

Wait, how do I remove it from staging? It seems there should be some symmetric operation, `git remove ` or something. Maybe git rm ``, whoa don't do that.

No, it is `git reset HEAD -- `. There is no mental symmetry.

Or why use add at all? What am I adding it to? It is so generic, why not `git stage file` and `git unstage file`?

I agree that you need to read and learn tools, but there is a lack of consistency and symmetry in many of the commands which make it harder.

Re: Git undo: We can do better

#134

Post by renewiltord »

phonebucket wrote: post #101

git config --global alias.undo 'reset --soft HEAD~1' Not that I would include this in my own shell. To the authors two example uses: 1) Undoing an amended commit. But if you're comfortable amending a commit, can't you just amend your amended commit? 2) Accidentally commiting an incorrectly resolved merge conflict. Revert the change if you want to be non-destructive. Reset HEAD~1 otherwise.

1. I believe it’s not that you want to amend it, but that you want to restore its pre-amended state. I would use the reflog to look that up and then reset to it but this makes that easy and hence, more accessible (which is good)

2. Yeah, but I think the UX improvement of a single command to say “Go back to where I was” is reasonable.

Re: Git undo: We can do better

#135

Post by urxvtcd »

dheera wrote: post #60
handrous wrote: post #32

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…

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"?

> And if I push without first pulling

I think I know git well, but you got me confused. I've never heard of pushes causing merges. Surely you are talking about pulls, right?

Re: Git undo: We can do better

#136

Post by eric4smith »

Ensorceled wrote: post #126
lugged wrote: post #120

Earlier quoted context omitted.

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…

At one time I was an expert in 'C'. I was the goto guy at our company for porting and performance issues and was often just handed the entire project if it involved porting. I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.

Bingo.

Re: Git undo: We can do better

#137

Post by jahnu »

dilap wrote: post #94
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/

GitUp is such a great app & fantastic UI design, but the author gave up on it at maybe 80% of functionality, and I think for that reason (among perhaps others), it never really caught on. (It's open source and there are still occasional commits, but it doesn't seem to be really actively worked.) Nevertheless my main daily driver, along w/ the command line. It's undo capabilities, best-in-class visualization of the ti…

An ex-colleague of mine used to maintain a fork here. Maybe you could encourage him to continue :)

https://github.com/douglashill/GitUp/releases

Re: Git undo: We can do better

#138

Post by [deleted] »

ItsMonkk wrote: post #95
dheera wrote: 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"?

It is for this reason that I have changed my workflow to always stash first, then pull, then pop the stash and do the merges locally, then push.

[deleted]

Re: Git undo: We can do better

#139

Post by gpanders »

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.

Re: Git undo: We can do better

#140

Post by gerbilly »

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)

Post reply on HN