
Hi friends! I love Haskell very much. So, I'm very interested in using Darcs. Is there some documentation explaining diffrences between Darcs and Git. Is there something that makes Darcs more robust rathen that Git. Does Darcs have some Emacs support (something like `magit`)? And one other question. Currently, I have no collaborators and use Git majorly myself to have version control, e.g. to revert some bad code, to have a nice log with code diffs and comments, and etc. But in future I will need something like GitHub for collaboration, is there a good solution for Darcs' hub already?

On Sat, Nov 14, 2015 at 07:28:27PM +0000, Geraldus wrote:
Hi friends!
I love Haskell very much. So, I'm very interested in using Darcs. Is there some documentation explaining diffrences between Darcs and Git. Is there something that makes Darcs more robust rathen that Git. Does Darcs have some Emacs support (something like `magit`)?
And one other question. Currently, I have no collaborators and use Git majorly myself to have version control, e.g. to revert some bad code, to have a nice log with code diffs and comments, and etc. But in future I will need something like GitHub for collaboration, is there a good solution for Darcs' hub already?
Hello Geraldus, I am a happy darcs user. I enjoy its basic philosophy much more than git one (patches vs. branches [1]); I do feel the user experience to be much smoother, too. There are darcs hosting services, one of them being darcs hub [2]. Or you can just upload the repository to your webspace and -presto- you are ready. I work like this [3] alongside with some barebone issue tracker [4] and I am pretty happy. [1] https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory [2] http://hub.darcs.net/ [3] http://www.ariis.it/link/repos/ [4] http://www.ariis.it/static/articles/lentil/page.html

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.
Which side, if either, of this does darcs land on?
On Sat, Nov 14, 2015, 13:45 Francesco Ariis
On Sat, Nov 14, 2015 at 07:28:27PM +0000, Geraldus wrote:
Hi friends!
I love Haskell very much. So, I'm very interested in using Darcs. Is there some documentation explaining diffrences between Darcs and Git. Is there something that makes Darcs more robust rathen that Git. Does Darcs have some Emacs support (something like `magit`)?
And one other question. Currently, I have no collaborators and use Git majorly myself to have version control, e.g. to revert some bad code, to have a nice log with code diffs and comments, and etc. But in future I will need something like GitHub for collaboration, is there a good solution for Darcs' hub already?
Hello Geraldus, I am a happy darcs user. I enjoy its basic philosophy much more than git one (patches vs. branches [1]); I do feel the user experience to be much smoother, too.
There are darcs hosting services, one of them being darcs hub [2].
Or you can just upload the repository to your webspace and -presto- you are ready. I work like this [3] alongside with some barebone issue tracker [4] and I am pretty happy.
[1] https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory [2] http://hub.darcs.net/ [3] http://www.ariis.it/link/repos/ [4] http://www.ariis.it/static/articles/lentil/page.html _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

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? Background: in practice, I found that git projects do not allow rewriting history that has been pulled for any coding. The changes can't be committed without rebasing, which is both somewhat advanced and potentially painful (due to merge conflicts), so it's actively avoided. There are variations such as setting aside repositories or branches for experimentation or patch preparation which may have their history rewritten, but that's just editing before the patch goes in, not a real history rewrite. So I think the difference is less relevant than most people think - but then maybe I'm overlooking something, so what's your take? Regards, Jo

On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz
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.
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. 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.

The best way to get a feel for how darcs is different is to just go use darcs for a while. The short version is that darcs is like jenga, where you can mess with things in the middle as long as no one else depends on them. Git is like towers of hanoi, where you have to do a bunch of juggling regardless. Or you could say git is like C, with a single well defined order of execution, and darcs is like haskell, where you often don't even think about order except as it's constrained by data dependency.

