4 ms·

The patch format addresses all of these issues, no? https://git-scm.com/docs/git-format-patch https://git-scm.com/docs/git-format-patch

by ed 1y ago

laserbeam 1y ago
TIL these are a thing. Thanks! (Just a regular joe on the internet, not the author)
genocidicbunny 1y ago
It might solve it for git, but this looks like something the Review Board team came up with, and they have to integrate with many other version control systems like SVN, CVS, Perforce..etc. Seems like this is meant to address supporting many different version control systems with a single format. I've worked at a place that used Review Board, and SVN as their primary vcs, but many devs used a local git-svn mirror for their work. Sometimes this caused problems with uploading diffs, especially if svn and git-svn were being mixed in one review. Having the Review Board cli generate a common diff format for both would have helped with that.
- chipx86 1y ago
  Exactly that. They all do things so differently that you end up creating and maintaining a separate parser for every SCM's diff format, and sometimes doing a lot of normalization of content or modification to include information the format lacks that's needed to apply the patches. And those are just for the ones that actually have a diff format -- many don't. We needed something for ourselves at the very least. Much of DiffX came from thinking about these pain points and from talking to other SCM vendors whose engineers have also given some thought to these problems.
  - motorest 1y ago
    > They all do things so differently that you end up creating and maintaining a separate parser for every SCM's diff format (...) ...and you seriously believe that pushing yet another ad-hoc format, and one which no one at all uses, is a way to address your concern?
    - seanhunter 1y ago
      Cue https://xkcd.com/927/ https://xkcd.com/927/
    - genocidicbunny 1y ago
      They are using it. Review Board is a successful project that's been around for a long time, and it's solving a problem they had. One of the most common workflows with Review Board for source code reviews is to use the RBTools command line tools to post or update reviews. The cli would be the one generating the diff (although it supports uploading diffs that you generate iirc.) I haven't looked into the details, but I assume RBTools can generate DiffX diffs which is probably easier for the backend to process. (E - from what chipx86 has said in some of his posts here, they have been using it for several years now) I don't really see this as pushing anything, more as documentation of something they did for themselves, but are also willing to provide to anyone else if they want to use it. Same as how the source code for the core Review Board product is available for anyone. If you're happy with the diff format you're using in your workflow, keep using that. No one's twisting your arm to switch to DiffX.
      - motorest 1y ago
        > They are using it. Which mainstream VCS supports this format?
        genocidicbunny 1y ago
        You're just being obtuse. It's been explained multiple times that there are tools external to the version control systems that can generate and consume this format. Just because there's no 'svn-diffx' or 'hg-diffx' command/tool built into the vcs itself, doesn't mean that this format can't be generated and used by other tools. So to answer your question, any vcs that has had tools written for it to generate this format. And it sounds like it's most of the major ones as far as Review Board is concerned.
  - genocidicbunny 1y ago
    DiffX would have been nice to have available way back when I was trying to add support for our custom in-house vcs to Review Board. We had to either contort the diffs from our vcs to some format already understood by Review Board, which was sometimes difficult due to how the vcs structured the data it stored, or add a whole new parser to our Review Board instance, which would have been a major maintenance pain. As an aside, I applaud you for creating Review Board. I've introduced its usage with several teams that I've worked with, and it really helped change how those teams operated, from a fly-by-night sort of development to actually having a process; The reduction in bugs and improvement in code quality were quite useful too.
    - chipx86 1y ago
      I'm really glad it was useful for you and your teams! :) Hearing that kind of thing always brightens my day. I've felt very lucky getting to work on this as my job all these years. It'd have been amazing having something like DiffX when we started building some of these SCM integrations too. It's really saved us a lot of trouble with some of the recent ones we've built (PlasticSCM / Unity Version Control, Keysight SOS, and ClearCase), which didn't have a format to work with and needed a lot of extra metadata for lookups and some other stuff.
- motorest 1y ago
  > 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?
- deleted 1y ago
  [deleted]

