71–80 of 550 posts
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…
In a similar manner for Emacs users: magit-toggle-refine-hunk is a lifesaver for word diffs
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 not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge.
The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists? But I could harp on the same way about his missing MATLAB or firmware skills.
Earlier quoted context omitted.
> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never nee…
I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems. Unfortunately due to time constraints, interest levels, and simply ease people go top down. They need to switch branch, so they will follow the least effort principle and use a UI. Barely understanding many fundamental tools is common thes…
You can use top-down knowledge to inform yourself on what concepts you need to learn, and you can ignore the parts of the domain you need right now. But you still have to learn them bottom up. Getting confused by the concepts you're using is a gigantic waste of time.
And the harder the concepts, the easier it is to get confused, so there's no trade-off.
What is a good resource to learn modern git properly? I have been using git for 10 years and get around with a really small set of old commands.
If you want to learn Git from the inside out, I wrote a two-parter that aims to explain Git from the inside out, focusing on the data-structure Git uses:
https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/
https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/
Finally, _if_ you have an O'Reilly subscription, I am currently writing Head First Git (first four chapters are in early release). If you are not familiar with the Head First series, its a rather unique format that involves using lot of pictures to explain ideas and traditionally the books move a lot slower than most technical books. Ideas/concepts are cemented using puzzles, quizzes, crosswords.
You can see a list of the existing ones here https://www.amazon.com/Head-First-Series-Books/b?ie=UTF8&nod...
Feel free to email me if you need any more resources—I have spent a lot of time teaching Git.
Can someone tell me why they decided to have the new branch argument be `-c` in switch when it's `-b` in checkout?
Earlier quoted context omitted.
How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning. Its probably a rhetorical question but I think its worth answering anyway. Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. If you are a new dev…
>Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. The depressing thing is I'm not talking just about off-the-shelf newbies, I'm also talking about experienced devs. >Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity. Yes, unfortunately, this is b…
I used to know lot of terminal commands but I'm seriously falling behind due to jetbrains integration which covers 99% of my daily use case. Together with local history, I've never "lost" work in years. Never heard of switch /restore and will probably forget about it the next time I'm on the terminal. Rebase and interactive Rebase is so well integrated for my use cases and I feel much more productive without having t…
> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never nee…
Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git.
The goal of being a programmer is to produce cool things, not to duel with your tooling.
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…
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…