Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to undo almost anything with Git (2015)

github.blog

Post reply on HN
Print view View original

71–80 of 84 posts

Re: How to undo almost anything with Git (2015)

#71

Post by tomxor »

onekorg wrote: post #32

The thing that made git click for me was to understand the data structures that make git work. There's beauty and elegance in the implementation details of git. You can do and undo with confidence once you can translate the changes you want to make to git object transformations. To get an overview of the concepts behind git I recommend this article by one of the GitHub founders: http://tom.preston-werner.com/2009/05/…

> The thing that made git click for me was to understand the data structures that make git work.

I cannot agree with this more! The data structure makes git git, there are some questionable CLI design choices but they all melt away once you get the data structure.

In relation to trying to manipulate commits and "undoing things", everything will be significantly clearer the faster you can move away from thinking of undo like a one dimensional word processor function... Instead start to think of git as an immutable graph of commit objects you are able to traverse, reference and use in anyway - at that point "undo" seems like a completely inadequate description.

Re: How to undo almost anything with Git (2015)

#72

Post by jzwinck »

nneonneo wrote: post #38

Also worth noting: you can abort and undo many kinds of in-progress operations with “git —abort”. Works for merge, rebase, and a few other things, and can seriously save your bacon when you do a “git merge ” and are suddenly confronted with a bazillion merge conflicts. Also, if you’re in a panic because something went screwy, check “git status” and read every line carefully. status tells you a lot more than you might…

Weirdly there is no "git stash pop --abort" to roll back when a merge conflict occurs during stash pop.

Re: How to undo almost anything with Git (2015)

#73

Post by mikestew »

maksimum wrote: post #35
lpghatguy wrote: post #11

Earlier quoted context omitted.

Git will even warn you if the hash prefix you provide is ambiguous! I had a collision the other day on a mediums-sized when using a 6 character hash and was surprised. Git let me know and told me which objects collided.

Wow, that's super unlikely. How many commits did the repo have? According to [1] using 3 letters you'd need at least 72 commits to have at least 50% chance to observe a clash. Using 6 letters you'd need at least 3977 commits, lol. [1] https://en.wikipedia.org/wiki/Birthday_problem#The_generaliz...

I’ve been using git for going on ten years. You don’t think I can pull off just one commit/day?

I use six character hashes, I don’t recall that I’ve had a collision yet. But I guess I’m “due”. :-)

Re: How to undo almost anything with Git (2015)

#74

Post by Doxin »

tduberne wrote: post #63
Doxin wrote: post #48

Earlier quoted context omitted.

> check “git status” and read every line carefully. Seconded, but I'd go even further. Run and read git status before and after running any git command until you get comfortable enough with git to where you can predict the output without running it. Additionally you can go get git prompt[1] installed so you always know your git status at a glance. Saves a lot of typing in any case. As a last suggestion I'd say go rea…

I totally second reading the book front to back. It is not that long and fairly well written, and can save so much time and frustration in the long run. Giving the link is the first thing I do when helping someone with git. Unfortunately so many people put that aside and never read it, and then come back to me a few weeks later because they messed everything up again, and still do not understand what I mean with "ind…

I don't even think git is all that awkward. It's incredibly elegant but that also makes it somewhat orthogonal compared to how you're used to think about stuff.

I dunno, git is probably one of the few instances where I feel like RTFM is a valid remark.

Re: How to undo almost anything with Git (2015)

#75

Post by SlowRobotAhead »

godot wrote: post #24
SlowRobotAhead wrote: post #23

> You started a new branch feature based on master, but master was pretty far behind origin/master I’m bad at git. So... wait what now? When is Master not Origin/Master? I don’t understand what is going on there. Explain?

It means your local master is behind remote origin/master. (i.e. you needed to git pull)

OHH... ok! That makes sense. My last two projects I’ve been the only one committing so this pretty much can’t happen. Thanks.

Re: How to undo almost anything with Git (2015)

#76

Post by 3pt14159 »

sadjad wrote: post #12
stouset wrote: post #10

Earlier quoted context omitted.

Wait, seriously? I sign all my commits as habit and I `--amend` regularly. If this means my signature histories are broken…

git config commit.gpgsign true

This is great! Thanks! I'll use the global setting:

    git config --global commit.gpgsign true

