7 ms·

I think part of the problem is it seems everyone is trying to make a version control tool that is agnostic to all languages. Both computationally and UI wise. B

I think part of the problem is it seems everyone is trying to make a version control tool that is agnostic to all languages. Both computationally and UI wise. But C++ users expect to see different things than JavaScript users and so forth. I’m surprised at the lack of hyper-specific language version control tools. I thought about making a side project for one in Julia a while back but not quite sure how it would look. Some random thoughts: - info on type, name, constant changes - let me checkout older revisions of individual functions / objects / whatever - on unit test result changes for functions that have unit tests - when changes are simply a refactor and are functionally the same

pastage 3y ago
Every change is different in the same way every program is unique, the change of a couple of characters will alter the meaning. I think you have to try to write a diff UI to understand why it is hard. Difftastic, Meld, diff -u, Word and other tools are amazing because they are usefull in many scenarios. Getting the UI right has been a long process, beingable to grok the changes is still hard even with thw best tooling. It is also a question of tool adoption it takes a long time to understand how a tool works.
nathan_compton 3y ago
Can you imagine having to learn a bunch of different language specific version control tools? Sounds like a hassle to me.
- stevage 3y ago
  No, because I only code in one language.
mqus 3y ago
Most repositories I work on don't have only one language. They have at the very least two, like the main language and maybe markdown for README files, then configuration like .ini or .toml, json stuff, yml, xml, etcpp. And then you might have bash scripts, Dockerfiles, other build tool languages, etcpp. And those are only text files. You probably will also have images, maybe zipped stuff, office documents and more, all not the "core" repository content, but stored nearby and versioned alongside. Building a hyper-focussed tool won't be very useful, expect to at least rudimentarily support other file types.
- fanf2 3y ago
  Off topic, but “etcpp” is a new one for me. Wiktionary suggests it is German, which amuses me because I write “etc. usw.” to mean the same thing.
  - mqus 3y ago
    whoops :D thought it was more international than this, since its pretty much as latin as etc. Interesting!
    - jorams 3y ago
      I read it as a little joke referring to C++, for what it's worth.
    - maleldil 3y ago
      What's the difference between etcpp and etc?
      - fanf2 3y ago
        The pp implies there are manny more things, as opposed to just some more things. https://en.m.wiktionary.org/wiki/etc._pp https://en.m.wiktionary.org/wiki/etc._pp.
      - mqus 3y ago
        sibling is right, although for me its mostly a habit, I rarely use etc.
- willow8349 3y ago
  This doesn’t really detract from my point - the “best” tool tool would use knowledge of python for python files, json for json files, and so forth. I think you’re just saying you’d want multiple of these rolled in a single tool as opposed to standalone, which is fair. I think any tool would have to be compatible with git /layer on top of it so it’s available as a fallback

pastage 3y ago

Every change is different in the same way every program is unique, the change of a couple of characters will alter the meaning. I think you have to try to write a diff UI to understand why it is hard. Difftastic, Meld, diff -u, Word and other tools are amazing because they are usefull in many scenarios. Getting the UI right has been a long process, beingable to grok the changes is still hard even with thw best tooling. It is also a question of tool adoption it takes a long time to understand how a tool works.

nathan_compton 3y ago

Can you imagine having to learn a bunch of different language specific version control tools? Sounds like a hassle to me.

stevage 3y ago
No, because I only code in one language.

mqus 3y ago

Most repositories I work on don't have only one language. They have at the very least two, like the main language and maybe markdown for README files, then configuration like .ini or .toml, json stuff, yml, xml, etcpp. And then you might have bash scripts, Dockerfiles, other build tool languages, etcpp. And those are only text files. You probably will also have images, maybe zipped stuff, office documents and more, all not the "core" repository content, but stored nearby and versioned alongside. Building a hyper-focussed tool won't be very useful, expect to at least rudimentarily support other file types.

fanf2 3y ago
Off topic, but “etcpp” is a new one for me. Wiktionary suggests it is German, which amuses me because I write “etc. usw.” to mean the same thing.
- mqus 3y ago
  whoops :D thought it was more international than this, since its pretty much as latin as etc. Interesting!
  - jorams 3y ago
    I read it as a little joke referring to C++, for what it's worth.
  - maleldil 3y ago
    What's the difference between etcpp and etc?
    - fanf2 3y ago
      The pp implies there are manny more things, as opposed to just some more things. https://en.m.wiktionary.org/wiki/etc._pp https://en.m.wiktionary.org/wiki/etc._pp.
    - mqus 3y ago
      sibling is right, although for me its mostly a habit, I rarely use etc.
willow8349 3y ago
This doesn’t really detract from my point - the “best” tool tool would use knowledge of python for python files, json for json files, and so forth. I think you’re just saying you’d want multiple of these rolled in a single tool as opposed to standalone, which is fair. I think any tool would have to be compatible with git /layer on top of it so it’s available as a fallback