Not quite a Rails question, but more of a git question.
Typically, if a feature will be removed for few weeks because it’s not quite working, the common thing to do is to comment out the invoking code and leave in the “dead” code.
I’m wondering if some people actually rip out the code in a git commit and later undo that git commit? Is it lazy or efficient to just comment out the part where the code is invoked so that it can be easily fixed when time allows?
I usually delete everything that I don’t need and let git handle it for me. I don’t like comments, in general, so I try to minimize the amount of those I have in the code.
I’m with zamith. Commented code is like broken windows… it seems to multiply on its own until it takes over your project.
That said, if you comment it out and forget about it, there’s a good chance someone will stumble across it in the future and re-enable it. That won’t happen with a git branch (not until the semi-yearly branch cull that happens when some poor programmer just can’t handle 200 poorly named and obsolete branches anymore and harasses their owners to delete them).
My policy: if I’m pulling the feature out to hand off to a team, or put back in the issue tracker, then I delete it. If I’m playing with a problem and not sure what will happen, I’ll comment it out with a big fat TODO and a date. If a month goes by and it doesn’t get re-enabled, then any programmer should feel free to delete it.
shrug works for me
When I see commented out code I delete it and commit.
I just did this. My solution was to disable the feature via a couple surgical changes that lived in a single commit. When I went back to fix the feature, I then reverted that commit as the first action in the “fix this” feature branch.
Obviously, reverting a feature is a sign of a problem and should be examined when it happens, but this felt OK. I squashed the revert commit, I don’t see it as being an incredibly important part of the git history, as the “fix branch” commits articulated adequately what was going on.