Top 10 school or 10x developer, or both?

Woo hoo - new boss just contacted me about potential git clients. My nightmare scenario that they were still on subversion somehow is abated!

She's thinking about purchasing Git Kraken Pro for the team. I'm used to SourceTree but sure whatever.

I know real programmers never use a GUI for anything that can be memorized in a mere 50 command line commands + options and worked through in a painful terminal display.

Whatever school he went to is lost in the mists of time, all the better. I dunno of 10x QA guy is a thing but here's hoping.


Sigh, I kinda like subversion, how much of a troglodyte does that make me.

Is this where I admit most of my legacy work is on an old CVS server? And that I used to use RCS?

Am I mixing you up with LarryLegend again?

I've used CVS, VSS (shudder), StarTeam, Subversion and probably some others I'm forgetting.

In the old world you couldn't check out a file if someone else had it checked out to edit. If you wanted to work on it you literally had to go find that person lol.

Subversion or maybe StarTeam(?) broke that mold and paved the way for git. WHAT YOU MEAN WE CAN BOTH HAVE THE SAME FILE CHECKED OUT TO EDIT? What is this madness?

That's for me to know and you to find out?

Or I could just go back a couple pages.

Don't be ridiculous, the only system I ever encountered like that was Perforce. All other systems I ever encountered were resolved at commit time.

VSS was like that (in 2000-2002-ish). You had to check out files to edit. If one was checked out you couldn't edit it, except by killing the other person's edit checkout. The files were set to read-only on your dev machine. One way to avoid merge conflicts.

I felt like CVS was too but I only worked with it a little in 2000 or so.

VSS I never worked with.

CVS does not fool with the repo until you want to commit. Same with SVN and git. Perforce, when you wanted to edit a file you had to ask permission. When you did a commit, it was all associated with a "revision" that you had checked out in advance.

I think think aside from RCS those are the only ones I've dealt with.

CVS in 2000 might have been a little different. I think this concept is where the whole term "check out" came from for code. You had to check it out to work on it.

I think the it's the "lock" concurrency model in this list: https://en.wikipedia.org/wiki/Compar...ntrol_software

VSS either didn't have a merge option or we didn't turn it on back then.

Interesting stuff suzzer. I wish there was a documentary on old school source control.

It's not that intimating. And the terminal is the opposite of painful. To me, a GUI would be painful and total amateur hour. Most of the git commands are:

status
log
add
commit
reset
rebase
branch
checkout
diff
grep
stash
fetch/pull
push
merge

(that was more than I thought, but it's pretty intuitive, not blind memorization)

Ok now do all the flags and exact syntax of each. Gimme a choice of memorizing all that or a gui that does stuff the command line can't do (diff) and I'll generally pick the gui.

Git bisect is super badass for debugging when you aren't sure where a bug was introduced - and about the only thing I use git command line for.

I've seen people check in with git and walk through changes. It looks pretty painful compared to a GUI with diff and discard changes feature built in.

I guess I just don't really enjoy terminal that much.

You're forgetting about aliases, e.g. it's trivial to create an alias for "git rebase --continue" as something like "grc".

It's not a crime to use the GUI, you'll just be slower. It's like typing on the keyboard with two fingers because it's "easier".

I use our git provider (e.g. Gitlab) for looking at large diffs (e.g. merge requests), but if I'm looking at the diff of unstaged/staged changes or between commits, then `git diff` is sufficient. Commits should also not be gigantic changes, that's what branches are for.

Whenever I show command line people "discard changes" in SourceTree, they're always like - oh yeah I can't do that. I lean on that hard.

With that I can make all kinds of changes when I'm trying to debug or figure something out, then on a file, block or line-basis, easily throw those away before committing the changes I do want to commit.



Notice I have the option to discard the whole file (meaning just the changes in green), the hunk in question (far right button) or I can just do a line or group of lines if if I select them. No one has ever been able to show me a command line equivalent to this.

`blame` is also neat

If I understand your example, let's say you add 5 additions (maybe be several lines) to a file. Now you decide you only want to undo the 3rd and 4th additions? I don't know if there's a git command that revert sections of a file, but the git way of doing would be to create 5 separate commits. If the 5 changes are independent, then there's an argument to to make them 5 separate commits.

edit: `git checkout -p` let's you do what you want. Learned something new! And I never knew the technical term was "hunk", but I always knew that git kept track of changes in chunks (Linus should've called them "chunk" imo). I know this because I run into conflicts where one part of the text is empty, and the new part is non-empty, and the obvious solution is to add the non-empty text, but git isn't smart enough to resolve it on its own.

And regarding "memorization": it's not a matter of memorization, it's matter of knowing git. `git rebase` is more than a command, it's a concept. Once you know what rebase means, then it's trivially easy to remember the command `git rebase` or easy to assign as short alias to it.

Yeah the GUI makes doing discards at a file, hunk or line(s) basis much easier. Even the command line guys would always concede that to me when I showed it to them.

As an aside, we never rebased at my job. Just merge. We didn't care too much about clean history and cared a lot about weird conflicts. I get that other shops might care more about clean history.

I'm not sure I follow your exact usage but it sounds like a job for `git add --patch path/to/file.lol` (or -p ) flag to go through each set of changes and determine if you keep, discard, etc. Obviously it's not the same experience.

I will say that vscode has some pretty solid git integration built in to the UI that I have been enjoying. It even has a Discard button for you. I'm all for use the tool you enjoy and want to use. Sometimes I'm in the terminal, sometimes in vscode. Might as we be able to commit from both.

I once opened sourcetree, and I was just as lost as my co-worker was in the cli that only uses ever uses sourcetree.

A huge plus for cli is that if you need to do something it takes 5 seconds to google "how to blablabla in git" and you can ususally copy paste the first answer.

For gui its never that simple.

You should ask those guys if know about `git add -p` and `git checkout -p`, because I sure didn't an hour ago. Otherwise, I almost conceded to this one feature, but definitely wouldn't have forfeit the terminal for it.

Right, and imagine if you knew the command (and had aliases) and didn't have to google and copy it.

It's probably easy to do as well if you know the gui procedure off hand.

The git cli isn’t some mystical thing that takes forever to learn. I learned the basics of what I have to do day to day in just a few hours. And for routine tasks you find yourself doing a lot you can always script.

But, I am still pretty error prone, the office got a hearty chuckle out of this bonehead move I did the other day:



I thought I was on my dev branch and did something goofy with a pull when I should’ve used a fetch. Ended up merging master into master during a small change I made to a file. I thought this was a mistake so i reverted it.

Then i realized i ****ed everything up by doing that so I reverted the revert. Lol whoops.

I heavily lean on sourcetree for certain use cases. CLI stalwarts: please tell me how to directly compare 2 different commits diffs? Because in sourcetree its 2 clicks while holding cmd. Also checking out commits (detached head) is ridiculously easier. Both of which I do daily while doing PR review etc.

I exclusively use command line but I wouldn't describe myself as a stalwart. I expect there are probably some use cases where the GUI is better, which I just don't happen to use very often. Probably even some where if I got used to using a GUI I might prefer it, but I haven't been bothered enough to find out. When I review PRs I tend to just check out the branch.

When you say "compare 2 different commits diffs", you mean compare their respective diffs against their separate branches, but side-by-side? i.e. like running two different "git diff" and displaying them next to each other? If that's what you mean I'm not sure if there is a command line command for that. Probably have to have 2 terminal windows side by side or something.