Thomas Heller wrote:
On 03/21/2012 11:02 PM, Julian Gonggrijp wrote:
This is not just about bugs or private/public, this is about making changes to work. Even just changing your mind before you make something public already happens often enough to make local unit-of- work commits a feature. If a bug is found after the faulty code has gone public, small commits still help to better narrow down the changes that caused it and to reduce the amount of work that has to be done to solve the issue.
Unit-of-work commits make it easier to find and review past work, reduce the burden on the developer to keep track of what they're doing until they're ready to publish it, and enable you to keep unfinished but versioned work around while working on other, more publish-ready changes. Unit-of-work commits really help you to manage and keep track of work, contrary to snapshot commits which mostly just provide a backup facility.
This is way more generally applicable than you seem to be willing to admit. Sure, this all makes perfect sense. But this is not restricted to a DCVS, this can be done any version control system (be it centralized or not).
Nobody is going to make many small commits in a CVCS, because it adds too much overhead and because commits on a CVCS have to be "good enough". I've already said this. The "you can do this in svn too" argument really doesn't hold here.
It is a matter of good habit.
A good habit people are forced to give up when using a CVCS.
Though, as has been pointed out numerous times now, every approach comes with its own set(s) of problems.
unit-of-work commits by themselves do not introduce any new problems in comparison with snapshot commits. It's rather the other way round.
Unless you can test _everything_ on your local machine, or you push onto a volatile branch, which opens a completely other can of worms (from what i understand). What can of worms? I don't recall reading any post that described a can of worms associated with volatile branches. Besides, /if/ you're altering volatile branches anyway, that's again way easier to manage with unit-of-work commits than with snapshot commits.
You seem to suggest in addition that what we've been discussing here has something to do with cans of worms. Do you actually intend to suggest that unit-of-work commits introduce problems that don't exist for snapshot commits? No, I am saying that altering history is dangerous! Which you described as one of the advantages of "the git approach".
We have to distinguish between published and unpublished history. The power to alter unpublished history isn't dangerous at all, it's a convenience that boosts productivity and which is better facilitated by smaller commits. Altering published history may admittedly come with caveats, but I think this is orthogonal to the size of commits; whether you alter published history or not, smaller commits will always help you to do a better job at what you do.
I completely lost track. I described my experience I had with. I was told that this was not the way to go, I am not sure if it is directly related to "changing history". But the problems existed.
I read your nightmare story and I appreciate it. You're definitely right that the forking business isn't trivial. However, with the right preparation it can be fun and rewarding rather than a nightmare.
Now, force pushing (as i understand this is the only way to rewrite published history) essentially breaks every other clone of that public repository.
No, as Dave explained it doesn't have to break other repositories. If your peers know what to expect they'll pull --rebase from the volatile branch and nothing breaks.
[...] This is exactly the can of worms i was mentioning. Or to formulate it differently: When is my public repository, which i intended for my use only, not private anymore?
A public repository is never private? If you want a repository to be private then don't make it public. Perhaps you meant to ask something else. -Julian