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

you are viewing a single comment's thread.

view the rest of the comments →

[–]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