11–20 of 146 posts
I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.
-p, --patch
Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.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 add --patch, try the 'e' option if you need more nuance than the hunks git provides (it contains instructions for how to ex/include individual lines, so you don't have to remember how to do it).
Is there a historical reason why git is needlessly complex? Seeing this cheat sheet really brings it to life.
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 terminology and sometimes workflow is backwards from every other "normal" version control system. A "Pull Request" (PR) is named that because for Linux development Linus/maintainers would PULL changes into Linux kernel tree. In almost every other version control system it's called a Merge Request which logically makes MUCH more sense because you are merging a change (where ever it came from) into a tree.
Git was (still?) the only open-source distributed version control system that could handle enormous code bases with good speed which means it gained a lot of inertia at big companies as well.
I vastly prefer and use Mercurial for personal projects but if you have tried to use Hg on huge code bases (I've tried on Android AOSP) it really chokes. Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal.
I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.
Btw I moved from Sourcetree to Fork. It’s very similar but way more performant and smooth UI (unless ST has improved in last few years)
Earlier quoted context omitted.
It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpo…
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.
The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.
Thanks!
Are there git alternatives that aren't a PITA to master before one can use them in production?
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 WINE fails because Sourcetree can't be installed with the 'Administrator' user and recent WINE releases have (accidentally?) removed the ability to run a WINE program as a non-Administrator user.
I haven't personally tried (yet) to install Sourcetree on a Windows machine and copy the directory over and try via WINE, but it's on my list to do.
A 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…
I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.
All I know of git is clone, pull, commit, and push. That’s all I’ve ever needed. Git can be that simple. Of course it supports more complex uses, which you can learn if you need them.