On 15 November 2015 at 09:37, Mike Meyer
On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz
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.
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. 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.
On the other hand, when accepting a PR, I don't want it to be full of lots of little "let's see if this worked; nope I need a second commit" messages cluttering up the git log: I recently had such a case where there were empty commits called "test commit", etc. Or in my own work, if I accidentally forgot to include a hunk in a commit I prefer to squash that change with the commit it was meant to be in rather than have an extra commit. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On 11/15/2015 02:31 AM, Ivan Lazar Miljenovic wrote:
On 15 November 2015 at 09:37, Mike Meyer
wrote: I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs are introduced. 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.
On the other hand, when accepting a PR, I don't want it to be full of lots of little "let's see if this worked; nope I need a second commit" messages cluttering up the git log: I recently had such a case where there were empty commits called "test commit", etc. Or in my own work, if I accidentally forgot to include a hunk in a commit I prefer to squash that change with the commit it was meant to be in rather than have an extra commit.
Yes -- this is one extremely important use case for rebase/squash. In git, the commit history is *not* meant for preserving "what happened". It's meant for humans to read when you're digging through change logs, perhaps because you're hunting a bug. I tend to find that people who want to preserve what happened have a different way of working where they tend to try to create good commits as they go whereas I (post-git) just create a bunch of "WIP" commits for almost every change regardless of whether it compiles or not and then clean up the "history" for readability once the full change is ready for pushing to the world. I used to be in the former group, but have found that moving to the in the latter workflow is incredibly liberating. It means that I don't waste nearly as much time checking that everything compiles (etc.) for every little change I make. I just check all that stuff for the final series of commits. "Patch theory" is all well and good, but it's missing the point, IMO. Tools *must* have a manual override for when the user knows best[1] and that also means adapting to *my* workflow rather than me having to constantly think mind "should I commit now?", "which order do I need to do my refactoring in to get small reviewable commits?", etc. With git, it's very rare to have to think about this. Now, we've talked about squashing, but I also find that *splitting* commits to be hugely valueable in that you can often (post-working-frenzy) split everything into neat, logically coherent easily reviewable commits/chunks. Absent strong AI, no "patch theory" can do this since it's not a technical problem. That's what I like about Git -- it works on *my* terms rather than its terms. (Yeah, the UI isn't exactly great[1], but once you're over the learning curve the UX *is*, IMO.) Regards, [1] If you're an emacs user: Use "magit" it's incredible. Maybe even worth learning emacs for.

(Sorry about the self-reply -- just wanted to clarify a bit:) On 11/15/2015 07:40 AM, Bardur Arantsson wrote:
That's what I like about Git -- it works on *my* terms rather than its terms. (Yeah, the UI isn't exactly great[1], but once you're over the learning curve the UX *is*, IMO.)
I also tend to find that some of the UX advantages are actually *predicated* on doing lots of commits all the time. For example, if you're committing every 5 minutes or so, then it's extremely easy to just rewind to a prior point in your work (git reset --hard HEAD~n) if you find yourself in a dead end. Likewise, if you find that you've done a bad "git reset --hard" or a bad rebase you can just dig out the old hash from "git reflog" and reset to that. If you commit often, none of this will result in losing significant amounts of work. Regards,

On 15 November 2015 at 17:40, Bardur Arantsson
[1] If you're an emacs user: Use "magit" it's incredible. Maybe even worth learning emacs for.
Actually, I would argue that using magit is worth learning/using git for ;-) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On Sun, Nov 15, 2015 at 07:40:16AM +0100, Bardur Arantsson wrote:
"Patch theory" is all well and good, but it's missing the point, IMO. Tools *must* have a manual override for when the user knows best and that also means adapting to *my* workflow rather than me having to constantly think mind "should I commit now?", "which order do I need to do my refactoring in to get small reviewable commits?", etc. With git, it's very rare to have to think about this.
Fairly recently (v2.10.0) darcs introduced `suspend` and `unsuspend`, when you want to modify stuff deep down in the repo (a patch that depends on one or more other patches, etc. - see this blog post [1]). I seldom use it as cherry-picking with darcs is easy, but those times I was really glad to have had the option. [1] https://parenz.wordpress.com/2015/07/28/darcs-rebase-by-example/

