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

31–40 of 84 posts

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

#31

Post by maksimum »

Stratoscope wrote: post #29
godot wrote: post #27

I'm actually somewhat surprised that this wasn't mentioned in the comments yet: https://ohshitgit.com/ Which is a page that covers common mistakes using git and quick ways to fix your mistakes. I've found myself making a mistake mentioned on this page with regularity and always refer to the site to help myself fix it quickly. (It looks like they have a swearing-safe version now at https://dangitgit.com/ )

If you have to use the command line, those "gosh darn it git" sites have some good recipes. Because if the problem is "I accidentally committed to the wrong branch!" who is going to remember all this off the top of their head: # undo the last commit, but leave the changes available git reset HEAD~ --soft git stash # move to the correct branch git checkout name-of-the-correct-branch git stash pop git add . # or add in…

> It works in conjunction with the command line

Do you know of git GUIs that explicitly maintain a bijection between the GUI and the underlying command history? It'd be cool to use the GUI and see the command history, or use the CLI and see updates in the GUI.

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

#32

Post by onekorg »

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/19/the-git-parable.htm...

To understand the data structures I suggest: https://codewords.recurse.com/issues/two/git-from-the-inside...

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

#33

Post by Stratoscope »

maksimum wrote: post #31
Stratoscope wrote: post #29

Earlier quoted context omitted.

If you have to use the command line, those "gosh darn it git" sites have some good recipes. Because if the problem is "I accidentally committed to the wrong branch!" who is going to remember all this off the top of their head: # undo the last commit, but leave the changes available git reset HEAD~ --soft git stash # move to the correct branch git checkout name-of-the-correct-branch git stash pop git add . # or add in…

> It works in conjunction with the command line Do you know of git GUIs that explicitly maintain a bijection between the GUI and the underlying command history? It'd be cool to use the GUI and see the command history, or use the CLI and see updates in the GUI.

I'm not sure if this is exactly what you're looking for, but maybe close? SmartGit has an Output window that shows the underlying Git commands that it uses when you drag things around or use its commands. And if you make changes in the command line and then switch back to the SmartGit window, it updates to match.

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

#34

Post by thefunnyman »

kbenson wrote: post #17

This flowchart[1] has been useful to me a few times when I've been lost on how to fix something. I usually keep it as a bookmark, but I don't have it saved on this computer, so I just did a google image search and was able to fine it fairly quickly. A google image search for "git solution workflow" or "git fix flowchart" finds it right away, in case this tickles your brain in the future and you want to find it again,…

Why does the rebase command here include the --force flag? I don't think it's necessary.

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

#35

Post by maksimum »

lpghatguy wrote: post #11
chrisweekly wrote: post #8

Earlier quoted context omitted.

PSA: You can safely refer to those long "commit-ish" identifiers using just the first 7 or 8 chars (eg `88113a64`) without real risk of collision. Let alone in examples / gists!

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

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

#36

Post by quleap »

Pinckney wrote: post #22
coryrc wrote: post #18

Earlier quoted context omitted.

I'm not that poster, but Mercurial is just as powerful and much easier to use.

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…

You surely don't know much about Mercurial.

"purge" has NOTHING to do with commits. "purge" only removes file not tracked by Mercurial.

"graft" replaced "transplant".

"graft" copies commits while "rebase" moves commits.

These commands all have very clear purposes, unlike those in Git.

It's just that you haven't really bothered to spend a few minutes on learning them.

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

#37

Post by mixmastamyk »

Pinckney wrote: post #22
coryrc wrote: post #18

Earlier quoted context omitted.

I'm not that poster, but Mercurial is just as powerful and much easier to use.

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…

I don’t do any of the things you describe.

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

#38

Post by nneonneo »

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 expect - what branch you’re on, if you’re even on a branch, what merge/rebase/commit operation you’re in the middle of (if any), and even how to go forward with or back out of the current operation.

Finally, commit regularly and often! reflog and rebase mean that you can always maintain a clean history if you want, while committing makes sure that your changes are properly tracked and saved by git so you can rewind when needed. Once you get comfortable with it, git lets you really practice fearless experimentation, which unlocked a whole new level of productivity for me.

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

#39

Post by pjtr »

Pinckney wrote: post #22
coryrc wrote: post #18

Earlier quoted context omitted.

I'm not that poster, but Mercurial is just as powerful and much easier to use.

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…

Fortunately "transplant" is just an old extension, so you can just forget entirely about it.

"Graft" copies; "Rebase" moves.

Alternatively just forget about graft also, and use "rebase --keep" to copy.

"Rebase with evolve" is conceptually still rebase.

Mercurial has strip (removes changesets from repository, by default stores a backup). Mercurial does not have purge.

Evolve has ~purge~ prune (marks changesets as obsolete).

Evolve is similar to a git reflog.

Evolve stores more contextual information than the reflog, so Mercurial+Evolve it is safer and easier to undo things than in Git+reflog. Mercurial also pushes some of this contextual information, so even collaborative history rewriting is possible in a safe and easy way, unlike git.

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

#40

Post by pjtr »

quleap wrote: post #36
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…

You surely don't know much about Mercurial. "purge" has NOTHING to do with commits. "purge" only removes file not tracked by Mercurial. "graft" replaced "transplant". "graft" copies commits while "rebase" moves commits. These commands all have very clear purposes, unlike those in Git. It's just that you haven't really bothered to spend a few minutes on learning them.

purge is a third-party extension; it removes untracked files as you wrote.

But ~purge~ prune is also a command of the evolve extension, that is conceptually similar to strip, as GP wrote.

Post reply on HN