4 ms·

Darcs (and Pijul?) can support more patch types than textual diffs, but I doubt much use has ever been made of that. I don't know about the more general case,

by gnufx 5y ago

Darcs (and Pijul?) can support more patch types than textual diffs, but I doubt much use has ever been made of that. I don't know about the more general case, but it supports the extra type now for identifier replacement, at least as basically s/x/y/g. (One place where another type might be useful is changelogs, but I never looked at what that might take.) The Toolpack tool set for Fortran from the '80s was based around parse trees and had a VCS, but I don't remember whether that actually operated on trees or just text.

jayd16 5y ago
git can support different diff/merge tools. I just wish more of gits configuration could be added to the repo itself. As it is, if you needed a custom merge tool (like UnityYamlMerge) you need each user to configure it separately. The consequence is every contributor needs to know enough about every file type in the repo to know if a custom merge tool should be add/updated. You might get surprised with a merge conflict in a filetype you never touched if you happen to be the one merging down feature branches. Hopefully some of this stuff and default client githooks are fixed one day. Seems easy enough to add a "suggested project config" to git.
- fiddlerwoaroof 5y ago
  The problem is those merge tool configurations are all security holes. Also, I get annoyed whenever something (like husky) messes with my git configuration: like editor customizations, I have a certain git workflow and I dislike projects that disrupt it.
  - jayd16 5y ago
    Sure, I don't think it should be more than a suggestion you can vet yourself but I would like the process to be automated once approved.
- morelisp 5y ago
  Defining the drivers themselves needs to be done outside the repo as letting the repo run arbitrary commands is a security hole, but which merge/diff drivers appliy to which files can be done in the gitattributes file, and that does work in-repo.
  - jayd16 5y ago
    >security hole Its really not that hard to imagine how you can do this in a secure way. Git has identity and signatures built in. Maybe only updates from trusted users are considered, and you still must agree to the updates, etc etc. Throwing up our hands and saying its impossible seems like a terrible choice.
    - morelisp 5y ago
      If you're going to make me manually agree to the updates, you may as well just have me run a script manually. I'm not saying it's impossible! I'm saying it's pointless. Trust people set up their own config given tools and instructions, and they might even surprise you by coming up with a better workflow.
      - jayd16 5y ago
        Third party tooling could interface with something built in but not the one off scripts people use now. I'm not trying to be draconian here. I just want a built in way to share needed configuration information that we have to special case now.
        morelisp 5y ago
        Third-party tooling already interfaces with hooks/merge config without having to check them in. You put the script that does it in the repo, and you ask users to run the script on checkout.
        jayd16 5y ago
        I want exactly this but with an official format.
dan-robertson 5y ago
Darcs could have some slightly crazy patches like replace-regexp, but to be honest I don’t think that works so well on a large codebase. The problem I’ve had so far thinking about structural patches is that they need to capture several weird kinds of edit that imply that the patch cannot simply mirror the tree structure of the file. Some examples of tree patches (using sexps to show the tree structure): (A B C) -> (A B B2 C) (A B C) -> (let ((b B)) (A b C)) ((A B) (C D)) -> ((A B C D)) ((A B C D)) -> ((A B) X (C D)) (F X (G Y)) -> (G Y) Specifically it is operations like splitting, merging, raising, lowering, and reordering that can cause problems with computational and logical complexity. If you look at the model for pijul, it goes: 1. A file is a totally ordered set of lines (or other atoms), some of which are marked as “deleted” 2. We consider a patch to be a map from one file to another, taking lines that don’t change to their counterparts, deleted lines to “deleted” lines, and changed lines to their new versions. The map must respect the order by being strictly increasing 3. We now generalise to allow for merges (and merge conflicts) by changing total order to partial order (it is a conflict where the ordering is not total) and patches are increasing maps. It is hard to me to see how such a thing would extend to tree-structured files. But other Brooke online seem more confident so maybe I’m wrong.

by gnufx 5y ago

jayd16 5y ago

git can support different diff/merge tools. I just wish more of gits configuration could be added to the repo itself. As it is, if you needed a custom merge tool (like UnityYamlMerge) you need each user to configure it separately. The consequence is every contributor needs to know enough about every file type in the repo to know if a custom merge tool should be add/updated. You might get surprised with a merge conflict in a filetype you never touched if you happen to be the one merging down feature branches. Hopefully some of this stuff and default client githooks are fixed one day. Seems easy enough to add a "suggested project config" to git.

fiddlerwoaroof 5y ago
The problem is those merge tool configurations are all security holes. Also, I get annoyed whenever something (like husky) messes with my git configuration: like editor customizations, I have a certain git workflow and I dislike projects that disrupt it.
- jayd16 5y ago
  Sure, I don't think it should be more than a suggestion you can vet yourself but I would like the process to be automated once approved.
morelisp 5y ago
Defining the drivers themselves needs to be done outside the repo as letting the repo run arbitrary commands is a security hole, but which merge/diff drivers appliy to which files can be done in the gitattributes file, and that does work in-repo.
- jayd16 5y ago
  >security hole Its really not that hard to imagine how you can do this in a secure way. Git has identity and signatures built in. Maybe only updates from trusted users are considered, and you still must agree to the updates, etc etc. Throwing up our hands and saying its impossible seems like a terrible choice.
  - morelisp 5y ago
    If you're going to make me manually agree to the updates, you may as well just have me run a script manually. I'm not saying it's impossible! I'm saying it's pointless. Trust people set up their own config given tools and instructions, and they might even surprise you by coming up with a better workflow.
    - jayd16 5y ago
      Third party tooling could interface with something built in but not the one off scripts people use now. I'm not trying to be draconian here. I just want a built in way to share needed configuration information that we have to special case now.
      - morelisp 5y ago
        Third-party tooling already interfaces with hooks/merge config without having to check them in. You put the script that does it in the repo, and you ask users to run the script on checkout.
        jayd16 5y ago
        I want exactly this but with an official format.

dan-robertson 5y ago

Darcs could have some slightly crazy patches like replace-regexp, but to be honest I don’t think that works so well on a large codebase. The problem I’ve had so far thinking about structural patches is that they need to capture several weird kinds of edit that imply that the patch cannot simply mirror the tree structure of the file. Some examples of tree patches (using sexps to show the tree structure): (A B C) -> (A B B2 C) (A B C) -> (let ((b B)) (A b C)) ((A B) (C D)) -> ((A B C D)) ((A B C D)) -> ((A B) X (C D)) (F X (G Y)) -> (G Y) Specifically it is operations like splitting, merging, raising, lowering, and reordering that can cause problems with computational and logical complexity. If you look at the model for pijul, it goes: 1. A file is a totally ordered set of lines (or other atoms), some of which are marked as “deleted” 2. We consider a patch to be a map from one file to another, taking lines that don’t change to their counterparts, deleted lines to “deleted” lines, and changed lines to their new versions. The map must respect the order by being strictly increasing 3. We now generalise to allow for merges (and merge conflicts) by changing total order to partial order (it is a conflict where the ordering is not total) and patches are increasing maps. It is hard to me to see how such a thing would extend to tree-structured files. But other Brooke online seem more confident so maybe I’m wrong.