Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-03-22 06:01:28

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