Splitting up the work is time consuming with few benefits.
durron597 asks:
I was naughty. Too much “cowboy coding,” not enough committing. Now, here I am with an enormous commitment. Yes, I should have been committing all along, but it’s too late now.
What is better?
- Do one very large commit listing all the things I changed.
- Try to break it into smaller commits that likely won’t compile, as files have multiple fixes, changes, additional method names, etc.
- Try to do partial reversions of files just for appropriate commits, then put the new changes back.
Note: as of right now, I am the only programmer working on this project. The only person who will look at any of these commit comments is me, at least until we hire more programmers.
By the way, I am using SVN and Subclipse. I did create a new branch before doing any of these changes.
I asked a separate question related to how I got into this situation in the first place: How to prepare for rewriting an application’s glue?
See the full, original question and all answers here.
Don’t split up your work
Karl Bielefeldt answers (42 votes):
To answer, you have to ask yourself how you expect to use the results of these commits in the future. The most common reasons are:
- To see in what release a bug was introduced.
- To see why a certain line of code is present.
- To merge into another branch.
- To be able to check out a previous version for troubleshooting an issue a customer or tester is seeing in that version.
- To be able to include or exclude certain parts from a release.
The first two reasons can be served just as well with one big check-in, assuming you can create a check-in message that applies equally well to each line of changed code. If you’re the only programmer, then smaller commits aren’t going to make your merge any easier. If you don’t plan on doing a release or testing with only part of your unsubmitted changes, then the last two reasons don’t apply.
There are other reasons for making small commits, but they are for while you are in the middle of the changes, and that time is past. Those reasons are making it easier to back out a mistake or an experimental change, and making it easier to keep synced up with colleagues without huge scary merges.
From my understanding of your situation as you described it, it seems there’s little to no benefit to splitting your commits at this point.
Related: “Git for personal (one-man) projects: Overkill?”
Backup, then make your changes
Superbest answers (3 votes):
How about option four: back up your repo’s current state in a temporary place, revert your repo to its original state, make a list of all the changes you did (you can still look at the temporary backup), then manually reimplement (and compile and test!) them as separate commits.
This should be easier, because you’ve already written the code, it’s just a bit of figuring out which parts to copy and paste from your temporary backup.
When you have reimplemented every change cleanly, and thus ensured that commits are self-contained, small, and compile, you can delete the temporary backup, and everything will be almost exactly as (except for the time/date of commits) it would have been if you did it right from the start.
One check does the trick
Chris Lively answers (3 votes):
You’re the only programmer; just do a single massive checking detailing the important bits of what you did. Are you likely to roll back “parts” of what you did? If not, then absolutely proceed with option one.
There are a couple of reasons to check code into a version control system. And ALL of them, when you’re the only developer, revolve around safety. If you screw up, the machine dies or whatever, you can always get back to that last checkpoint.
A programmer coming into the project later is unlikely to want to roll back to a version that doesn’t compile. So, IMHO, option two is lunacy.
Option three sounds like such a time sink, that if I was your boss and saw you wasting hours doing this, I’d have a little talk with you about what your time is worth.
To iterate: by checking in your code you are covering/saving yourself in case of failure on your machine. Everything else, on a one-man team, is window dressing.
Find more answers or leave your own answer at the original post. See more Q&A like this atProgrammers, a question and answer site for professional programmers interested in conceptual questions about software development. If you’ve got your own programming problem that requires a solution, log in to Programmers and ask a question (it’s free).