[Haskell-cafe] Darcs vs Git

Joachim Durchholz jo at durchholz.org
Sun Nov 15 07:15:43 UTC 2015


Am 14.11.2015 um 23:37 schrieb Mike Meyer:

(Aside: Please "reply to list", "reply to all" massages the headers in a 
way that my own "reply to list" does not work anymore. I don't need a 
personal copy anyway.)

> On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz <jo at durchholz.org> wrote:
>
>> Am 14.11.2015 um 21:10 schrieb Mike Meyer:
>>> Since we're talking about this, ones is the reasons I dislike for is that
>>> it treats the project history just like any other prolix public document,
>>> providing tools for modifying it, changing it as you push or pull, etc. I
>>> disagree with this, and prefer tools that believe that history should be
>>> immutable, like hg and fossil.
>> Just curious: Why?
>
> Philosophical. I want history to reflect the way things actually happened.

Things actually happen in the editors of contributors, which isn't 
committed. Not even all of what you write to disk is ever committed. So 
even without history rewrites, history does not reflect what actually 
heppened.
The only difference is that git allows you to version control your local 
scratchpad.

Also, philosophically, git never rewrites history; you create a new 
history and label it with an existing branch name.
(The original branch is not automatically preserved or shown, but it's 
still there; just give it a branch name, it's as easy as "git branch 
<archival-branch-name>" before working on the new history.)

>> So I think the difference is less relevant than most people think - but
>> then maybe I'm overlooking something, so what's your take?
>
> I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs
> are introduced.

git history may be changed, but it cannot be made inconsistent.
So if the tip of a branch contains a bug, git enforces that the 
introduction of that bug is in the history, including proper attribution 
(unless somebody commited in lieu of somebody else, which is something 
that no SCM can prevent).

 > But that's minor to not wanting history hidden. I even had
> someone ask that I collapse a bunch of changes when I pushed them to my
> github repo before creating a PR. Not going to happen.

As Bardur wrote, it can make the history easier to review.
Which is important for reviews.

What's the original history significant for?
I haven't seen a use case for that. And philosophical or no, 
down-to-earth practial consequences beat philosophy any day. 
("Philosophy" typically indicates subconscious reasoning. Which can 
still be important, but unless you can bring them to conscious thinking 
and verbalize them, we won't know these reasons and cannot integrate 
them into our own thinking.)

Regards,
Jo


More information about the Haskell-Cafe mailing list