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

221–230 of 490 posts

Re: Git undo: We can do better

#221

Post by arxanas »

renewiltord wrote: post #129

It is interesting. I’ve never had any trouble with git. I think the reason is that I learned it relatively early in my career and so I had the luxury of “What’s the right way to resolve this situation?”. I have never lost data despite using filter-branch, rebase, bad merges, bad rebases, bad branch deletes… Still, the UX sugar of undo sounds quite nice. I only worry about introducing something heavyweight into the th…

No, it doesn't force others to use branchless at all. The git undo data is stored in a separate database in your .git directory, so other people won't have access to it. (Of course, this means that they can't use git undo on your actions.)

Re: Git undo: We can do better

#222

Post by kahkeng »

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.

I find it pretty useful to use the `--patch` or `-p` option (also a mnemonic for "prompt") to various commands:

`git add -p`: prompt which hunks should be added to staging

`git checkout -p`: prompt which unstaged hunks should be thrown away

`git checkout HEAD^ -p`: prompt which hunks from HEAD should be discarded

`git reset -p`: prompt which currently-staged hunks should be unstaged

`git reset HEAD^ -p`: prompt which hunks from the HEAD commit should be unstaged

Nice thing is that you get interactive yes/no prompts with a preview of the change for each hunk, and you can also quit early if you realize it's not the command you want.

Doesn't fully address the potential for lost changes, but slows it down by adding an interactive roadblock for each change.

Re: Git undo: We can do better

#223

Post by stickfigure »

stormbrew wrote: post #105
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…

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 yet I still scramble for stackoverflow every time something goes slightly amiss.

Re: Git undo: We can do better

#224

Post by cerved »

atoav wrote: post #163
lisper wrote: post #48

Earlier quoted context omitted.

I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…

I really would wish git would embrace the idea of not destroying any data unless specifically prompting for it first. Same for merging pull requests. How hard would it be to again prompt in case of conflict how to proceed?

Commits are immutable, itś incredibly hard to destroy data that has been committed. Even if they become loose objects, Git is very conservative when it comes to deleted that. If you have uncommitted data, git will refuse to do lots of operations. The default is always to not delete changes, even if resetting a branch.

Contrast that with TFVC which tries its best to nuke everything within it's reach (that is not under version control) in inexplicably stupid ways.

  tf reconcile . -r -clean
This command is equivalent to

  git reset --hard origin/head && git clean -fdx
Because that's sensible.

  tf reconcile . -r -i clean
One might think -i is a short flag for -ignore. No. It's short for -preview. That's a "feature". Good luck finding the documentation for this idiotic behavior.

How about if you pipe a list of files into tf reconcile, to avoid it's idiotic behavior? Say

  git ls-tree HEAD -z | xargs -0 tf reconcile -r -clean
You better hope that ls-tree outputs something, otherwise that is the same as calling

  rm -rf .
I can't say I recognize your experience. You only risk creating a mess of changes to the point where it's hard to recover due to the share amount data it hasn't deleted.

Re: Git undo: We can do better

#225

Post by lanstin »

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.

And always diff before stash because sometimes it's just random shit I wasn't serious about, so I'll re-checkout that file and then stash the rest.

Re: Git undo: We can do better

#226

Post by leotaku »

jonathanberger wrote: post #219

Git is one of those bizarre products that has remained a leader in its category for almost a decade while being extremely difficult to use, even for experts. Another one of these products is Apache. Why is this? At least from my naive point of view I would expect these extremely user-hostile products to have been overtaken but more user-friendly alternatives. I know the best products don't always win, but when they d…

I would guess that network effects and the amount of quality tools built on top of Git are the main reason for its prevalence.

Fossil and Darcs sure look nice, but having to self-host my repositories or use a smaller company that could go under at any minute? Having to use barely-maintained plugins for my editor, CI, CD, etc.? And most importantly, having to explain a completely new set of tools to anyone who wants to work on my projects? In my opinion, it just isn't worth it.

Re: Git undo: We can do better

#227

Post by cerved »

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…

The CLI doesn't obscure as much as presupposes that you understand internal workings of git.

All GUIs are not created equal. The JetBRains GUIs are pretty good. Others try and impose git "their way" and just invite creating a mess.

Re: Git undo: We can do better

#228

Post by lanstin »

MereInterest wrote: post #211
lisper wrote: post #48

Earlier quoted context omitted.

I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…

> that identical changes in two branches are not actually a conflict I think this is part of a downside of rebase-centric workflows, since it encourages making multiple branches with identical changes, but no shared history. At some point I want to read more pros/cons on different workflows. My current thinking is that rebase-only sacrifices far too much on the altar of a clean-but-inaccurate commit history, but I do…

I think if you run into this a lot, git revere will be helpful:

https://www.git-scm.com/book/en/v2/Git-Tools-Rerere

If you have a lot of long-lived branches that don't merge and get deleted you have a whole different world of pain from normal git usage, and need some resources designed as SCM experts to manage this stuff. But really short lived branches that deliver net steps forward are the way to live.

I hate branches because it breaks git-bisect. Linux kernel history has lived without it, so I'm guessing the "our code is so complex we need it" is a false idea.

Also, the actual history of what main/master points to is linear. If the bit-post merge are identical, it doesn't matter if they were rebased or not except having 2 ancestors for HEAD is a lie.

Re: Git undo: We can do better

#229

Post by zabzonk »

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 don’t even know how to pronounce “mercurial”

But you do know how to pronounce "Unnecessarily"?

Re: Git undo: We can do better

#230

Post by lanstin »

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.

magit (for emacs) is quite good. But I still only use it for browsing around mostly, or single-file commits. For serious work, I start with git status, and then git diff all the changes, and then group them and then commit then in groups, then pull --rebase then push HEAD:good_branch_name (by the time I've done all the above, I have a better chance at a good name than I do for the first commit). Then over to PR land, where we have "ff if possible and delete source branch."
Post reply on HN