5 ms·

I don't know if I am your target audience, but it seems like it's doing a whole lot more than most people would need. I feel like there is huge value in versio

I don't know if I am your target audience, but it seems like it's doing a whole lot more than most people would need. I feel like there is huge value in version control that supports various binaries with custom diff support. Perforce, git-lfs, etc. offer binary version control, but not custom and useful diff tooling per binary type. Kaleidoscope, Beyond Compare, etc. offer some improved diff tooling, but not for a wide variety of file types. That seems like it would be the essence of a product like this. I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS.

jsunderland323 3y ago
I think you're probably correct that you likely aren't the target audience here. Version control is a loaded term. This would be a terrible replacement for perforce or anything for diffing something like a CAD file. The real focus of the system is for things that are better managed by people who aren't engineers but end up interfacing with code very tightly. The idea was to focus on the peripheral functions that come up in UI engineering and enable e.g. translators, copy editors, and designers to essentially commit to a codebase without having to understand git or know how to handle plaint text merge conflicts. > I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS. I totally agree. You can modify the output to your hearts desire. This was a big part of our design.
IshKebab 3y ago
Git does support custom diffing algorithms and tools.
- jsunderland323 3y ago
  It does but it can't support cascading states. I kind of explain this at the bottom of this page https://floro.io/technical-overview-part-2 https://floro.io/technical-overview-part-2
  - jFriedensreich 3y ago
    i did not understand what a cascading merge is after reading this twice. if you have a git threeway merge and a merge tool that can parse and merge all three filestates what exactly would your solution solve that the git one cannot?
    - jsunderland323 3y ago
      I'll try to contextualize it in the case of something like AST merging so it's more familiar. Imagine you have file A and file B. In one change someone adds some code that imports something from file B into file A. In another change someone deletes file B without touching file A. That will result in a valid three-way merge. However, your compiler will complain and you will have to update file A to remove the references to file B. This is okay because you can edit the plain-text and fix the inconsistency. This doesn't work for things where you can't really hop in and manually fix the conflict. You could definitely create a tool that understand the AST and knows how to remove stale references. If you add in the requirement that there cannot be inconsistent states at any commit you've essentially derived an entirely new merging system. Could you build this on top of git? Sure, it's a plain-text system, you could build anything on top it. Is there any gain if the point of the system is to disallow manual conflict resolution and enforce consistent state? I don't think so but maybe I'm not seeing something.
      - IshKebab 3y ago
        But can't you have a custom merge driver for 3 way merges too? So that when you try to merge the changes it does complain? The advantage of building this on top of Git is fairly obvious: you get to use all the existing Git tooling, and you can use Git for other files in the repo that don't need special merge drivers.
        jsunderland323 3y ago
        > But can't you have a custom merge driver for 3 way merges too? So that when you try to merge the changes it does complain? You kind of could, at least for diffing. This is what difftastic does https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/. Merging is really ambiguous in what the intended behavior of a removed reference is in AST. Do you delete or nullify or something else? How does that affect other upstream references? I'm not sure you'll ever find a satisfying answer there but floro is constrained to static assets, which are a bit more predictable. > The advantage of building this on top of Git is fairly obvious: you get to use all the existing Git tooling, and you can use Git for other files in the repo that don't need special merge drivers. So I think there is some confusion here in how this interfaces with code and I'm sorry I didn't think to explain this first. With floro you have a file in your git repository that points to a sha from floro to generate your assets from. Here's an example https://github.com/florophore/floro-react-native-demo/blob/main/floro_infra/meta.floro.json https://github.com/florophore/floro-react-native-demo/blob/m... I think of it sort of like having a package.json and a lockfile. You don't check your dependencies into git because odds are you don't want to deal with merge conflicts in third party dependencies, just the package.json and lockfile. Similarly you wouldn't want to deal with the conflicts of floro in a git repo. So you do still you get to use all the existing Git tooling with respect to your codebase. The problem really is that git would allow for inconsistent states, which is fine for programmers but tough for anyone who doesn't know how to resolve the inconsistencies.

jsunderland323 3y ago

I think you're probably correct that you likely aren't the target audience here. Version control is a loaded term. This would be a terrible replacement for perforce or anything for diffing something like a CAD file. The real focus of the system is for things that are better managed by people who aren't engineers but end up interfacing with code very tightly. The idea was to focus on the peripheral functions that come up in UI engineering and enable e.g. translators, copy editors, and designers to essentially commit to a codebase without having to understand git or know how to handle plaint text merge conflicts. > I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS. I totally agree. You can modify the output to your hearts desire. This was a big part of our design.

IshKebab 3y ago

Git does support custom diffing algorithms and tools.

jsunderland323 3y ago
It does but it can't support cascading states. I kind of explain this at the bottom of this page https://floro.io/technical-overview-part-2 https://floro.io/technical-overview-part-2
- jFriedensreich 3y ago
  i did not understand what a cascading merge is after reading this twice. if you have a git threeway merge and a merge tool that can parse and merge all three filestates what exactly would your solution solve that the git one cannot?
  - jsunderland323 3y ago
    I'll try to contextualize it in the case of something like AST merging so it's more familiar. Imagine you have file A and file B. In one change someone adds some code that imports something from file B into file A. In another change someone deletes file B without touching file A. That will result in a valid three-way merge. However, your compiler will complain and you will have to update file A to remove the references to file B. This is okay because you can edit the plain-text and fix the inconsistency. This doesn't work for things where you can't really hop in and manually fix the conflict. You could definitely create a tool that understand the AST and knows how to remove stale references. If you add in the requirement that there cannot be inconsistent states at any commit you've essentially derived an entirely new merging system. Could you build this on top of git? Sure, it's a plain-text system, you could build anything on top it. Is there any gain if the point of the system is to disallow manual conflict resolution and enforce consistent state? I don't think so but maybe I'm not seeing something.
    - IshKebab 3y ago
      But can't you have a custom merge driver for 3 way merges too? So that when you try to merge the changes it does complain? The advantage of building this on top of Git is fairly obvious: you get to use all the existing Git tooling, and you can use Git for other files in the repo that don't need special merge drivers.
      - jsunderland323 3y ago
        > But can't you have a custom merge driver for 3 way merges too? So that when you try to merge the changes it does complain? You kind of could, at least for diffing. This is what difftastic does https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/. Merging is really ambiguous in what the intended behavior of a removed reference is in AST. Do you delete or nullify or something else? How does that affect other upstream references? I'm not sure you'll ever find a satisfying answer there but floro is constrained to static assets, which are a bit more predictable. > The advantage of building this on top of Git is fairly obvious: you get to use all the existing Git tooling, and you can use Git for other files in the repo that don't need special merge drivers. So I think there is some confusion here in how this interfaces with code and I'm sorry I didn't think to explain this first. With floro you have a file in your git repository that points to a sha from floro to generate your assets from. Here's an example https://github.com/florophore/floro-react-native-demo/blob/main/floro_infra/meta.floro.json https://github.com/florophore/floro-react-native-demo/blob/m... I think of it sort of like having a package.json and a lockfile. You don't check your dependencies into git because odds are you don't want to deal with merge conflicts in third party dependencies, just the package.json and lockfile. Similarly you wouldn't want to deal with the conflicts of floro in a git repo. So you do still you get to use all the existing Git tooling with respect to your codebase. The problem really is that git would allow for inconsistent states, which is fine for programmers but tough for anyone who doesn't know how to resolve the inconsistencies.