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

Learn the workings of Git, not just the commands (2015)

developer.ibm.com

Post reply on HN
Print view View original

31–40 of 98 posts

Re: Learn the workings of Git, not just the commands (2015)

#31

Post by dahart »

erwincoumans wrote: post #15

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja…

> There is probably a proper command for it

Before you merge, the command is “git merge --abort”. After you merge, the command is “git reflog” to show your history, and then something like “git reset --hard HEAD@{1}” where the number in braces is the reflog entry you want to restore.

Reflog is the ultimate undo tool for work that’s been committed, it’s like having an infinite Ctrl-Z. If you use reflog to restore before your merge, you can even use it again to restore your mess, or to restore a different merge before the one you made a mess of.

The one thing you can’t recover using reflog is an accidentally dropped git stash. This is one reason I try to avoid stashes, and just use lots of one-off branches instead.

Re: Learn the workings of Git, not just the commands (2015)

#32

Post by balefrost »

altonen wrote: post #25
balefrost wrote: post #23

Earlier quoted context omitted.

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_b…

You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.

That's true! I personally prefer having a symbolic name for my backup, but the reflog is also very useful for "oops" moments.

Re: Learn the workings of Git, not just the commands (2015)

#34

Post by ethomson »

zibzab wrote: post #26
globular-toast wrote: post #18

Earlier quoted context omitted.

How to undo a change or revert to a previous version? That sounds like a pretty fundamental thing that a user would need to do, yes.

It is usually as easy as "git checkout ID". If that doesn't work you probably have done something really bad to begin with.

That's probably not what you want. Checking out an ID would put you in a detached HEAD state, and the CLI will give you the page of warning messages that go along with it. I think that this is an excellent reminder that yes, the git CLI is not simple or obvious.

Re: Learn the workings of Git, not just the commands (2015)

#35

Post by dragonwriter »

speed_spread wrote: post #6

Git's CLI is it's greatest weakness. Someone should really just scrap that part and rebuild it from scratch on sane ground.

> Git's CLI is it's greatest weakness

Git’s CLI is good as a unix-philosophy low-level tool that user-friendly tools can build on, and is a strength in supporting a wide range of different workflows.

It's suboptimal as a end-user tool for most workflows, but not bad enough for that people consistently build tooling rather than guides for particular workflows.

Re: Learn the workings of Git, not just the commands (2015)

#36

Post by trabant00 »

speed_spread wrote: post #6

Git's CLI is it's greatest weakness. Someone should really just scrap that part and rebuild it from scratch on sane ground.

For 20 years I keep hearing these types of complains about Git, Perl, GPG, etc. If you really need those tools than things like syntax, arguments and flags need a little time investment, but after a while they become second nature and you don't even think about them, but about the hard problem that is being made possible to solve by said tools.

These are not toys, one should not expect to just jump into them and start doing work like you would not just jump into a Boeing 747 and just take off, fly and land. It having 100s of buttons is not a weakness.

Re: Learn the workings of Git, not just the commands (2015)

#37

Post by dahart »

speed_spread wrote: post #6

Git's CLI is it's greatest weakness. Someone should really just scrap that part and rebuild it from scratch on sane ground.

And, unfortunately, the CLI is git’s greatest strength as well. Git was designed for the command line only truly flourishes there, for advanced workflows. The GUI tools that wrap git, and web interfaces like github, only provide access to a subset of what git can do.

It’d be interesting to see what a good redesign might look like. I do think some of the command names and command flags could be superficially updated/renamed/moved and provide a meaningful impact on git’s usability and learning curve. I’m curious though about whether the conceptual part of git is the primary source of difficulty, whether git is fundamentally a little hard to learn, because it’s fundamentally a little bit complex. If that’s the case, a rebuild might not help, there might not exist the kind of “sane ground” to build on that you hope for.

Re: Learn the workings of Git, not just the commands (2015)

#38

Post by icedchai »

balefrost wrote: post #23
erwincoumans wrote: post #15

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja…

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_b…

I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!

Re: Learn the workings of Git, not just the commands (2015)

#40

Post by karatinversion »

_dain_ wrote: post #13
pfarrell wrote: post #12

Earlier quoted context omitted.

Poe's Law is getting me on your comment. If it wasn't sarcasm, what's an example of a weakness? IMHO, there's a learning curve to using git and especially getting to the point where you can be your team's go-to person for git questions. However, I hold the opinion that of the many technologies out there, git is among those that is worth any investment you can make in learning it. Personally, long term use of git has…

quick: explain to me the difference between "git reset", "git revert" and "git restore", without looking up the docs.

Maybe you are newer to git, but this does not feel like a good faith comment, because “restore” is a command that was added specifically because people complained that the overloading of “checkout” is confusing.

Anyway: “reset” changes the ref to which the HEAD branch points, and depending on options can also update the index and working tree to match as well. “Revert” creates a commit that is the reverse of an earlier commit. Restore rolls back uncommitted changes to a file.

This isn’t hard?

Post reply on HN