The patch format addresses all of these issues, no? https://git-scm.com/docs/git-format-patch https://git-scm.com/docs/git-format-patch

by ed 1y ago

The patch format addresses all of these issues, no? https://git-scm.com/docs/git-format-patch https://git-scm.com/docs/git-format-patch

laserbeam 1y ago

TIL these are a thing. Thanks! (Just a regular joe on the internet, not the author)

genocidicbunny 1y ago

It might solve it for git, but this looks like something the Review Board team came up with, and they have to integrate with many other version control systems like SVN, CVS, Perforce..etc. Seems like this is meant to address supporting many different version control systems with a single format. I've worked at a place that used Review Board, and SVN as their primary vcs, but many devs used a local git-svn mirror for their work. Sometimes this caused problems with uploading diffs, especially if svn and git-svn were being mixed in one review. Having the Review Board cli generate a common diff format for both would have helped with that.

chipx86 1y ago
Exactly that. They all do things so differently that you end up creating and maintaining a separate parser for every SCM's diff format, and sometimes doing a lot of normalization of content or modification to include information the format lacks that's needed to apply the patches. And those are just for the ones that actually have a diff format -- many don't. We needed something for ourselves at the very least. Much of DiffX came from thinking about these pain points and from talking to other SCM vendors whose engineers have also given some thought to these problems.
- motorest 1y ago
  > They all do things so differently that you end up creating and maintaining a separate parser for every SCM's diff format (...) ...and you seriously believe that pushing yet another ad-hoc format, and one which no one at all uses, is a way to address your concern?
  - seanhunter 1y ago
    Cue https://xkcd.com/927/ https://xkcd.com/927/
  - genocidicbunny 1y ago
    They are using it. Review Board is a successful project that's been around for a long time, and it's solving a problem they had. One of the most common workflows with Review Board for source code reviews is to use the RBTools command line tools to post or update reviews. The cli would be the one generating the diff (although it supports uploading diffs that you generate iirc.) I haven't looked into the details, but I assume RBTools can generate DiffX diffs which is probably easier for the backend to process. (E - from what chipx86 has said in some of his posts here, they have been using it for several years now) I don't really see this as pushing anything, more as documentation of something they did for themselves, but are also willing to provide to anyone else if they want to use it. Same as how the source code for the core Review Board product is available for anyone. If you're happy with the diff format you're using in your workflow, keep using that. No one's twisting your arm to switch to DiffX.
    - motorest 1y ago
      > They are using it. Which mainstream VCS supports this format?
      - genocidicbunny 1y ago
        You're just being obtuse. It's been explained multiple times that there are tools external to the version control systems that can generate and consume this format. Just because there's no 'svn-diffx' or 'hg-diffx' command/tool built into the vcs itself, doesn't mean that this format can't be generated and used by other tools. So to answer your question, any vcs that has had tools written for it to generate this format. And it sounds like it's most of the major ones as far as Review Board is concerned.
- genocidicbunny 1y ago
  DiffX would have been nice to have available way back when I was trying to add support for our custom in-house vcs to Review Board. We had to either contort the diffs from our vcs to some format already understood by Review Board, which was sometimes difficult due to how the vcs structured the data it stored, or add a whole new parser to our Review Board instance, which would have been a major maintenance pain. As an aside, I applaud you for creating Review Board. I've introduced its usage with several teams that I've worked with, and it really helped change how those teams operated, from a fly-by-night sort of development to actually having a process; The reduction in bugs and improvement in code quality were quite useful too.
  - chipx86 1y ago
    I'm really glad it was useful for you and your teams! :) Hearing that kind of thing always brightens my day. I've felt very lucky getting to work on this as my job all these years. It'd have been amazing having something like DiffX when we started building some of these SCM integrations too. It's really saved us a lot of trouble with some of the recent ones we've built (PlasticSCM / Unity Version Control, Keysight SOS, and ClearCase), which didn't have a format to work with and needed a lot of extra metadata for lookups and some other stuff.
motorest 1y ago
> 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?
deleted 1y ago
[deleted]