Le 20/04/2011 19:11, Darren New a écrit :
> On 4/20/2011 9:03, Invisible wrote:
>> Fundamentally, VCS are about tracking changes. Git might *implement*
>> that by
>> storing the entire file, but *logically* what you're trying to do is keep
>> track of what you changed.
> 
> Or, as an alternate example, say you've been working and every day you
> commit before lunch and you commit before you go home, even if it's not
> working, just so it gets backed up. And you implement two functions, and
> you write code on that, and then realize you should have put that first
> function elsewhere, and you don't need the second function at all, and
> the other code should be in separate objects, and etc etc etc.
> 
> And at the end of the week, you have 50 messy changes committed.

Yes, but that is in your messy repository only.
"Commit often, Push when working" is a good approach with DVCS.

> 
> With git, you can say "OK, go diff the current version against where I
> branched, and give me exactly one commit with all the changes I need."
> It's trivial to do that in git and then say "now commit *that* change
> for everyone else to see, and abandon all the intermediate changes."
> 
> I don't know how you'd do something like that in mercurial or darcs that
> store *changes* in the repository.
> 

For mercurial, there is an extension which aggregate the change-line or
even a cloud: collapse.

As long as the set of commits was not published in another repository,
it's ok (you just loose the finer steps).

Post a reply to this message