I asked about that for diffs, because I can't imagine using a terminal for this job. I don't mean any offense by it just to be clear, it's just not something that works for me. Perhaps I rely more on visual orgnaization. To give some context to that:

The standard way git shows up in a terminal (on Windows) it's diffuclt for me to "orient" myself in the code based on the diff, I prefer side by side diff compared to the split addition/deletion lines. I also like syntax highlighing that default git does not do.

Git in a Jetbrains IDE has the diff for any of my changed files is a single click away. The commit window has overview of changed files, a single click to view and edit a diff, including the normal syntax highlighting and one-click revert for a single change. Jetbrains specifically also avoid some of the bothersome part of pulling or checking out changes, as it doesn't force you to stash changes first.

Dealing with a merge conflict without a GUI also seems exessively hard. How do you do that through a terminal and keep track of things? Especially if it is a really messy conflict?

[–] [email protected] 1 points 1 day ago (1 children)

How do you do that through a terminal and keep track of things? Especially if it is a really messy conflict?

I am not sure how to articulate the answer to this question, as it just feels intuitive. It is how I learned and used it, and it would be akin to describing how I see colours. I am sure I would have found it a pain at the beginning.

In the case of a messy merge conflict, it consumes a lot of time, which I am sure would be the case with GUIs too, but I never found Git on terminal getting in my way in such instances.

I prefer side by side diff compared to the split addition/deletion lines. I also like syntax highlighing that default git does not do.

I can say that I prefer inline diff view, and find split diff views to be jarring. I am sure syntax highlighting can be enabled while viewing diffs on terminal. However, I never bothered enabling it, despite using it in my editors for as long as I can remember.

Jetbrains specifically also avoid some of the bothersome part of pulling or checking out changes, as it doesn't force you to stash changes first.

That sounds risky to me. But as long as it make sense to the user, and it always behaves deterministically, it is fine.

I remember trying out the Git GUI offered by CLion a few years back. I found the interactive way of viewing diffs a chore and time consuming. Perhaps, they have revamped the UX; I remember reading about a UI revamp across JetBrains' lineup a year or so back. If so, I will check it out again.

[–] BehindTheBarrier 2 points 1 day ago (1 children)

Thanks for the replies.

The stashing isn't as bad as it sounds, it keeps a copy around when swapping branch so even if you fuck it up, it should still be in storage. I think the worst one I had was popping from the shelf and it failed to apply but still got removed... I don't remember why that ended up happening but yeah. Not exactly related to the automatic stashing however. But I tend to more often want to keep changes changing branch than not. I have to use stash/Shelve less often because of it.

I know Jetbrains added a "all in one" diff option about a year ago, but I hate it as large/many files make it horribly slow and awful to navigate compared to just moving through the files one at a time. But the diff view itself good. I know there may be some that disagree, but it allows ignoring whitespace and newlines, which filters out non-important from important changes. For most programming (aka not python) whitespace changes means nothing so it doesn't matter 99% of the time. But it greatly improves going through a diff that had a total "code cleanup/reformat". Which is more often than one would expect in my project.

[–] [email protected] 1 points 1 day ago

Ignoring whitespace can simplify diffs, but I prefer to keep it visible to see exactly how the code has changed.

I also try to minimize whitespace changes by relegating formatting adjustments to the final stage of a code check-in, after all approvals. It is even better when the project or team uses Git hooks with a linter and formatter to take away this rote work altogether.

Thank you too for sharing your workflow. It is always interesting to read how everyone approaches the same problem in their own way. :-)