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

71–80 of 98 posts

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

#71

Post by 5e92cb50239222b »

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

reflog saved me a few times, just remember that commits not referenced by a pointer (like HEAD or branch) can be GCed and disappear at any point. They are likely to be there right after a merge/rebase is finished, but may not be there anymore an hour later.

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

#72

Post by spookthesunset »

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

Hmmm....

    - reset: "blindly" load whatever commit you tell it into your working directory. This is the one if you add "--hard" will plow over your working directory in a way that cannot be undone. Actually I think without the "--hard" it won't make any changes to your working directory, it will treat whatever is in said directory as a change from the commit you told it to reset to. Dunno... have to look into it.

    - revert: Creates a new commit that undoes whatever commit you pass in.  Often times people mistakenly use this to "undo" a merge into a production branch that shouldn't have happened. The result is trouble when they want to push those changes back into production again.

    - restore: I have no clue what this does.
All I really know is "--hard" is one of like two commands that you can do in git that you can't back out of. "git clean" is another one (I think).

Yeah... conceptually Git is kinda easy but the command line is pretty nuts.

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

#73

Post by housecarpenter »

globular-toast wrote: post #54
dec0dedab0de wrote: post #46

Earlier quoted context omitted.

Are you really shocked that someone would make a backup before doing something they are unsure of? Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.

> Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être . If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is f…

It's entirely possible to trust something to work one way (e.g. keep a trivially restorable backup of previous state) when you do one thing with it and not trust it to do the same thing when you do another thing with it (especially if it's something you do infrequently or have never done before). The advantage of cp compared to git is that it only does one thing (more or less), so you don't have the potential for "doing things you're unsure of" in the same way as git.

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

#74

Post by dec0dedab0de »

globular-toast wrote: post #54
dec0dedab0de wrote: post #46

Earlier quoted context omitted.

Are you really shocked that someone would make a backup before doing something they are unsure of? Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.

> Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être . If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is f…

Backups and version history are not the same thing. Especially when you're messing with the version history. I make copies when I'm using git-filter-repo, or BFG. But even rebase is a destructive action that would be nice to have a safety net for.

In the real world people have a ton of untracked files for their development environment, and uncommitted changes, but need an update from a coworkers branch that has a conflict with development, and a different conflict with your local changes. This can leave you in a weird state pretty quickly, and merge conflicts are a pain, especially if the conflicts are in a part of the code you're not very familiar with. Personally, I go full cowboy and work my way through it, but I am not surprised in the least when I hear that people make a backup so they can quickly restore.

One benefit of copying a directory instead of using git is that it will copy all of your untracked files, and uncommitted changes as is. Another benefit is that it works the same no matter what tooling you're using. I believe that some legacy code at my company is still on SVN and source safe. I also use open source projects that are developed with mercurial, bazaar, and fossil. If I were going to work on any of them, I would definitely be making backups the standard way instead of trusting my ability to use the tool properly.

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

#75

Post by cryptonector »

enriquto wrote: post #56

As much as I love and depend on git, the visible user interface seems a bit ugly. You can get used to it over time, but it has a certain non-unix flavor that I dislike... There should be a purely unix way to use git, as in "everything is a file". Sure, you can go to the .git folder and there are files in there. But the structure of these files does not directly represent the structure of the repository. What I want i…

> A disturbing feature that I don't see a way out is that in git there are "standard" and "history-rewriting" operations, and there is a clear distinction between the two. To what would that correspond in terms of pure file operations? Something about changing the default permissions?

> "history-rewriting" operations

Git is a Merkle hash tree. You can never rewrite history. Instead, what you think of as "history-rewriting" operations is just "non-fast-forward" changes to branches. Branches are really just named pointers -- {branch_name, commit_hash}. A change to branch from {$name, $commit0} to {$name, $commit1} is fast-forward IFF $commit0 appears in the linear history of $commit1. A non-fast-forward change to a branch is what you call a "history-rewriting" operation.

There's nothing wrong with "history-rewriting" -- I do it all the time. It's only ever bad when you do a non-fast-forward push to a branch that others track, and even then it's not the end of the world because usually those others can recover easily enough with `git rebase --onto`. Rewriting the history of a public branch is a problem, yes, because you want the history to be stable and reliable so you can use it to figure out problems, understand the history of the project, etc, and because making others have to `git rebase --onto` is impolite.

It's essential to understand that the only destructive operations in git are a) non-fast-forward branch changes, b) tag changes, c) gc/prune operations when you're like me and you're used to working in detached-HEAD mode.

If you're stuck on "Git has history rewriting, and that's bad!", then you've misunderstood everything about modern version control systems. You can -and I have- do the same sorts of destructive operations in version control systems going back to the early 90s (e.g., Teamware, CVS), to say nothing of newer ones like Mercurial, Fossil, and, of course, Git.

Inb4 "But Git encourages history rewriting" -- that is neither true nor a good argument.

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

#76

Post by giraffe_lady »

karatinversion wrote: post #40
_dain_ wrote: post #13

Earlier quoted context omitted.

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 earli…

What definition of hard are you using? It's an industrial strength tool used almost exclusively by professionals and expert-level amateurs. It's definitely hard, the same way knowing what to do with a welding machine is hard.

On the other hand, even among the professionals it has a reputation for being tricky and frustrating. Which is not the norm for most critical daily-use tools in this or any professional. So I'd also consider it hard in that sense.

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

#77

Post by cryptonector »

globular-toast wrote: post #29
DarkWiiPlayer wrote: post #9

The important thing to understand is that git is a blockchain

It goes a lot further than just being a blockchain. Git is a DAG through and through. But this might actually be the best way to make some people understand it. I was gobsmacked one day when a colleague came into work and they were really excited as they'd realised git is actually a blockchain. I was stunned as it seemed so obvious, but if they only just realised then how had we been working successfully with git for…

A blockchain is one linear branch. Git is just a tree of them, but they're all blockchains.

The only other extremely important thing to understand about Git is that it has a way to name commits symbolically (branches and tags), and that those names can be changed, and that leads to understanding what a fast-forward and non-fast-forward change to a branch really is.

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

#78

Post by dogleash »

zibzab wrote: post #16
throw0101a wrote: post #3

It's been over a decade and I still find this joke amusing: > @wilshipley git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 (It's a 'spoof' on the Monad joke.)

Why does any post discussing _any_ aspect of git always results in these type of comments? "git is complex", "git command line is confusing me", "life would be easier is we all used subversion". Please let us discuss git in peace. (Although I admit that this one was funny)

>Why...

Because lots of people don't want to learn git. They want to bungle through it the same way they bungle through most of the software they touch. People who work with software professionally are very adept at bungling. Even through complicated professional software that other users would need training for. But git is resistant. Even rote memorization won't let you hide completely from learning git. There's a steep learning curve before you can half-ass it.

Depending on perspective this is either a damning indictment of git, or just another day at the office.

I've been helping people learn git for over a decade now. Unironically the easiest to teach are interns.

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

#80

Post by dogleash »

enriquto wrote: post #56

As much as I love and depend on git, the visible user interface seems a bit ugly. You can get used to it over time, but it has a certain non-unix flavor that I dislike... There should be a purely unix way to use git, as in "everything is a file". Sure, you can go to the .git folder and there are files in there. But the structure of these files does not directly represent the structure of the repository. What I want i…

> What I want is to "mount" a git repository, [...] Would that even be possible?

Yeah, sure, why not? You could do it with fuse http://libfuse.github.io/doxygen/ There's even a git fuse filesystem already out there. I dunno if it works the way you want though.

Post reply on HN