41–50 of 237 posts
Just delete the directory and clone it again.
Even though I understand git really well it’s quicker to just blow it away and start again rather than accidentally make it worse realising you didn’t understand it as well as you thought you did.
Fortune favours the lazy.
For someone to get out of a mess they would have to know that they caused a mess in the first place! I'm starting to think trying to get people to use rebase and squash is a losing battle when they frequently just merge without pulling.
I got my team on side to use rebase/squash instead of blind merge commits after I showed them how much easier git bisect is to use when you have a linear commit history in your main branch. Now nobody wants to be 'that person' who breaks the bisect feature in case we urgently need it.
At least until someone does a foxtrot merge and then it never works again
My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels! You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the b…
My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels! You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the b…
Conceptualizing a commit graph with branch/tag labels is the easy part. What gets messy is operations regarding remote vs. local (as you mention) and regarding the various local state one may have (working directory, index/staging). Then there’s also the issues that arise with merging, but you have those with every VCS.
Is there an extension or something for Git to have similar behavior to this?
Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
If anyone is curious: git diff --cached is the same as git diff --staged. I don't know why they aliased them but I run git diff --cached very frequently and after seeing this post's reference to --staged I wondered what the difference was. Turns out there is no difference.
git branch NEWBRANCH
git checkout master
git revert —hard HEAD^
If you want to continue working on the new branch you do
git checkout NEWBRANCH
Earlier quoted context omitted.
Depends. Sometimes it's easier to tear down everything and start from scratch.
Isn't this what a `git reset --hard` does?
Also useful are git-fast-export and git-fast-import, if you really need to delve into the inner details of a commit. For example, I had three separate but related git repos that I needed to merge, so I created a new repo with separate branches to hold each repo, merged everything manually, committed that to a new branch, then used export/import to edit the commit to have the tips of the three other branches as its ancestors. Maybe there's a better way to do this with other git commands but I found it easier just to delve in and edit the commit data manually.
It is considerably more powerful than most teams need.