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".
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.
Life being easier... maybe, I'm sure it would be for most projects. For some where git is required, likely not. I'd reckon MOST projects don't really need a DVCS; they have the much easier mental model and work quite well with a centralized "source of truth" that people can take from or give code to (coughgithubcough)
If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.
I like the attitude of "learn the principles of the simple building blocks behind it" as a good next step from a freshman that just memorized "add, commit & pull/push"
But most headache (and heartattack) inducing part of Git when I was a beginner was the "remote vs local repo" and additional complexities this concept introduced. Nothing more stressing for the new guy than making mistakes that screw up for others (mistakeful push, merge, mostly ) or if he think he did.
The article does a poor job (imo) regarding this. It skims on a 2 paragraph "Caveat" section how rebase(and later squeeze) can fuck local vs remote repo, but for most people I know, stress memories around this is what made them learn more about Git beyond than "branch & history keeping software & commands.
That and if you unfortunately end up in a project that uses subtree or submodules
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.
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.
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 affected the way I code to bring more intention and organization to what I'm doing.
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.
Understanding what git is doing under the hood did more for my ability to use it effectively than it did for most tools.
That said, this document in particular does not seem to be a very good way to get that understanding, it's a very "IBM documentation" way of presenting git. I wish I remembered what I read, because it's was a much easier read.
Perhaps it was Pro Git's chapter 10: Git Internals(1)? I once used it as a guide when writing a basic 'git inspection' tool and definitely found the whole experience useful for getting a better understanding of Git.
Maybe the git man pages? Iirc the man pages have 2 or 3 'getting started' documents that really made me feel confident. Then I didn't use it for two years and now it's real fuzzy again.
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 anyone interested in it from reading more about how it works up front.
"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 and don't want to loose any work. There is probably proper command for it, but I sometimes get into a git mess that I cannot get out of. (reading stack overflow, trying get reset, git checkout, git reset --hard and so on)
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_branch_backup.
This same pattern is useful for other dangerous commands, like rebases or filter-branch.
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}.
Thanks, I should have been mote precise in my post. I meant, I zip repo root folder before a complex git operation (certainly not before every single merge).
One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla) Changing the email of an existing commit messed up my repo beyond repair. This is just one example from memory, it happens infrequently luckily. Thanks for the git tips :)
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.
I'm the same - although I've had many experiences in the past where I avoided the time-saving tools because they were too complex in the moment and then kicked myself later on when I realized just how much time I had been wasting by avoiding spending ten minutes learning the time saving tools, every time I try to do a git merge "the right way", I end up with conflicts that shouldn't be conflicts and changes that I didn't want to pull in that I have to manually undo until I just give up and "manually" merge.
"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?
Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.
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.
Readit News
> @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.)
For example, ```git-dissect-tipdissects indexed local tips from all noted downstream upstreams, remotes commit graphs, etc.```
Anytime somebody is confused or stuck with Git, it's a great idea to helpfully send them some documentation links from there.
Please let us discuss git in peace.
(Although I admit that this one was funny)
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.
Because it is.
> "git command line is confusing me"
Because it does.
Life being easier... maybe, I'm sure it would be for most projects. For some where git is required, likely not. I'd reckon MOST projects don't really need a DVCS; they have the much easier mental model and work quite well with a centralized "source of truth" that people can take from or give code to (coughgithubcough)
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
It is surprisingly simple and efficient. I am starting to think this Linus guy knows what he is doing.
If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.
Holy shit, yes.
`git branch` in gitspeak really means `git branch list` in human-readable CLI
But `git branch ${NAME}` does not mean `git branch list ${NAME}`, instead it means `git branch create ${NAME}`
There is no `git branch switch ${NAME}` but instead it's `git checkout ${NAME}`
There is no `git branch log` – that would be `git log`, whereas if you want what should be `git log` what you really want is `git log --all`
Don't get me started on whether modified files are added, staged, or indexed...
https://github.com/pluralsight/git-internals-pdf/releases
But most headache (and heartattack) inducing part of Git when I was a beginner was the "remote vs local repo" and additional complexities this concept introduced. Nothing more stressing for the new guy than making mistakes that screw up for others (mistakeful push, merge, mostly ) or if he think he did.
The article does a poor job (imo) regarding this. It skims on a 2 paragraph "Caveat" section how rebase(and later squeeze) can fuck local vs remote repo, but for most people I know, stress memories around this is what made them learn more about Git beyond than "branch & history keeping software & commands.
That and if you unfortunately end up in a project that uses subtree or submodules
Like LOTR, everyone has more than one name.
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.
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.
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.
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.
That said, this document in particular does not seem to be a very good way to get that understanding, it's a very "IBM documentation" way of presenting git. I wish I remembered what I read, because it's was a much easier read.
1) https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
Of course no one is stopping anyone interested in it from reading more about how it works up front.
I must admit that I'm at the point where I shrug, delete and clone the repo if I'm stuck. Some errors and messages were to cryptic to me.
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 and don't want to loose any work. There is probably proper command for it, but I sometimes get into a git mess that I cannot get out of. (reading stack overflow, trying get reset, git checkout, git reset --hard and so on)
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_branch_backup.
This same pattern is useful for other dangerous commands, like rebases or filter-branch.
When you're done, just delete blah_branch_backup.
One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla) Changing the email of an existing commit messed up my repo beyond repair. This is just one example from memory, it happens infrequently luckily. Thanks for the git tips :)
Don’t forget to commit your changes if you’re going to `reset --hard` later!
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.
Could you tell me what you think git is for and why you use it?
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.
Maybe it's not your intent, but you're coming off as a bit of a git yourself. He lacks your confidence.
Deleted Comment