Earlier quoted context omitted.
After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.
So where is the totally refactored/revamped CLI that applies Occam's Razor ?
Git cheat sheet [pdf]
121–130 of 146 posts
Re: Git cheat sheet [pdf]
#122I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: "git diff > works.patch" Later on, you can apply it if necessary with "git apply works.patch".
You could use stash for just that use case (even multiple times to make multiple "patches"). For a more robuts method, you could also just commit (without pushing of course). Then, you can do "git reset --hard HEAD~1", and you have a pre-patch env ready for more work. When you need to re-do your commit, you can check reflog to get the ID. Either way is, to me, an easier way to achieve the same result as patches.
Instead of looking up the commit hash in your reflog, you could also just create a branch on that commit and refer to the commit with the branch name.
Re: Git cheat sheet [pdf]
#123Earlier quoted context omitted.
IntelliJ has become pretty powerful with Git these days. Squashing, dropping commits, rebasing. Even interactive rebase can be done in a few clicks. I sometimes pop up IDEA to do some non-trivial cleanup in a repo. Even if relatively fluent with the command line, it saves me a lot of time.
What I like most, and isn't available in most UIs, is the ease of selecting individual lines you want to commit. Allows you to make very clean isolated commits most of the times.
Magit does that and this is super useful indeed!
Re: Git cheat sheet [pdf]
#124A couple of hidden gems: git diff --staged (shows the diff between the last commit and what you've got staged, great when what you're staging is finicky, lets you double check that you have precisely the files/hunks you intended) git log (git log, but for just commits where was touched; saves pilfering through all of git log, especially useful when the file only gets modified infrequently) Random tip: when using git…
> git diff --staged (shows the diff between the last commit and what you've got staged, great when what you're staging is finicky, lets you double check that you have precisely the files/hunks you intended)
If you set `git config --global commit.verbose true`, then Git will automatically include this diff in the comment section of the commit message editor.
Re: Git cheat sheet [pdf]
#125Earlier quoted context omitted.
Subversion. It was made by CVS maintainers and a lot of care and thought was put into how it works and how the commands work and what the names of the commands are. Subversion is limited in being an older model of version control where there is exactly one single source of truth. In my mind Git solves a different problem that Linus Torvalds was facing: many people working in parallel with only some of the ideas pushe…
I have just the opposite view of yours! Subversion is so so complex. It requires a client and a server . It might have a nice UI, but its internals are a mess. Just the opposite of git! Why would a solo dev choose to use a client-server version control instead of one that works fully locally?
Subversion does not require a server :-)
You can ask Subversion to create a repository anywhere you like in the filesystem.
Re: Git cheat sheet [pdf]
#126I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have. I used to barely understand git, but after a couple of years working at a company that relies on a rebase workflow, I'd like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet. Is it common that developers still have issues with git after using it pro…
A version control tool shouldn't take YEARS of usage to be productive, to me that's a red flag. Some engineering tools are just complex because what we're doing might need that flexability so the tools provide a myraid of options or workflows.
But writing software, tracking your changes, being able to back out your changes and getting your changes integrated into a code base should be as low activation energy as possible to be productive.
But again, git wasn't created for "you and me", it was created by one guy for his project, the fact "mere mortals" are using it is kind of our fault.
Re: Git cheat sheet [pdf]
#127Earlier quoted context omitted.
Yes. Because git was created by Linus Torvalds specifically to enable and advance Linux kernel development. The fact it has become so widly adopted is a "happy accident" (or misery). Github I think has been widely credited with making git so common place ("free git hosting") but I don't think git is the "ideal" revision control system for many projects. Because it was made for Linus for Linus/Linux, this is why the t…
It might also help understanding, when talking about the history of git, to keep in mind that it came to be out of the urgent need for a tool to replace (then still proprietary) BitKeeper. I wouldn't say that bk is as hard to grok as git, but it's certainly complex as well. I wonder if some of git's idiosyncrasies are a result of intentionally avoiding a look&feel equivalent to bk lest that would alienate Mr. McVoy.
I can't say I was front and center to everything happening, but I always thought it was strange that Linux used Bitkeeper which is very not open-source. So many battles have been fought around Linux and GPL that this seemed a bit hypocrtical.
Of course things were run afoul when Tridge started reverse engineering the bk protocol/datastructure but frankly the need to switch away from bk was a bit self-inflicted from what I could tell.
Re: Git cheat sheet [pdf]
#128Are there git alternatives that aren't a PITA to master before one can use them in production?
Mercurial if you're not on a huge code base. While the core command-line hg works great, GUIs and third-party programs are kind of lacking. Atlassian Sourcetree in theory works with Hg (because Atlassian's Bitbucket used Mercurial as their primary version control system before moving to git) but SourceTree is Windows/Mac only, there is no Linux version for some strange reason. Trying to run SourceTree on Linux via WI…
This whole thread got me to go back and see what else is out there and I remembered there's another (potentially) saner choice: Fossil : https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
I haven't used it myself but I might for a solo project I'm involved in right now.
A good read (not my article, linked from the Fossil site):
Re: Git cheat sheet [pdf]
#129Every cheat sheet like this highlights the surprisingly high learning curve of the git cli. It's an interface that really ships it's underlying data model rather than optimizing for common workflows. This isn't necessarily a bad thing, but I often feel like the target audience of git is the power user, leaving me uncertain anytime I need to perform an intermediate level action.
Lately I've been enjoying Graphite as a tool to interface with git. Commands are based around atomic actions I want to perform, despite often triggering multiple git commands under the hood. This has reduced my overall mental overhead, and removed many footguns.
Re: Git cheat sheet [pdf]
#130Earlier quoted context omitted.
You must learn the terminology to properly understand it, but after that it's smooth sailing This promise never held to me. I know the terminology and “how”, but it never got clear in my mind how to express day to day things which aren’t clone/add/commit/push. It’s just bad unmemorable ui that is both cumbersome to use and reason about. I do have trouble remembering things but not like this with any other tool. For e…
Lol if you can remember how to use ImageMagick and Ffmpeg but not Git, I don't get it. Those programs do have very different argument passing styles than Git, but Git uses the same style as most every other unix/linux program. If you use it and know what you're doing, you should not be able to lose any work. My advice to get over the hump you're on is to commit more often, check the status more often (`git diff [--st…
What ffmpeg and magick have in common that git doesn’t is (relatively) intuitive and straightforward arguments. They have lots of arguments, but they are otherwise simple and consistent. If I remember an idea, it always works the same and looks the same.
In git there’s always “foo”, “bar --frob” or “baz :QUUX -j” in a set of logically related operations, and neither of keywords make sense. Also every generation of git had its own ui ways, so it’s very hard to learn if it’s e.g. some reset/checkout incantation or just restore that you wanted, because when you refer to google, it never knows it’s not 2015 anymore. Some humans can’t learn inconsistent badly named things, I’m one of them. I can remember, but to actually understand I’d have to understand Linuses mind’s inner machinery, which is alien to me.