After having witnessed developers use IntelliJ's built-in git functionality, I am persuaded that it should have never existed in the first place.

Asking you if you want to git add after every file you create, providing dangerous shortcuts that do pull, merge and push at once, but most importantly providing just enough comfort to keep their users ignorant about interactive git add or rebase, and other advanced git functionality.

The search for all the UI buttons + IntelliJ's baseline 5G RAM consumption is both slower and more error-prone than using the Git CLI

True! But a hint: rebase is cancer, go with backmerges, at least you have transparency on what you’re doing Bebe

Otherwise, IntelliJ becomes really resource hungry if you have that neutron star called node-modules in your project. It’s really insane.

I have a strange relationship with git integrated in the IDE.
It‘s useful to have it for read only information to see changes in the file structure and inside of files.
But I‘d never use it to commit stuff.
For that I use a dedicated GUI git client.
It can do everything that the cli can do but I have better UI and I don‘t need to remember the command names.

My main gripe with intellij is surprisingly their auto save.

Let me choose when to save, and if you want to keep backups transparently, fine, just don't fucking commit to disk every fucking keystroke.

@CoreFusionX can be configured.

All in all, IntelliJs GIT Integration is imho one of the most complete ones.

Interactive rebasing, squashing, dropping comments...

Many IDEs lack these futures.

@gcavalcante8808 I don't wanna be rude, but rebase or gtfo. (Feel free to force a merge commit, but rebase beforehand.)

@gcavalcante8808 is it due to node_modules? On Windows, does it make a difference setting them to +h (Windows' hidden attribute)?

@Lensflare I find git's default gitk utility more than enough & for remembering cmds vs ui button locations is basically a question of habit (but the former is free, available everywhere and doesn't require you to readapt if you change IDE/editor)

@saucyatom interesting. Why not a git merge or git pull origin branchxxx.

Putting any experienced aside, what each really brings into the table in terms of advantages? I always liked backmerges, it’s always seemed simple for me.

@webketje for me yes. Projects with a lot of dependencies and big neutron stars(node_modules) pulled my IntelliJ ideS down (I use pycharm, goland and clion ).

Most of the memory spent was with indexing and with eslint checks.

@TheCommoner282 git rebase is not error-prone, it is just not beginner-proof. So if you have less than 3y exp w git I say don't use rebase and if you do, test it out first on an unimportant project.

A single ticket should often be one commit. If it's not, your stories are defined too broadly. And no one needs to know retroactively that you pushed 4 commits of which only the first is significant and the 3 following ones are "fix typo", "fix lint issues", "integrate pr feedback"

@webketje the discussion is a very old one.

Rebasing / Squashing of reverts or as you described "typing up" is okay in my opinion, so git blame doesn't get messy.

But squashing for the sole purpose of having one comment and only one comment is senseless imho.

Git history should tell a story. The story of how the code was changed and why.

I think you are both right in that case: If the rebase is meant to have a nice history, ok.

If the rebase is just cause someone thinks 1 commit is best. Nope.

@IntrusionCM that‘s a great way of thinking about it!

@TheCommoner282 The history of how you changed your approach 5 fives usually is not important and only pollutes the history. That's why (in my ideal world) you'd make sure your history actually reflect logical changes - in your example you should end up with 3 commits, stacking upon each other. (Interactive rebase is your friend)

Once your working branch has a neat history, rebasing on main should not be an issue. You'll have a very clean history which is much easier to follow than having 50 fix-this fix-that commits.

As pointed out before it does require discipline and knowledge of your tools however, so it is not easy for beginners.

Interesting opinions here.

For me a backmerge + squash and merge worked wonderfully for almost a decade and it’s easy to teach.

Otherwise I agree that if you’re a folk that commit every line or create big PRs instead of breaking complex features into smaller PRs (maybe you need to follow weekly delivers or some other creepy and non continuous integration and deployment scenario) a rebase will make the history appealing.

@TheCommoner282 I didn't intend my comment with that tone of voice and in typing a quick reply omitted specifics (and I think both merge & rebase have their merits)

I totally agree with your example (there is some degree of subjectivity ofc in what you consider a single "effect") & the follow-up comments by @IntrusionCM, @saucyatom & @gcavalcante8808 totally nail it ++.

The need for clean history, separation of concerns (per commit), easy to understand PRs, and perhaps also potential cost (as in time spent getting conflicts resolved in a way that does not erase historically important details or results in bugs) needs to be balanced in the use case context

My own main gripe with intellij is that, in some circumstances, their 'Upload' command will delete files on a remote server. Change name of local directory and 'Upload', I'd expect to have two versions on the remote server, one with old name and one with new name. Wouldn't be wanting the old directory deleted silently. No. Really. Would. Not.