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

391–400 of 490 posts

Re: Git undo: We can do better

#391

Post by bentinata »

MayeulC wrote: post #210
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…

> What does "git reflog" or "git reset --hard ...." do? What are the implications? This is supposed to be covered in `man git reflog` and `man git reset --hard`. I admit that it could be more readable though. Currently, it's more of a technically-correct introduction than a layman's. I guess it's really more of a documentation for experts. Some have made fun of this: https://git-man-page-generator.lokaltog.net/ In la…

Minor additions; branches are named commits that move along as you commit, while tags are named commits that stay.

Re: Git undo: We can do better

#392

Post by cellularmitosis »

nexuist wrote: post #151
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…

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this hap…

> Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either.

Well, actually, a lot of people work in large repos, so this can be a pain.

Which of course brings up another failing of the git UI: the difficulty of removing old history from the repo. Last I checked, you pretty much have to use a 3rd party tool for this.

Re: Git undo: We can do better

#393

Post by pjmlp »

lugged wrote: post #357
pjc50 wrote: post #324

Earlier quoted context omitted.

The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master. Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

So use svn?

I would, but the option is not mine to make.

Re: Git undo: We can do better

#394

Post by atoav »

still_grokking wrote: post #354
unknown_error wrote: post #325

Earlier quoted context omitted.

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a small mistake. It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.

Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case. That's reality in engineering. If developers want to call themself "engineers" they should behave as such. On the other side you don't let people without special training ev…

As someone who just learned a thousand electrical norms let me assure you of one thing: the way git handles "dangerous actions" that might delete things is NOT something you would find an equivalent for in the industrial machines, where you have mandatory warning signs, switches for operation with two hands (or even two people), mandatory inspections of these safety features etc.

It is not a different league it is a different sport. If a factory was designed with the equivalent of gits usabilty today, it wouldn't even get a permission to be built based on the plans alone. Also the person who planned it would have a hard time ever doing so again.

If git was a bridge it would have no handrails and it would oscillate in certain winds and for some odd reason there is a roundabout in the middle.

It is still better than no bridge for sure. As one of the first of its kind a lot can be excused, but fundamentally better engineering is possible as well.

Re: Git undo: We can do better

#396

Post by filmor »

cmeacham98 wrote: post #379
meowface wrote: post #364

Earlier quoted context omitted.

Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory w…

They are wrong, there are actions you can take in git that will cause you to lose your "immutable" history. Most accidental cases probably involve `git reset` or `git rebase`, but here's an example if you want to do it intentionally: # Commit all changes and push to at least one remote so your changes are ""immutable"" rm -rf myrepo/ mkdir example && cd example git init # Repeat for each remote git remote add remote1…

`git reset` and `git rebase` will not lose anything that you have commited before. And force-deleting the remote stored repo is cheating (and prevented by default in quite a few services).

Re: Git undo: We can do better

#398

Post by pjmlp »

Shacklz wrote: post #313
woah wrote: post #190

Earlier quoted context omitted.

Sorry, I'm trying to get work done, not memorize an obscure set of incantations like some kind of D&D wizard. If the repo gets messed up, I delete it and reclone.

I really understand your sentiment, and I've been there for long enough myself - but once you have a somewhat decent understanding about gits internal data model, the commands that allow you to clean up pretty much any mess (reset & reflog probably being the most prominent ones) start to somewhat make sense. If you had previous exposure to anything computer-science, it very likely won't take more than a few hours unt…

> And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development.

Unfortunely.

Re: Git undo: We can do better

#399

Post by pjmlp »

somethingor wrote: post #241
approxim8ion wrote: post #185

Earlier quoted context omitted.

We still use tortoiseSVN at work. It's crude but shockingly simple to use. Moving to git would be a significant expense just to train people not to break things and to get them used to CLI.

TortoiseGit exists too and is fantastic IMO: https://tortoisegit.org/

Indeed, it makes using git so much less painfull.

There are days where I daydream of Clearcase when dealing with git.

Re: Git undo: We can do better

#400

Post by sam_lowry_ »

stickfigure wrote: post #265
sam_lowry_ wrote: post #255

Earlier quoted context omitted.

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

I was. But it wasn't quite as pointless as it sounds - the tool was a sort of tripwire-like system, with changes shipped to an append-only log, that itself was checkpointed in an early blockchain-ish structure. The threat model was "nation state actor" so the client wouldn't accept SHA1. It was actually a pretty cool system. I don't think it was ever sold though.

I do not remember jgit internals, but its API is pretty bad. I always assumed it was some kind of throwaway PoC suddenly turned popular.
Post reply on HN