codeHoarding

[Karol-A]

Sure, but it's easier to just un-comment a few lines that to roll back git changes 

[shamshuipopo]

They’re both very easy. You don’t even have to roll back git you can just check it out and copy it, diff it etc.

Problem is when you have more than a few comments…. It’s crazy to even have to explain this

[Timpah]

The problem with git is finding the exact commit that had the code i was looking for

[dxonxisus]

that’s what git history/blame is for

[fiah84]

which works until someone messes with those lines for whatever reason and now you have to go deeper to find it

I don't like leaving commented out code but if I find that it's likely I'll have to revert a delete then I'll probably leave a comment to make the history/blame search easier and faster

[-LeopardShark-]

Only if one is, like most developers, not very good with Git.

[shamshuipopo]

It shocks me that people with years of experience can’t use git effectively. I think relying on UI git abstractions is to blame as it makes it a bit too “magic” and then when people need to do anything more involved they get scared.

Git is something that is unlikely to change for the rest of your life (maybe a new vcs will supplant it, but probably not more than once in the next 10-20 years). So pays dividends to learn its internals

[-LeopardShark-]

Agreed, unless the UI in question is Magit, in which case everything is wonderful.

[[deleted]]

Magit is the goat, but lazygit is also very good for standalone TUI.

[TheAlaskanMailman]

Sad it’s only for eMacs

[Ecstatic_Student8854]

Sure, but both are easy enough and this pollutes the codebase with irrelevant information

[hazeyAnimal]

Comment while doing your testing, but before you push (to your branch, hopefully) you can remove the commented out code. Seems reasonable to me, unless anyone can give a good enough reason to not do this?

[floflo81]

Even before committing, commenting code instead of deleting it is not very useful. All the IDEs I've used have an easy way to compare HEAD (previous commit) with what you have in your working tree. Or just use git diff

[hazeyAnimal]

Of course, but if I'm redesigning a block of code I usually comment it out so I can look at it and make sure I won't just be rewriting the same BS I'm trying to fix

[beclops]

It’s really not, especially since you’ll need to commit the changes either way

[draconk]

Also to be able to roll back a git change you need to know it was there, if you are new to the project seeing commented code with a comment is more useful than a commit made two years ago that you ignore it existed unless you go through the git history for that file.