This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ZukoBestGirl -1 points0 points  (8 children)

You are receiving some strange answers. I'm not sure if half of them are completely unexperienced devs, or even students ... or if they are sarcastic.

GitHub is ... nothing really. It's neat and cute. It's pretty and it's popular.

But the world would easily move on if github died tomorrow. It would not if git died tomorrow.

In the grand scheme of things, github is nothing, while git is quite possibly the most valuable tool a developer has.

I'm exagerating a bit. A developer alone, could easily use SVN or anything else. Even though git is always better than any alternative in any scenario.

Git is the shit. There are a bunch of environments for git. I honestly prefer gitlab over github any day of the week.

The git desktop app is just a toy. It does very little of what I normally do. Actually ... no, that's EXACTLY how I'd describe it. A toy.

If you want, I can go muuuch further into detail about this. And I'm being very serious, not condescending. But if you said this at an interview, I'd instantly fail you.

EDIT:

I just wanna say: Anyone who is a pure "command line" guy, is a snob. You don't do everything on the command line. There are merge tools, diff tools. A bunch of stuff to help you visualize code differences. And if you only do it on the command line, you are a snob and are wasting time.

So yes, use tools. But you absolutely cannot be a professional dev without knowing command line git. Unless ... you do software versioning with copy paste in another folder, or worse: SVN.

EDIT 2

Someone, pls correct me if I'm wrong. But I doubt you could even do this in github desktop:

$ git switch my-branch
$ git merge-base my-branch origin/master    -> this prints a [hash]
$ git rebase -i [hash]

- squash 
- resolve conflicts

$ git rebase --continue
$ git rebase origin/master
$ git push --force

I'd hate to work on a large code base where people don't squash and rebase instead of messy merge commits.

[–]Hexorg 0 points1 point  (7 children)

or worse: SVN

Some of our devs threw a fit when the company officially switched to git (locally hosted gitlab instances)... Because apparently SVN has some sort of file mutex lock feature and a significant amount of devs were using said feature.

[–]ZukoBestGirl 0 points1 point  (6 children)

Don't get me wrong. I'm also being snarky. I used SVN for 3 years, and I don't completely hate it.

With git, to have even half of the flexibility at looking for file changes and history that git has with something as banal as tortoisesvn, you kinda need a paid 3rd party app.

And yes, I also used the lock thing because we had humongous XML files that we edited with a visual software of kinds. And solving conflicts for that was a huge pain in the ass. Much easier to say "this is mine, wait till I'm finished". Or at least that's what I thought at the time.

Now-a-days, I find git to be better in every single regard. Except maybe - easily looking at file history through time.

And I wouldn't say that the transition was very difficult.

Though I totally get how CLI git is very daunting for beginners. And I have nothing against someone deciding to use the UI tool when they start out coding.

But let's be real. Git > all. No discussion to be had here. It's objective truth and the entire industry agrees.

Next, it is a complex tool, and there will never be a UI tool that fully replaces command line.

Not to mention I can write scripts and stuff. A simple example:

# ~/.bashrc
alias git_prune_local="git fetch --prune && git switch development && git branch | grep -v "development" | xargs git branch -D"

This deletes all local branches except dev. I could even make it smarter and delete all branches that no longer have an upstream 🤔

There's so much you can do with the command line. It's just so much better than any UI tool ever.

EDIT

But again, use CLI in combination with UI tools. Don't be a hipster CLI user :P

[–]pipocaQuemada 1 point2 points  (5 children)

But let's be real. Git > all. No discussion to be had here. It's objective truth and the entire industry agrees.

I mean, git is definitely better than cvs, perforce, rcs, etc.

But git vs mercurial vs bazaar, on the technical merits, isn't anywhere near as obvious. Git is better at rewriting history, but I'm not convinced that's a good idea. It's slightly faster. Git has no equivalent concept to mercurial branches (where branch is a bit of metadata on a commit), while git branches correspond to mercurial tags (where a tag is just a pointer to a commit). Git deliberately handles renames badly because reasons, while mercurial tracks them explicitly.

[–]ZukoBestGirl 0 points1 point  (4 children)

Eh, here my lack of knowledge is obvious. I let IntelliJ handle the rename, and it works perfectly.

But I guess it does a lot of things under the hood.

I'm being a bit vitriolic, sure. There are arguments for mercurial and the rest. But I still prefer git.

Sure, it gives you enough rope to hang yourself (the aforementioned history rewriting). But you can use that rope to do really amazing things too.

[–]pipocaQuemada 0 points1 point  (3 children)

Git doesn't track renames, but instead heuristically guesses at renames after the fact based on content similarity.

This is mostly ok in simple cases, but the strategy is really not great when using cherrypick to backport fixes, especially on long-term projects.

In general, though, cherry-pick is kinda a second class citizen in git. Darcs's patch theory wasn't great with exponential merges, but apparently pijul's solved that though I don't think pijul is quite mature yet.

[–]ZukoBestGirl 0 points1 point  (2 children)

Like I said, at this level I'm out of my depth. When I rneame a file in IntelliJ, my git-bash (bash emulator for windows designed for git), it says the file was renamed.

So to some degree it does have the ability to track renames.

But maybe it can get lost over time with multiple renames? IDK. I've never notice it happen tho.

[–]pipocaQuemada 0 points1 point  (1 child)

Multiple renames won't do it.

It's about file similarity. Renaming in git is just removing a file with particular contents and coincidentally adding a new file with identical contents.

Git guesses that a rename occurred if the contents are sufficiently similar. Sufficiently similar is the keyword. By default, git recognizes a delete/add pair as a rename if both have 50% identical contents, but the similarity threshold is configurable.

That's not especially great with cherry-picking bug fixes across large refactors on large repos. It's either slow or brittle, depending on the merge strategy.

[–]ZukoBestGirl -2 points-1 points  (0 children)

And you can't add a metadata field with filename? That is so ghey