This Is Why We Can't Have Nice Things

[Mark Waddingham]

> I just remembered why you thought that I had a binary diff in lcvcs.
> Way back when I first started looking at it I was thinking of making a
> diff driver which you can set in git’s config to generate a text
> representation of a binary file just for the diff. This would be
> almost perfect for the review process if we could come up with a file
> format that was just a single file for a stack with the exception that
> github won’t show the text diff so they would need to review a PR
> locally. It won’t help them merge but will show them what’s changed
> and if there’s no other branches with changes to that file they can
> just accept or reject the changed file. For this I think it would be
> acceptable to just have a script that looped over all the objects and
> added their long name (with stack name instead of file path) and their
> script to the file. It may be they want to diff properties and custom
> properties too but that wouldn’t be that difficult to arrange. It
> doesn’t need to be any special file format because it’s never going to
> get read in and rebuilt into a stack.

I do wonder if a GitHub hook could be used here. Peter's done some great 
things with them in terms of PR review, CLA checking and CI via our 
'vulcanbot' build system.

If PRs which contain stacks were monitored by vulcan, it might be able 
to pick up when they aren't going to merge due to binary reasons and 
provide a link to a page which shows the diff so at least the review 
process could start and provide feedback to the submitter. It would 
still be a chunk of work to integrate such things (as if the target 
stack had changed since the submitted stack was modified, you can't just 
copy the submitted one over the target one) but at the very least that 
would give a list of changes that need to be applied.

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps