51–60 of 275 posts
Git is one of those technologies that I never got to wrap my head around of, because in so many ways it doesn't follow intuition and unless you have been using it for a long time, for literally every action you would probably have to Google or use the man page of the command.
As everyone knows, though, Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…
The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…
One of the beauties of Git is that as long as you’ve created an object, it’s impossible to lose that work (short of nuking the .git directory). Committing often is key. Precommit hooks (that take more than ~100ms) go against that.
Yeah, please don't create sites like this. Just... don't. Any, and I mean any "in case of a Git problem, just do this " recipe is wrong , often in very subtle ways. So, my advice: in case of a Git problem, contact the help channel provided by the organization hosting your Git repository. They'll help you out! And if it's your personal-I-am-truly-the-only-human-using-this repository? Just recreate it, and save yoursel…
Oh no, that poor soul...
Earlier quoted context omitted.
I guess we're coming from different places. In my vernacular, ending a comment with "...really?" is about as casual as calling somebody bro. It's gender neutral btw.
"Bro" is the furthest thing from "gender neutral". Not sure how you could think it's gender neutral. It originated from male behavior and is definitely not gender neutral. You can address women as "bro" and they might even respond to you but they'll think you're absolutely weird.
Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…
The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…
There isn't one tree of commits, there are typically at least two: local and remote
Branches are not just pointers to commits, but also possibly related to pointers in the other tree via tracking.
Stash and index and the actual contents of the working directory are additional data that live outside the tree of commits. When op says "avoid git reset hard" it's because of how all these interact.
Files can be tracked, untracked and ignored not ignored. All four combinations are possible.
Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…
The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…
Earlier quoted context omitted.
The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…
The "move a branch from one commit to another without changing anything" command is "git reset". "git reset --hard" is "...and also change all the files in the working directory to match the new branch commit". "git reset --soft" is "...but leave the working directory alone".
[1] https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.
git merge origin/master
git reset origin/master
git commit -am "squash" # might need some extra fixup if your branch has added files