Live data from Hacker News

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

developer.ibm.com

51–60 of 98 posts

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

#51

In my experience it is fine to first learn only some required commands. One will run into cases, where ones understanding or imagination of how git works will not work any longer. In such cases one can still read up on how it works and build a new working understanding. Only important to not always just shrug, delete the repo and clone again. That will not really facilitate learning. Of course no one is stopping anyo…

This usually leads to "my shit's due in an hour, my repo is totally broken and I have no idea why... HEEEEELP".

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

#52

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

> git branch blah_branch_backup

Don’t forget to commit your changes if you’re going to `reset --hard` later!

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

#53

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

You mean like: https://gitless.com

Or my own project: https://github.com/martinvonz/jj.

I think https://github.com/Byron/gitoxide also plans to provide a different CLI, but I don't think they've started working on it.

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

#54

Earlier quoted context omitted.

"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?

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 for and why do you use it? This would help me enormously to understand where you are coming from.

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

#55
post #13

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.

Don’t forget rebase if we are doing this.

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

#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 is to "mount" a git repository, so that I can explore its contents using cd, ls and cat. Also, by editing these files I implicitly make commits and create branches to the underlying structure. Would that even be possible?

EDIT: 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?

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

#57

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…

Git is a popular distributed versioning tool, but some commands have obscure syntax that is easy to get wrong, leading you into a mess that becomes a time drain. Creating a zip file of a git root folder takes seconds, and can get you out of the mess in seconds, rather than spending minutes or hours to undo some mess. If you can foresee git getting into a mess (and I can, after > 10 years of git experience), you can just take that backup to save time 'just in case' your git repo gets into that mess again.

Changing the git commit history (for example because you made a commit under the wrong name/email address) in particular can cause huge headaches.

Doing a git merge with tons of changes (think of clang-format white space changes in combination with various other commits) is another one.

This is not about the specific cases where your git repo can become a mess, but more about having a simple safety mechanism to always get you out of the mess.

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

#58

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…

> 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 for and why do you use it? This would help me enormously to understand where you are coming from.

All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve.

I also understand git fear - some of the stuff is a little arcane, and organizations are often very dogmatic and loud about their usage and approaches to git. It leads to a lot of gatekeeping. Do we rebase here? Do we never rebase? Linear history? Rebase feature branches or merge directly into main? It makes the fear of the tool that much stronger.

`cp`, on the other hand, is pretty straightforward. There are no local approaches to using it, there's no real `cp` expert in-house at most places. It does what it says on the box without a lot of frills or options.

git is a complex tool. It becomes easier the longer you use it, like most things, but it can be very intimidating to new or intermediate users.

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

#60

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…

If I might offer a suggestion, instead of using various git commands, you want to be able to just cp a folder to a mounted git folder, and echo the commit message to a .commitmsg in that folder, or something like that, right?
Post reply on HN