Re: How to undo almost anything with Git (2015)

#77

Post by Pinckney »

alwillis wrote: post #69
Pinckney wrote: post #22

Earlier quoted context omitted.

That's what everyone says, but for me, coming from a rebase heavy git workflow, I've found Mercurial far more difficult to learn. For example, with Mercurial, there's at least four different ways to do a rebase-ish thing: transplant, graft, rebase, and rebase (w/ evolve enabled). It's not obvious which a newbie should pick (rebase+evolve... I think?). Likewise, Mercurial has purge and strip which both delete commits…

For example, with Mercurial, there's at least four different ways to do a rebase-ish thing: transplant, graft, rebase, and rebase (w/ evolve enabled). It's not obvious which a newbie should pick (rebase+evolve... I think?). You're cherrypicking--no pun intended. By default, Mercurial doesn't do any of these operations; you have to activate extensions. If I were a newbie coming from Git and I wanted a similar workflow…

> By default, Mercurial doesn't do any of these operations; you have to activate extensions.

graft is actually built-in, but that's beside the point. Coming from a rebase heavy workflow in git, things like updating a ref or abandoning a commit feel like fundamental operations, and when moving to Mercurial it wasn't obvious which of the built-ins or bundled extensions I needed to be reading about to do these things.

I did eventually find Evolve, as you suggest, but it's not one of the bundled extensions, and it's not something you'll find in the official tutorial, or "The Definitive Guide", or even in most of the SO answers explaining how to do git-like things.

> By design, Mercurial makes it much harder to shoot yourself in the foot.

This is true, but git makes it so easy to recover from those mistakes.

Re: How to undo almost anything with Git (2015)

#78

Post by karmakaze »

DaiPlusPlus wrote: post #30
karmakaze wrote: post #28

Earlier quoted context omitted.

Git shouldn't take months to master if you can understand it conceptually rather than by use-cases. If instead of trying to learn commands to affect the working directory, staged files, or history, you learn how git organizes historical tree of commit hashes, then base what each operation does, it becomes much clearer. It's similar to trying to learn strings of shell pipe commands to get things done rather than reali…

git’s problem to newcomers - even people without any prior experience with diff-paradigm systems like SVN and TFS - is the idea of a commit representing a snapshot of a file system is difficult to comprehend because it feels so crazy and impractical (especially as CS101 makes a huge deal about computational complexity). The fact that git internally is actually quite efficient is buried in heavy articles about git’s p…

It makes complete sense for programmers learning git to also learn some relevant underpinnings of what git is doing (not necessarily how it achieves it so efficiently). That is a much quicker route than having users guess at similarities with things they've used or imagine while using it and being surprised with it veers off expectations.

Re: How to undo almost anything with Git (2015)

#79

Post by DaiPlusPlus »

webreac wrote: post #45
DaiPlusPlus wrote: post #30

Earlier quoted context omitted.

git’s problem to newcomers - even people without any prior experience with diff-paradigm systems like SVN and TFS - is the idea of a commit representing a snapshot of a file system is difficult to comprehend because it feels so crazy and impractical (especially as CS101 makes a huge deal about computational complexity). The fact that git internally is actually quite efficient is buried in heavy articles about git’s p…

IMHO, the main idea of git is immutability. See the following comparison of git and synergy in a migration study. https://github.com/24eme/eurocontrol_synergy2git/blob/master... The git description is far shorter, but also more complete.

In practice, git isn't immutable - people rebase their commits after pushing, or go back in time to remove a file that shouldn't have been there and reindex, and so on.

Re: How to undo almost anything with Git (2015)

#80

Post by jki275 »

thinkingemote wrote: post #51
DaiPlusPlus wrote: post #30

Earlier quoted context omitted.

git’s problem to newcomers - even people without any prior experience with diff-paradigm systems like SVN and TFS - is the idea of a commit representing a snapshot of a file system is difficult to comprehend because it feels so crazy and impractical (especially as CS101 makes a huge deal about computational complexity). The fact that git internally is actually quite efficient is buried in heavy articles about git’s p…

When I used to use NetBeans the main feature I loved was the history feature. Basically every save to every file was stored and diffable in a kind of self contained repo. I've missed this feature in every other editor since.

NetBeans is a wonderful IDE for this reason.
Post reply on HN