4 ms·

> Knowing what not to put in is sometimes the best way to keep good code. What does that have to do with exposing a read only versioned history? Nobody is aski

by ef4 12y ago

> Knowing what not to put in is sometimes the best way to keep good code. What does that have to do with exposing a read only versioned history? Nobody is asking him to give the whole world commit privileges.

meepmorp 12y ago
There is an existing, available source of read only versioned history, available online for anyone to see: ftp://ftp.porcupine.org/mirrors/postfix-release/index.html It's tarballs for each release, with associated patches for each release. That's a pretty complete read only versioned history. Why does it have to be a VCS?
- ef4 12y ago
  Because that history is way too coarse to answer the kind of questions that a VCS can answer. And because they already have a VCS, and are just stubbornly unwilling to share all that useful information with the wider community.
  - meepmorp 12y ago
    What questions do you need to answer at a finer level of granularity? Is it really critical to know that someone fixed a typo in something day over day, but that the typo wasn't included in any releases? I get that this clashes with the culture you're used to working in, but I don't see where it's actually impactful in a real world sense. edit: a slight rewording
    - ef4 12y ago
      I search through other people's commit histories all the time. Commit logs are by far the most thorough documentation you'll find in the typical codebase. Not for the big things that appear in changelogs, but for the little things like "why the heck does this line work that way?" Giving Weitse the benefit of the doubt, his commit logs are probably very useful indeed, and not sharing them makes the codebase that much less useful to everyone else. Edit to add: the canonical example is bisection. When something breaks, it is awesome to bisect it down to the precise change that broke it. Bisection lets you narrow the scope down to a vastly smaller problem space than a whole release would.
- jacobgreenleaf 12y ago
  How are you going to view the diff between more than two temporally adjacent commits? Or find the commit upon which an arbitrary line of source code was added? Or x, or y, or z reasons that are so painfully easy to enumerate?
watson 12y ago
I feel many people in here don't actually read the entire post. It mentions several times that there is a VCS. It even gives a link: https://github.com/vdukhovni/postfix https://github.com/vdukhovni/postfix

by ef4 12y ago

meepmorp 12y ago

There is an existing, available source of read only versioned history, available online for anyone to see: ftp://ftp.porcupine.org/mirrors/postfix-release/index.html It's tarballs for each release, with associated patches for each release. That's a pretty complete read only versioned history. Why does it have to be a VCS?

ef4 12y ago
Because that history is way too coarse to answer the kind of questions that a VCS can answer. And because they already have a VCS, and are just stubbornly unwilling to share all that useful information with the wider community.
- meepmorp 12y ago
  What questions do you need to answer at a finer level of granularity? Is it really critical to know that someone fixed a typo in something day over day, but that the typo wasn't included in any releases? I get that this clashes with the culture you're used to working in, but I don't see where it's actually impactful in a real world sense. edit: a slight rewording
  - ef4 12y ago
    I search through other people's commit histories all the time. Commit logs are by far the most thorough documentation you'll find in the typical codebase. Not for the big things that appear in changelogs, but for the little things like "why the heck does this line work that way?" Giving Weitse the benefit of the doubt, his commit logs are probably very useful indeed, and not sharing them makes the codebase that much less useful to everyone else. Edit to add: the canonical example is bisection. When something breaks, it is awesome to bisect it down to the precise change that broke it. Bisection lets you narrow the scope down to a vastly smaller problem space than a whole release would.
jacobgreenleaf 12y ago
How are you going to view the diff between more than two temporally adjacent commits? Or find the commit upon which an arbitrary line of source code was added? Or x, or y, or z reasons that are so painfully easy to enumerate?

watson 12y ago

I feel many people in here don't actually read the entire post. It mentions several times that there is a VCS. It even gives a link: https://github.com/vdukhovni/postfix https://github.com/vdukhovni/postfix