151–160 of 550 posts
You don't need -- as much in the "git restore" example. With git checkout it may be necessary to separate the branch and the paths with "--" but since "git restore" does not take a branch (except with -s), doing this is totally fine git restore test.txt
It's usually not necessary for checkout either
A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…
I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you
- use the same terminology as git
- show a log of every command
- default to sane behavior
- ask preferences instead of assuming (ex: rebase or merge?)
- show warnings when doing something destructive or unusual
I've found that I now spend zero time learning and thinking about git anymore, and it also protects our repos from git noobs at the same time.
However, what really sticks in my memory are the concepts Git implemented. This helps to refresh the operational knowledge rather quickly, well, notes help too.
In my view, 'check-out' as a concept is very much central to VCS as such. So, having a dedicated 'checkout' command which works on both commits/branches and files is quite reasonable - it keeps you in the same conceptual context.
I don't mind the specialized commands, such as 'switch' and 'restore'. But sure enough, I'll forget these wordings or maybe even mix them up with 'reset' or 'revert', ??'undo', yet the 'checkout' command would likely present itself on my command line as it's directly tied to the concept.
My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and…
Or maybe just don't shame people for not working the way you do.
Earlier quoted context omitted.
I feel you. I was recently hired to help with svn to git migration and Java upgrades from 5-7 to 8 (due to my previous experience with such migrations). When I joined they already had a plan. They told me no one will be using command line. They are currently discussing which GUI to use and everyone will have this GUI installed by default, git command will be discouraged as non-standard approach, windows users will no…
Sublime merge would have been a good suggestion in this scenario. It's UI uses standard git terminology and concepts, so you'd have been sneakily trainig them in the command line whilst they used the UI!
This is also why there was so so much fuss about git GUI client, there were looking for a golden hammer, a GUI that would do everything and anything.
A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…
I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you
I would never brush off a team member with “cannot help you”. I’m a git expert and I will figure out what’s wrong and fix it.
My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and…
I think sublime merge is pretty close to the optimal git GUI, https://www.sublimemerge.com/ . It uses standard git commands and terminology and allows you to add custom git commands to the GUI. Unlike Sourcetree is cross platform for Windows/Linux/Mac and includes a merge tool. I think command line git and Sublime Merge git translate back and pretty easily.
It is unfortunate that: + git switch is documented as "EXPERIMENTAL" + git --help lists git switch but not git checkout as an important command This is a documentation inconsistency. It can't be both the canonical interface to use and experimental at the same time.
So send in a patch.