On Sun, Nov 15, 2015 at 12:40 AM Bardur Arantsson
I tend to find that people who want to preserve what happened have a different way of working where they tend to try to create good commits as they go whereas I (post-git) just create a bunch of "WIP" commits for almost every change regardless of whether it compiles or not and then clean up the "history" for readability once the full change is ready for pushing to the world. I used to be in the former group, but have found that moving to the in the latter workflow is incredibly liberating. It means that I don't waste nearly as much time checking that everything compiles (etc.) for every little change I make. I just check all that stuff for the final series of commits.
Well, I want to preserve history but tend to commit whenever it's convenient as well. This started when I moved to perforce - because branches are cheap, so just create them whenever you need one,and make sure what you merge compiles. So I branched whenever I thought a change would take more than a single session - and finished with mercurial, where all work happens on what's essentially a branch anyway, with push as merge. I agree, it's critical to have a tool that adopts to your workflow, but it's also important that other people don't break your workflow, because like languages the claim of "if you don't like it, just don't use it" is bullshit. So while mercurial has "rebase" so you can use it if you need it, it's disabled by default and flagged as being for expert use, not something that's part of the daily workflow.

On 11/15/2015 03:53 PM, Mike Meyer wrote:
On Sun, Nov 15, 2015 at 12:40 AM Bardur Arantsson
wrote: I agree, it's critical to have a tool that adopts to your workflow, but it's also important that other people don't break your workflow, because like languages the claim of "if you don't like it, just don't use it" is bullshit. So while mercurial has "rebase" so you can use it if you need it, it's disabled by default and flagged as being for expert use, not something that's part of the daily workflow.
I think I can the number of times my workflow has been "broken" by others rebasing on approximately zero hands :). It just isn't an issue in practice. (Maybe I've just been lucky, who knows?) Regards,

Am 15.11.2015 um 16:01 schrieb Bardur Arantsson:
On 11/15/2015 03:53 PM, Mike Meyer wrote:
On Sun, Nov 15, 2015 at 12:40 AM Bardur Arantsson
wrote: I agree, it's critical to have a tool that adopts to your workflow, but it's also important that other people don't break your workflow, because like languages the claim of "if you don't like it, just don't use it" is bullshit.
It's bullshit in a codebase. Doesn't mean it's bullshit everywhere else. You'll need to name a concrete problem to drive that specific point home.
So while mercurial has "rebase" so you can use it if you need it, it's disabled by default and flagged as being for expert use, not something that's part of the daily workflow.
I think I can the number of times my workflow has been "broken" by others rebasing on approximately zero hands :).
It just isn't an issue in practice. (Maybe I've just been lucky, who knows?)
I guess I was lucky, too :-) It can affect code reviews. OTOH that's something that reviewer and submitter can agree to without affecting other people's work. Regards, Jo

On Sun, Nov 15, 2015 at 9:46 AM Joachim Durchholz
It can affect code reviews. OTOH that's something that reviewer and submitter can agree to without affecting other people's work.
If your review tools won't let you review changes in the format you prefer, that's an issue with the review tools, not the version control system.

Well, thank you all, pals! I'll try darcs in near future. As for me I try to make each commit to present a project's state which compiles; I like when commit have a description with easy to follow diffs (so all staged chages should be logically connected). Sometimes I'm squashing minor commits into larger one. The worst disadvantage is that I got used to `magit` very much. Is there anyone who tried (or thought at least) to implement something similar for Darcs?

On 16 November 2015 at 04:27, Geraldus
Well, thank you all, pals! I'll try darcs in near future.
As for me I try to make each commit to present a project's state which compiles; I like when commit have a description with easy to follow diffs (so all staged chages should be logically connected). Sometimes I'm squashing minor commits into larger one.
The worst disadvantage is that I got used to `magit` very much. Is there anyone who tried (or thought at least) to implement something similar for Darcs?
There's darcsum, which gives you the interactive hunk selection for creating a patch. But it doesn't have the ability to push/pull inside of Emacs, so you still need a terminal open for that. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On 11/15/15 12:57 PM, Ivan Lazar Miljenovic wrote:
On 16 November 2015 at 04:27, Geraldus
wrote: The worst disadvantage is that I got used to `magit` very much. Is there anyone who tried (or thought at least) to implement something similar for Darcs?
There's darcsum, which gives you the interactive hunk selection for creating a patch. But it doesn't have the ability to push/pull inside of Emacs, so you still need a terminal open for that.
It should be a very easy thing to add. darcsum needs a maintainer/developer, contact me if you're interested.

