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

431–440 of 490 posts

Re: Git undo: We can do better

#431

Post by globular-toast »

meowface wrote: post #364
sedatk wrote: post #347

Earlier quoted context omitted.

How do people lose their work so easily with Git then?

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…

You should change the way you work with git. Commits are cheap. Really, really cheap. Commit all the time. Make "WIP" commits to remind you to squash them later. Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.

Re: Git undo: We can do better

#432

Post by lmm »

pjc50 wrote: post #320
nicoburns wrote: post #231

Earlier quoted context omitted.

I tend to default to `git pull --rebase`.

I have this configured as default everywhere and strongly believe that merge-pulls are always wrong. The first place I used git we were learning together (i.e. nobody knew what a sensible workflow was) and people would push their local merge commits back to master. It was horrible.

Strongly disagree. Never rewriting local commits is great for the same reasons that never rewriting published commits is great; if you rebase you lose the ability to fearlessly work on multiple branches in parallel that's the great advantage of git.

Pushing merges is great. Pushing random (unreviewed) local commits directly to master is bad, but it's no worse when those commits are merges than when they're not. Conversely, rebasing master (which is quite easy to do if you're inexperienced but have been advised to use git pull --rebase) and pushing that creates a self-perpetuating mess that is very hard to fix (because even if you fix what you did, any other user who did a rebase-pull of master in the meantime is going to reintroduce the problem). Using rebase also trains you to force-push which makes messing up published branches much easier.

Re: Git undo: We can do better

#433

Post by oblio »

OJFord wrote: post #319
oblio wrote: post #88

Earlier quoted context omitted.

That's a failing of Git. TortoiseSVN brought source control to millions of people. A good tool should be fully embeddable in a UI, 15 years after its launch.

Or a success of git? No good GUI exists because they realise they'd just be recreating things that exist, but with a GUI frame? If you wrote git 2.whatever from scratch would you structure rhe commands a bit differently? Yeah, sure, probably; but I always think these threads are way overblown. The common stuff that you use frequently.. well you use it frequently, so either you remember it as a result or you use the a…

> if you have to look it up in the excellent documentation, is that a failing

Yes, if we ever want version control to become mainstream.

Version control is a very practical, day to day concept.

It's just almost unusable for regular folks.

And regular folks for sure won't use CLIs (unless you point a gun to their heads).

Re: Git undo: We can do better

#434

Post by lmm »

mikepurvis wrote: post #289
stormbrew wrote: post #105

Earlier quoted context omitted.

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…

What's wrong with `git push -f`? When I'm working on a branch that's been previously pushed with `-u`, it's pretty normal to force push it, particularly if you're amending or reordering commits in response to review feedback, or rebasing due to conflicts in preparation to merge.

It means you can't fearlessly pull from other people's feature branches. So people mostly don't bother looking at each other's feature branches (because there's nothing you can reasonably do with someone else's change-in-progress except wait for the branch to hit master), so you collaborate later and end up with more conflicts.

Re: Git undo: We can do better

#435

Post by yarg »

leafmeal wrote: post #419
yarg wrote: post #281

Earlier quoted context omitted.

Not quite - branches get ancestors. A new repository starts with an empty branch. A DAG gets layered on top. I mentioned conflicts, but can you explain where race conditions would arise?

I guess I was imagining a conflict as the result of a race condition. Two concurrent changes are made where if they were ordered, there would be no conflict.

Ideally it should be no different to the current situation; you cannot push to a branch that has been pushed to since your last pull - the difference being that changes to the parent are also considered.

Re: Git undo: We can do better

#436

Post by lmm »

DangitBobby wrote: post #342
Nullabillity wrote: post #321

Earlier quoted context omitted.

For the sake of your coworkers (and your future self), please don't lie just to make your history look pretty.

I try to make each commit a snapshot of a working repository (compileable or runnable or testable, whatever is the heuristic for working) where the difference between each snapshot can be explained by the commit message. Ideally they are isolated to a single logical "unit" of change (fix, refactor, add, remove). The goal here being to minimize the amount of confusion and work for anyone traveling up and down the tree…

Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through commits on your feature branch. If you squash then your whole feature development becomes a single monster commit and I can't bisect through it.

I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.

Re: Git undo: We can do better

#437

Post by lmm »

MereInterest wrote: post #334
pjc50 wrote: post #322

Earlier quoted context omitted.

Wait, what? I've probably been using Gerrit too long but why do you ever need force in a rebase workflow?

These may be specific to a workflow with git + github, when using git from the command line, but here are the cases I've run into where overriding safeties is needed. 1. After making a PR, there are conflicts when merging into main. In a merge-based workflow, I would merge main into the feature branch, resolve any conflicts, then push. In a rebase-based workflow, I rebase the branch onto main, resolve any conflicts,…

> There are some cases where git can delete the branch safely, which I think occurs either when the feature branch has only a single commit, or when the feature branch can be applied on top of main without a rebase, but I haven't exactly determined it.

FWIW: it occurs when the feature branch was based on the tip of master (because no-one else has committed to master since you branched/since you rebased onto master) - in this case rebasing your feature branch onto master is a no-op and the commits that go into master have the same hashes as they had on your feature branch.

Re: Git undo: We can do better

#438

Post by lmm »

pjc50 wrote: post #324
lugged wrote: post #116

Earlier quoted context omitted.

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.

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.

> 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.

On the contrary, you want those commits for bisection, which is the main reason to have a VCS history at all.

> Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

People think they want that, but I've never seen a convincing case for why. Bisect works better if you use merge. Blame works better if you use merge. And if you really want to see the history without merges (why?), it's one flag to do that.

Re: Git undo: We can do better

#439

Post by alxndrr »

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.

Tower for Mac supports undoing (and redoing) all working tree actions like staging/unstaging/discarding individual chunks or complete files, undoing applying a stash, everything. Just hit CMD-Z. The feature is coming to Windows soon as well!

I am the CTO of Tower, a Git client for Mac and Windows.

Re: Git undo: We can do better

#440

Post by rjmunro »

29athrowaway wrote: post #205

There is a large graveyard of "simple git tools", many of them portray themselves as happy GUIs that prevent you from learning git... None of them works. At some point you will be told to fix the problem by hand.

This.

The tools that do work are ones that add a simple extra function (git absorb is really cool, for example), or GUIs that help you visualise the repository and give you buttons that have the same names as the command lines that they replicate. Tools that try to make things "easier" are just confusing for people who know git, and prevent you ever learning git for real. When I first tried it, github desktop was firmly in this category.

We need to get git itself to adopt some changes - git switch is a good start, replacing checkout's branch switching features. I think that every time I do git checkout branch I should get a reminder to use git switch instead.

Post reply on HN