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

211–220 of 490 posts

Re: Git undo: We can do better

#211

Post by MereInterest »

lisper wrote: post #48
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 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 don't yet know enough to say for certain.

Re: Git undo: We can do better

#212

Post by reacharavindh »

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…

+1.

I wonder if it is possible for someone to write a meta-CLI that works on top of git like “git for humans”. While, still leaving the power for expert users

Re: Git undo: We can do better

#213

Post by Izkata »

umvi wrote: post #192
chriswarbo wrote: post #175

Earlier quoted context omitted.

> It's a human problem If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? > 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before. SVN isn't distributed; it mos…

> If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? Because maybe mercurial's real problems wouldn't show up until people started using it at scale. This is a classic problem that happens time and again. Windows vs. Mac back in 2005: "Windows having malware is a human problem" "If it were a human problem, how could alternatives…

> Because maybe mercurial's real problems wouldn't show up until people started using it at scale.

I actually tried both git and mercurial almost a decade ago having had only experience with subversion, and found git to be much easier to understand and use. I don't recall what those pain points were, and am sure I couldn't describe them correctly if I did remember, but because of that I do expect such things to start popping up if more people used it.

Re: Git undo: We can do better

#215

Post by rjmunro »

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?

No, IMHO you are doing things right. I virtually never use those commands, I've been using git for well over 10 years, and have totally got used to all it's quirks.

Re: Git undo: We can do better

#216

Post by kahmeal »

urxvtcd wrote: post #135
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 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?

push causes the error, the resolving pull creates the merge; the correct resolution has been pointed out as git pull --rebase but most people don't realize this.

Re: Git undo: We can do better

#217

Post by capitainenemo »

umvi wrote: post #179
sedatk wrote: post #125

I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never find yourself in an unrecoverable situation. Advanced mutable features can only be accessed by making configuration changes, and are still safe to use because public changesets are differentiated from draft changesets, so, you can only make changes on your own w…

Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere

https://www.mercurial-scm.org/doc/evolution/user-guide.html#...

The key thing seems to be the immutable repo editing is hidden by default, but viewable with --hidden flag if you need it.

Re: Git undo: We can do better

#218

Post by [deleted] »

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…

[deleted]

Re: Git undo: We can do better

#219

Post by jonathanberger »

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 don't there's often at least some theory about what is going on (network effects, business partnership, government regulation, etc.) that I don't have with these two products.

Re: Git undo: We can do better

#220

Post by yarg »

alkonaut wrote: post #181

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like t…

There's a limitation to the DAG model that has bothered me for a long time.

I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch.

I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances.

(And I know this would create some new fun and games from a conflicts perspective, but I think it'd be worth it for any use case that involves long term maintenance of different releases of the same piece of software.)

Post reply on HN