> This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs.
Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P
> Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit.
To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained.
You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective.
It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project.
How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)
> Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project.
Disagree, because the commits are merged in and I can clearly walk through them. You should think very carefully about what you're committing and when--but that doesn't make rebase a license to do stupid things to make life harder for other developers, and personally I am completely and entire convinced that that's really all rebase does; I consider it one of the biggest brain damages of git and in pushing the SVN->git migration crusade (because even with rebase stupidity it's vastly better than SVN--I'd prefer Hg, but that ship has sailed) at my current employer I'm pushing to have "don't mash your commits" made into policy.
> How the development actually happened is completely uninteresting in git.
"In git" has no bearing on what is interesting in the development cycle, and it's a little arrogant to claim that that's the case. My version control system does not decide what I find interesting.
Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P
> Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit.
To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained.
You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective.
It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project.
How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)