Am 15.11.2015 um 16:52 schrieb Mike Meyer:
On Sun, Nov 15, 2015 at 9:46 AM Joachim Durchholz
wrote: It can affect code reviews. OTOH that's something that reviewer and submitter can agree to without affecting other people's work.
If your review tools won't let you review changes in the format you prefer, that's an issue with the review tools, not the version control system.
Did you ever work with git, or any SCM that allows history edits? Because that wasn't a question of review tools at all, and while I can understand the discomfort around editing history, it is not something that one can reliably judge from hearsay and theory, you need to have seen it in action. Regards, Jo

Yes, I work with git on a regular basis. I'm not likely to have been asked
to compress my commits if I hadn't done so.
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. There
review tools, on the other hand, are sorry of crucial to them.
On Sun, Nov 15, 2015, 11:50 Joachim Durchholz
On Sun, Nov 15, 2015 at 9:46 AM Joachim Durchholz
wrote: It can affect code reviews. OTOH that's something that reviewer and submitter can agree to without affecting other people's work.
If your review tools won't let you review changes in the format you
Am 15.11.2015 um 16:52 schrieb Mike Meyer: prefer,
that's an issue with the review tools, not the version control system.
Did you ever work with git, or any SCM that allows history edits?
Because that wasn't a question of review tools at all, and while I can understand the discomfort around editing history, it is not something that one can reliably judge from hearsay and theory, you need to have seen it in action.
Regards, Jo _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Am 15.11.2015 um 18:54 schrieb Mike Meyer:
Yes, I work with git on a regular basis. I'm not likely to have been asked to compress my commits if I hadn't done so.
Oh. Right. My apologies.
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).

On Sun, Nov 15, 2015 at 12:10 PM Joachim Durchholz
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. Yes, the DVCS can make them harder if it doesn't support them, but that's case of picking a tool that doesn't support your workflow, which I think we all agree is a bad idea. 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. 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? 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.

Am 16.11.2015 um 18:36 schrieb Mike Meyer:
On Sun, Nov 15, 2015 at 12:10 PM Joachim Durchholz
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

On Mon, Nov 16, 2015 at 12:11 PM Joachim Durchholz
Am 16.11.2015 um 18:36 schrieb Mike Meyer: 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,
Accuracy. Having watched the soviets change their history texts with each regime, it bothers me to see history changed. If people actually read and/or otherwise examined these "carefully crafted change logs" on a regular basis, I might feel otherwise. But I never look at them unless I'm chasing a bug, and as far as I can tell, nobody else does either. So spending time editing history is not only mostly wasted effort, it may well cause problems for the only use. I don't have any actual proof that this is the case, but I haven't seen any for any other position, either. If you've got it, I'd certainly be interested in reading it.
I just hope that you can accept that other people greatly prefer a log which has been geared towards better reviewability.
Oh, I don't have a problem doing that. But I expect the same courtesy in return. In particular, If I choose to donate my work to your project, you'll not ask me to change my clone of your repo to meet your expectations, but modify the change log as you pull it to meet your standards. If that's a hoop you insist contributors jump through, that's cool. I'll stop submitting them. It's not like I lack things to do.

Am 16.11.2015 um 19:32 schrieb Mike Meyer:
On Mon, Nov 16, 2015 at 12:11 PM Joachim Durchholz
wrote: Am 16.11.2015 um 18:36 schrieb Mike Meyer: 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,
Accuracy. Having watched the soviets change their history texts with each regime, it bothers me to see history changed.
I can understand the sentiment, but neither reasons nor consequences seem comparable. The Soviets edited history to falsify it. SCM history editing is to make it easier to understand, not to falsify it. Actually the work of any historian is a rewrite if you will.
If people actually read and/or otherwise examined these "carefully crafted change logs" on a regular basis, I might feel otherwise.
Believe me, they do. Been there, done that. Particularly to find out why underdocumented parts of the code were introduced, what parts of it were intentional and what parts accidental, and whom to ask about specific parts of the code. You really need to know that for any major clean-up in a code base that has become messy, as is inevitable over time. Having an extensive history of merge commits pushed that job from "hard" to "not doable" for me, and more than once. Regards, Jo

