[Haskell-cafe] Darcs vs Git

[Joachim Durchholz]

Am 16.11.2015 um 18:36 schrieb Mike Meyer:
> On Sun, Nov 15, 2015 at 12:10 PM Joachim Durchholz <jo at durchholz.org> wrote:
>
>> Am 15.11.2015 um 18:54 schrieb Mike Meyer:
>>
>
>
>>> You talked about issues during a code review. I've never seen a review
>>> process that was really affected by the source code control system.
>>
>> If a history rewrite is tacked on at the end of a review process, that
>> means another round of review.
>> I agree that the SCM tool and the way it's being used wouldn't affect
>> individual reviews, it's the overall process that can be affected (you
>> could avoid that by doing the history rewrite as early as possible,
>> preferrably before starting formal review if the project has that).
>
> Um, I don't see how choice of a DVCS affects when you do history rewrites.

Oh, they do. Some SCMs are written with a specific workflow in mind and 
will become difficult if you use a different one; SVN is a case in 
point, I hear Mercurial is geared towards specific workflows, too, but 
then that's just hearsay.
Others allow many different workflows and you choose. The above 
paragraph was about what choices you have with git.

> And you saying history rewrites trigger another round of code reviews just
> reinforces my worries that such rewrites might be quietly introducing
> issues that need to be worried about, and hence the best way to avoid that
> extra round of reviews is to not do history rewrites.

You didn't see the alternative of doing history rewrites just locally, 
before the patch hits any official repo.

> Like I said originally, this is a philosophy issue: do you believe the
> point of the code review is to preserve history as it actually happened, or
> as you wish it had happened?

False alternatives.

It's not about history, it's about a log of changes. Which changes - 
that's the project's choice, it could be fully history of everything or 
it could be a carefully crafted change log that serves entirely 
different purposes than recording history.

I still do not understand why you think that history outweighs all other 
considerations.

 > Your repository is yours, and I don't have
> issues with you using it for whatever you want to - you're a step ahead of
> a lot of places in that you have one at all! It's when you start wanting to
> change the way I use mine - by, for instance, asking me to edit it's
> history on a pull request instead of doing it when you merge the request -
> that I have issues.

*shrug* if it's your project, it's your decision.
If you're contributing to somebody else's project, it's their decision 
whether they want to accept the full history, including fixup commits 
and intermingled parallel work, or whether they want small, 
topic-centered commits that have been pulled together from the local, 
historic stream of workspace commits.

I haven't seen you argue what purpose a full history might actually 
have, so I still can't say what value you see in the "full history" 
approach, but ah well - sometimes it's hard to verbalize such feelings, 
so I'm not going to insist on an explanation.
I just hope that you can accept that other people greatly prefer a log 
which has been geared towards better reviewability. After all, we can't 
simply adopt your view just because it's "philosophy" - philosophy can 
help to validate and verify that a given workflow does what it's 
supposed to, but philosophy cannot define goals and desirables.

Regards,
Jo