4 ms·

> Seems like this is meant to address supporting many different version control systems with a single format. I'm sorry, this is simply wrong at so many levels

> Seems like this is meant to address supporting many different version control systems with a single format. I'm sorry, this is simply wrong at so many levels. You're lauding this as a solution in search for a problem. As OP pointed out, this is already a solved problem as proven by Git. Git is not using a proprietary format. The problem of "integrate with many other version control systems" depends on whether those version control systems want to work on adding support for this feature. I guarantee you there isn't a single SVN or Mercurial maintainer complaining that they would love to share patches with Git but they are blocked because they cannot implement, let alone design, a format to exchange patches. That is not the hard part. That doesn't even register as a concern.

chipx86 1y ago
Git is using a proprietary variant on top of Unified Diffs. Unified Diffs themselves convey very little information about the file being modified, focusing solely on the line-based contents of text files and allowing vendors to provide their own "garbage" lines containing anything else. Every SCM that tracks information beyond line changes in a diff fills out the garbage data differently. The intent here isn't to let you copy changes from one type of repository to another, but to have a format that can be generated from many SCMs that a tool could parse in a consistent way. Right now, tools working with diffs from multiple types of SCMs need at least one diff parser per SCM (some provide multiple formats, or have significantly changed compatibility between releases. For SCMs that lack a diff format (there are several) or lack one that contains enough information to identify a file or its changes (there are several), tools also need to choose a method to represent that information. That often means yet another custom diff format that is specific to the tool consuming the diff. We've spent over 20 years dealing with the headaches and pain points here, giving it a lot of thought. DiffX (which is now a few years old itself) has worked out very well as a solution for us. This wasn't done in a vacuum, but rather has gone through many rounds of discussion with developers at a few different SCM vendors who have given thought to these issues and supplied much valuable feedback and improvements for the spec.
- motorest 1y ago
  > Git is using a proprietary variant on top of Unified Diffs. What definition of "proprietary" are you using?
  - chipx86 1y ago
    Created by the Git team for Git's purposes, rather than something documented or proposed for wider adoption. Other SCMs can and do use a Git-style diff format, but as there's no defined grammar, there are sometimes important differences. For example, Mercurial's Git-style diffs represent the revisions in a different format than Git's does with different meanings, reuse Git "index" lines for binary files but include SHAs of the file contents instead of any sort of revision, and have a header block that should be stripped out before sending to a Git-style diff parser.
    - bawolff 1y ago
      Aren't you doing the same thing? After all this is just review Board's custom diff format that nobody else uses.
      - chipx86 1y ago
        Yep! We spent 20 years dealing with these problems and in those 20 years nobody really solved these pain points. So we talked to some SCM vendors, bounced ideas around, built a spec, got feedback from them, repeated off-and-on for a couple years until we got the current draft, and implemented it for our needs. It's been a few years now, and so far so good for the purposes we built it for. And it's there for any other tool or SCM authors to use if it also happens to be useful to them.
        seanhunter 1y ago
        Feels more like in 20 years nobody else really has those pain points. 1. For most people using multiple SCMs is just a huge and easily-avoidable mistake. Most people can just mandate a single SCM for a project and then all these problems are moot. 2. For the things listed in TFA A single diff can’t represent a list of commits That's what "patch" and "patch format" is for. It works great. There’s no standard way to represent binary patches Very unclear why anyone needs this. There's no standard way to code-review a binary diff (it depends what the blob is that you're diffing) so how would it help if you had this standard way to represent the diff? Diffs don’t know about text encodings (which is more of a problem than you might think) This goes away if people on a project agree a particular encoding (which is going to be utf-8 lets face it). If someone sends a diff in an incorrect file encoding via diffx it will still apply wrong if someone uses a non-diffx aware (aka standard) tool to apply it. So diffx doesn't really fix this problem. Diffs don’t have any standard format for arbitrary metadata, so everyone implements it their own way. This goes away if you just use one SCM for a project which you should anyway for everyone's sanity.
genocidicbunny 1y ago
>I guarantee you there isn't a single SVN or Mercurial maintainer complaining that they would love to share patches with Git I was one of those maintainers. So you're already wrong there. As I described in my parent comment, I've worked somewhere this was an actual problem I encountered. I was responsible for both maintaining our SVN repository, and our Review Board instance, so I have had to actually deal with this.
- motorest 1y ago
  > I was one of those maintainers. So you're already wrong there. Please point out exactly where support for DiffX was implemented in either Mercurial or SVN.
  - genocidicbunny 1y ago
    DiffX is a bit younger than the tooling I've written, but I have added custom diffing tools to the SVN client for one team I worked with. I've also written plenty of tools that used the information provided by a VCS (sometimes even poking around in the server-side data), but external to it. So given a few days to refresh my memory on the interfaces, I could probably whip something up for SVN pretty quickly.

chipx86 1y ago

Git is using a proprietary variant on top of Unified Diffs. Unified Diffs themselves convey very little information about the file being modified, focusing solely on the line-based contents of text files and allowing vendors to provide their own "garbage" lines containing anything else. Every SCM that tracks information beyond line changes in a diff fills out the garbage data differently. The intent here isn't to let you copy changes from one type of repository to another, but to have a format that can be generated from many SCMs that a tool could parse in a consistent way. Right now, tools working with diffs from multiple types of SCMs need at least one diff parser per SCM (some provide multiple formats, or have significantly changed compatibility between releases. For SCMs that lack a diff format (there are several) or lack one that contains enough information to identify a file or its changes (there are several), tools also need to choose a method to represent that information. That often means yet another custom diff format that is specific to the tool consuming the diff. We've spent over 20 years dealing with the headaches and pain points here, giving it a lot of thought. DiffX (which is now a few years old itself) has worked out very well as a solution for us. This wasn't done in a vacuum, but rather has gone through many rounds of discussion with developers at a few different SCM vendors who have given thought to these issues and supplied much valuable feedback and improvements for the spec.

motorest 1y ago
> Git is using a proprietary variant on top of Unified Diffs. What definition of "proprietary" are you using?
- chipx86 1y ago
  Created by the Git team for Git's purposes, rather than something documented or proposed for wider adoption. Other SCMs can and do use a Git-style diff format, but as there's no defined grammar, there are sometimes important differences. For example, Mercurial's Git-style diffs represent the revisions in a different format than Git's does with different meanings, reuse Git "index" lines for binary files but include SHAs of the file contents instead of any sort of revision, and have a header block that should be stripped out before sending to a Git-style diff parser.
  - bawolff 1y ago
    Aren't you doing the same thing? After all this is just review Board's custom diff format that nobody else uses.
    - chipx86 1y ago
      Yep! We spent 20 years dealing with these problems and in those 20 years nobody really solved these pain points. So we talked to some SCM vendors, bounced ideas around, built a spec, got feedback from them, repeated off-and-on for a couple years until we got the current draft, and implemented it for our needs. It's been a few years now, and so far so good for the purposes we built it for. And it's there for any other tool or SCM authors to use if it also happens to be useful to them.
      - seanhunter 1y ago
        Feels more like in 20 years nobody else really has those pain points. 1. For most people using multiple SCMs is just a huge and easily-avoidable mistake. Most people can just mandate a single SCM for a project and then all these problems are moot. 2. For the things listed in TFA A single diff can’t represent a list of commits That's what "patch" and "patch format" is for. It works great. There’s no standard way to represent binary patches Very unclear why anyone needs this. There's no standard way to code-review a binary diff (it depends what the blob is that you're diffing) so how would it help if you had this standard way to represent the diff? Diffs don’t know about text encodings (which is more of a problem than you might think) This goes away if people on a project agree a particular encoding (which is going to be utf-8 lets face it). If someone sends a diff in an incorrect file encoding via diffx it will still apply wrong if someone uses a non-diffx aware (aka standard) tool to apply it. So diffx doesn't really fix this problem. Diffs don’t have any standard format for arbitrary metadata, so everyone implements it their own way. This goes away if you just use one SCM for a project which you should anyway for everyone's sanity.

genocidicbunny 1y ago

>I guarantee you there isn't a single SVN or Mercurial maintainer complaining that they would love to share patches with Git I was one of those maintainers. So you're already wrong there. As I described in my parent comment, I've worked somewhere this was an actual problem I encountered. I was responsible for both maintaining our SVN repository, and our Review Board instance, so I have had to actually deal with this.

motorest 1y ago
> I was one of those maintainers. So you're already wrong there. Please point out exactly where support for DiffX was implemented in either Mercurial or SVN.
- genocidicbunny 1y ago
  DiffX is a bit younger than the tooling I've written, but I have added custom diffing tools to the SVN client for one team I worked with. I've also written plenty of tools that used the information provided by a VCS (sometimes even poking around in the server-side data), but external to it. So given a few days to refresh my memory on the interfaces, I could probably whip something up for SVN pretty quickly.