universally understood file-diff format

Question

I've always assumed that the output from diff (typically "unified", whether or not it's colorized) is universally understood among most if not all text-based language programmers. Whether it's used due to version control or just comparing two individual files, it seemed that it is rather prolific.

• GitHub offers both unified and split (side-by-side), defaulting to last-used (first-time is unified, I believe)
• GitLab offers both unified and split, but defaults to unified (no ref found in docs)
• Mercurial (hg diff) uses it (https://www.mercurial-scm.org/guide)
• Subversion (svn diff) uses it (http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn.c.diff)
• Git uses it (defaults to unified, other formats available) (https://git-scm.com/docs/git-diff)
• (to name just a few)

In a recent conversation with a project-partner (who is operating solely in TSQL), they complained that the unified-diff text I sent them in an email (containing literally two changed lines) was unusable/unrecognizable to them. I'm not upset that they aren't familiar with my standard: I'm honestly surprised that "they don't grok diff output".

Questions:

1. They use Visual Studio and TFS. Some research suggests that TFS does support /format:unified, but I cannot determine if it is default. What is the default, and does TFS have some form of patch.exe to easily import a diff-like change?

2. They've directed that I send every change as a whole file. Since we both make changes to the code, they then need to manually find my changes and merge them (or not). I understand that this pain is now theirs, but if they choose to not merge because they don't see a change, I am directly affected (and troubleshooting is difficult). Is there a better way I can send them changes so that they easily know where all changes exist yet have the convenience of getting the whole file?

3. If not diff (or sdiff, vdiff, or diff3), what other "industry-standards" are there? (perhaps limited/focused on MS/TFS)

I'm fairly comfortable with git, GitHub, and GitLab, so my prejudice is recently git-centric, though I have history with RCS, CVS, and Subversion. While I do not assume that git and therefore diff is the end-all/be-all, my point here is not about opinions on VC systems. I'm trying to disspell my mis-assumptions and communicate better.

NB: I have no access to their TFS server, and they will not try to work with my GitLab.

Answer 1

There is no industry standard.

The diff-and-patch workflow originated in the mid-80s in the context of open-source Unix development. You could send diffs around via email and then apply that patch to your local code. This was influential in the development of version control systems like Git.

Other ecosystems have entirely different conventions. Also, other ecosystems tend to be less text- and command-line oriented than the Unix/Linux/Open-Source ecosystems. Therefore it is a red herring to try to find the command line switch that will make TFS accept your patch.

When working with other people, you will have to negotiate a common workflow. Sending whole files around is the lowest common denominator and isn't necessarily a bad idea – if everyone uses some version control system locally they can copy the file into their source tree and quickly see the changes. In Git you can start a branch off the last common state, apply their changes, and then merge them into your common state to prevent conflicting changes from being silently overwritten.

In such a workflow, the value of sending around patches instead of whole files is quite diminished: while patches let you see the changes at a glance and save you bandwidth and mailbox storage all of that isn't crucially important (as compared to, say, productively collaborating).

I still suggest that you explain every change so that the other party doesn't have to search themselves: a kind if natural-language diff or very detailed commit summary. E.g.: “in foo.sql, I changed the type of the product_category column from varchar to an enum because $requirements”.

Answer 2

They've directed that I send every change as a whole file. Since we both make changes to the code, they then need to manually find my changes and merge them (or not). I understand that this pain is now theirs, but if they choose to not merge because they don't see a change, I am directly affected (and troubleshooting is difficult). Is there a better way I can send them changes so that they easily know where all changes exist yet have the convenience of getting the whole file?

You could send both old and new version of a file. Though, if you still doubt they can and want to correctly apply your change, you probably should make sure you are not going to be accountable if they do it wrongly. This probably will include negotiating the format of the changes being send and application procedure in more details.