El 16 nov 2015, a las 13:32, Mike Meyer
escribió: On Mon, Nov 16, 2015 at 12:11 PM Joachim Durchholz
wrote: Am 16.11.2015 um 18:36 schrieb Mike Meyer: 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, Accuracy. Having watched the soviets change their history texts with each regime, it bothers me to see history changed. If people actually read and/or otherwise examined these "carefully crafted change logs" on a regular basis, I might feel otherwise. But I never look at them unless I'm chasing a bug, and as far as I can tell, nobody else does either. So spending time editing history is not only mostly wasted effort, it may well cause problems for the only use. I don't have any actual proof that this is the case, but I haven't seen any for any other position, either. If you've got it, I'd certainly be interested in reading it.
I just hope that you can accept that other people greatly prefer a log which has been geared towards better reviewability.
Oh, I don't have a problem doing that. But I expect the same courtesy in return. In particular, If I choose to donate my work to your project, you'll not ask me to change my clone of your repo to meet your expectations, but modify the change log as you pull it to meet your standards. If that's a hoop you insist contributors jump through, that's cool. I'll stop submitting them. It's not like I lack things to do.
"git merge --squash" is what you can use to satisfy both the person who wants a clean commit and the person who wants an accurate history log -- you can use it to create a single commit that's the sum of all changes on another branch, and now you're only creating a new branch instead of rewriting the old one. tom
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

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
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

On Sat, Nov 14, 2015 at 08:10:47PM +0000, Mike Meyer wrote:
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.
Which side, if either, of this does darcs land on?
darcs has some tools to "rebase". I would say they are seldom used in a typical workflow (for sure less than what I saw in typical git usage), but they are there.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Pertaining to darcs: is there a nice way to verify integrity yet? In git you can OpenPGP sign commits and tags. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWSbYxAAoJENQqWdRUGk8B2hwQANwgvk66ku+lV2K1qKxLpQ4o LB6SBgbMSmH75pzfXUQ6+FDyx+1169vOgScmhi5nyOCii1BEHab3lUOr6fzKvq5H Ph4azgm1I7tmjEBcmdoVqoNhpKDiCJC+2nf7s3VoSjWJ392+7W9F7UuQ/Ze6pLLu uX6Hwdors7+zGvmxN5YEL20Mr5BXOrkdvJV+eiyM0WmWEcftCDyrTfyysQ8sjM+K P2SPIxdawwJ3lN14rvcgtGDk0Wd8aJrPxJNPKcttDBCeICzNsKPriaMSqHGWzvZi 3L3iEi49iwchC5AVKA+syKzPiT8OAlSb3TK2O+6ajfuzefghX8490cuHF0YxE6ks ZDY6GMB0NiUkvQOzoUfAu1Fu0voNLSruY1WJf/2KpAfWz0LYvCjiwCjing2L2IMV PnKWzgw9zuPTm0sh9KxRHOGNHxjyHW5HR58dsyaLrD+Sy9U6LGjcdVDXkrzl4CxK +0n2qq9btqdRdw0Dk3//mjO4yTlfWhEnMarSp4MvawvG4TY/gik+ueTtJZnGrWKW jSJ/b7Ck6EkOHDYLl8O11I6MjjxapcJ2kMm0ENxiUflhV24/JVH1+cUyCyq0UnfH KwNiqhGjCApGiTndJKrUybLRSxy16iHygivbHPoRZqNHVkcMwrmcmswW1K7AqzPp WfN5oapy2xCUQQ/MMGrf =dwOz -----END PGP SIGNATURE-----
participants (10)
-
Alexander Berntsen
-
amindfv@gmail.com
-
Bardur Arantsson
-
Evan Laforge
-
Francesco Ariis
-
Geraldus
-
Ivan Lazar Miljenovic
-
Joachim Durchholz
-
Mike Meyer
-
Simon Michael