21–30 of 84 posts
Git is one of those once-a-decade technologies that's compicated, user un-friendly, takes months to master and is absolutely worth it.
Earlier quoted context omitted.
Curious, what do you currently use for version control?
I'm not that poster, but Mercurial is just as powerful and much easier to use.
For example, with Mercurial, there's at least four different ways to do a rebase-ish thing: transplant, graft, rebase, and rebase (w/ evolve enabled). It's not obvious which a newbie should pick (rebase+evolve... I think?). Likewise, Mercurial has purge and strip which both delete commits in different ways. Git has multiple ways to do the same thing, but at least it's simple and consistent when you lift the hood.
Undoing any sort of rebase-ish operation in Mercurial also seems difficult and janky. It seems to take multiple steps, and involves unbundling some sort of patch file stored underneath your home directory. Whereas in git, you just update a pointer: `git reset --hard $BRANCH@{1}`. Git's reflog is such a fantastic safety net. Doing any sort of history rewriting in Mercurial feels very dangerous, in comparison.
I’m bad at git. So... wait what now?
When is Master not Origin/Master? I don’t understand what is going on there. Explain?
> You started a new branch feature based on master, but master was pretty far behind origin/master I’m bad at git. So... wait what now? When is Master not Origin/Master? I don’t understand what is going on there. Explain?
> You started a new branch feature based on master, but master was pretty far behind origin/master I’m bad at git. So... wait what now? When is Master not Origin/Master? I don’t understand what is going on there. Explain?
For several months now I've been wondering how to get rid of a 700 MB data file that was accidentally committed to our shared git repo. Now everyone has it, and a clean pull takes forever. Appreciate any thoughts.
You should be able to run a command that cleans the git tree of the file in all commits. I’ve had to do it because of committed passwords in files. https://stackoverflow.com/questions/35115585/remove-file-fro...
(It looks like they have a swearing-safe version now at https://dangitgit.com/)
Git is one of those once-a-decade technologies that's compicated, user un-friendly, takes months to master and is absolutely worth it.
For me, I had trouble first using `git` after experience with `cvs` and `subversion`. At some point, everything clicked because I inferred its internal model.
I'm actually somewhat surprised that this wasn't mentioned in the comments yet: https://ohshitgit.com/ Which is a page that covers common mistakes using git and quick ways to fix your mistakes. I've found myself making a mistake mentioned on this page with regularity and always refer to the site to help myself fix it quickly. (It looks like they have a swearing-safe version now at https://dangitgit.com/ )
# undo the last commit, but leave the changes available
git reset HEAD~ --soft
git stash
# move to the correct branch
git checkout name-of-the-correct-branch
git stash pop
git add . # or add individual files
git commit -m "your message here";
# now your changes are on the correct branch
Similarly, for situations where you would look up hashes in the reflog, just click the Recyclable Commits checkbox, and everything in the reflog shows up as ordinary commits in the same commit tree as everything else. You can even see diffs between the reflog commits and your regular commits without having to do any temporary checkouts.
I know many developers like the command line and don't want to consider using a GUI. But I encourage you to give SmartGit a try. It works in conjunction with the command line, so you you're not locked into the GUI, you can use either one whenever you want.
Git is one of those once-a-decade technologies that's compicated, user un-friendly, takes months to master and is absolutely worth it.
Git shouldn't take months to master if you can understand it conceptually rather than by use-cases. If instead of trying to learn commands to affect the working directory, staged files, or history, you learn how git organizes historical tree of commit hashes, then base what each operation does, it becomes much clearer. It's similar to trying to learn strings of shell pipe commands to get things done rather than reali…
Oh, and the fact that a ‘git checkout’ is an unrelated concept to ‘svn checkout’ - and how SVN branches are “spatial” compared to git’s “parallel-universes” model is also a source of confusion.
If I could go back in time to 2005 (in addition to getting in super early on bitcoin) I’d beg Linus to not reuse SVN terminology. Personally I’d go with “git switch” instead of checkout, and “timeline” or “line” for short instead of “branch”. The fact that git branches are not 1-connected graph routes is enough reason not to call them “branches”.
I’d also convince him to include a “gitd” mode that would automatically fetch from upstream and automatically add commits when it detects file-move/rename changes. (I understand why git doesn’t have an exact “rename” op, but tooling today still isn’t good enough to detect rename-then-edit or rename-then-split operations without an intermediate rename-only commit. My dream “gitd” would also make auto-commits every 30 seconds just to give me a powerful filesystem undo feature. If you had hours of work that resulted in new files before you staged them and you accidentally did a hard reset then you’re sol - and this has happened to me already :/