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

111–120 of 490 posts

Re: Git undo: We can do better

#111

Post by jcranmer »

zach_garwood wrote: post #80
jcranmer wrote: post #54

Earlier quoted context omitted.

> git is already the easiest to understand of any VCS that I've used Breaks down in uproarious laughter. One of the worst offenses git is its use of multiple different jargon terms for the same concept; indeed, it's the only VCS I've used where reading help leaves me less sure than when I started if it does what I want it to do. If I accidentally leave my system in a weird state (say, I'm in the middle of a git rebas…

What are the jargon words youre referring to? In my experience, it uses the same jargon as the other VCSs. Perhaps you have a different workflow than me, but I don't find myself rebasing all that often to begin with. I generally don't rewrite history unless I truly fucked up. And since I'm in "I fucked up" mode, I take extra care with commands I type. I don't wanna be like Apple and say "You're holding the phone wron…

The staging area (aka "index" aka good god don't try to read git glossary's index for this) is a bad one. There's definitely several cases where I've read the documentation and struggle to figure out if it will or will not affect the working checkout or not.

Re: Git undo: We can do better

#112

Post by saiojd »

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.

Re: Git undo: We can do better

#113

Post by jdauriemma »

nsomaru wrote: post #96
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.

Am I doing things wrong if I have never used these commands?

Try not to think of it in terms of right and wrong. `git clean` is useful, though not "can't-live-without-it" useful. I couldn't imagine my workflow without `git reset`, though, and I recommend checking it out!

Re: Git undo: We can do better

#114

Post by arxanas »

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.

Re: Git undo: We can do better

#115

Post by funkymike »

handrous wrote: post #69
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"?

> 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"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a p…

I have this in my .gitconfig so the pull will fail rather than merge.

    [pull]
        ff = only
If it does fail I can decide whether to merge or rebase.

Re: Git undo: We can do better

#116

Post by lugged »

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

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.

Re: Git undo: We can do better

#118

Post by [deleted] »

an_opabinia wrote: post #75
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.

Not a single person I’ve met using git in the last decade has thrived using a UI for it.

[deleted]

Re: Git undo: We can do better

#119

Post by munificent »

lisper wrote: post #89
arxanas wrote: post #62

Earlier quoted context omitted.

There is a design for undoing changes to the staging area: https://github.com/arxanas/git-branchless/issues/10 The similar project [Jujube]( https://github.com/martinvonz/jj ) has experimented with backing up even unstaged changes after every command, and apparently it works well for them, so we could do the same in the above design. Undoing even untracked changes might be a bit much.

Yeah, this barely scratches the surface though. Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like: git branch list git branch create [name] git bra…

> "git branch create" is "git branch [name]".

I've been using Git professionally for of a decade and you just taught me something new. I always use `git checkout -b [name]` (which is a completely bananas UX, but it's the one I know).

Re: Git undo: We can do better

#120

Post by lugged »

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 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 workflow that hamstrings yourself to git stash as a poor man's branch. I get it, I used that as crutch for years, then I spent some time learning git properly.

Most people haven't even watched the one hour talk where Linus talks about the design and building of git.

One hour might sound like a lot to understand why branching is so amazing, and why distributed source control is hard but it's a tool I've used for almost a decade and won't stop using for the next decade. I think it was worth it.

Post reply on HN