This is completely unnecessary. I've been able to fix every mistake I've seen in the last 5 years with variations of git diff, git branch, git merge, git reset and git rebase and their options, and I've seen some horrific doozies from newbs and pros.
Git undo: We can do better
341–350 of 490 posts
Re: Git undo: We can do better
#342Earlier quoted context omitted.
> 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…
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. I often have to rewrite my local history to make this happen, because the actual changes that I make can happen in a somewhat arbitrary order. How has local history revision bitten you?
Re: Git undo: We can do better
#343Earlier 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…
Yep I love the git GUI in Jetbrains IDEs, especially the change lists and shelf based workflow. I also like using the IDE’s diff to quickly use parts of an old shelved patch or when I’m working through a book I can diff my project with the answer repo to quickly see and work through the differences. But my favorite feature is Local History which has saved me from many overzealous git disasters: https://www.jetbrains.com/help/webstorm/local-history.html
Basically the IDE has its own revision history of your project’s files that it stores and you can recover your files from it. So when you accidentally revert instead of undo or use —-hard when you didn’t really mean to, Local History comes and saves the day.
Re: Git undo: We can do better
#344Damn, 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 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…
I think it's because the commands are poorly named. "Reset" vs. "Revert" tells me nothing about what is happening at the low level, I just have to remember it. And yet the two operations, despite having fairly similar English language meanings, have entirely different meanings in the context of Git.
Re: Git undo: We can do better
#345Earlier 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.
Ultimately, I suppose, git usage is somewhat cultural. I personally have an aversion to push -f, along the premise that once it’s pushed it’s public and someone else may have branched (and pushed changes of their own) or simply had it checked out for review; doing push -f “changes reality,” while checking out a new branch is idempotent. If someone else has committed on that branch it’s especially jerky to push -f.
I try to be pragmatic about this sort of thing yet push —force is one of those cultural no-no’s for me.
Re: Git undo: We can do better
#346I 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
Eh, some may call it noise, some may call it "thank God my work is saved!". That only applies to pushed changesets btw, may I remind you. You can obviously remove/restructure local commits as you like; you just need to enable certain extensions for mutability.
Re: Git undo: We can do better
#347I 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…
Git is immutable. The only thing that isn't is your working directory.
How do people lose their work so easily with Git then?
Re: Git undo: We can do better
#348Damn, 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 suggest to try this:
www.pluralsight.com/courses/how-git-works.
It covers the fundamentals behind git but without the usual 'nose up in the sky attitude and elitism' that could be seen in many books or articles about it.
Re: Git undo: We can do better
#349Earlier 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…
For non-native speakers it's much more obvious how to pronounce mercurial than git. Mercurial can only be pronounced like mercury, I guess, is there any other sensible choice? But in git, it's not obvious if the g is pronounced as in get or as in gin until you look it up.
Re: Git undo: We can do better
#350Earlier 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…
so the distinction here is
- origin master - origin/master <=== a local branch that you cached from the "origin master" remote, may or may not be in sync with the real "origin master"