Binary file history view

Description

In History on previous commits, GitHub Desktop shows a message that this binary file has changed and I can open it with related program. My file is a Rhino .3dm file that when I try open it, it show me just last version.

Version

• GitHub Desktop: version 1.5.1

• Operating system: Microsoft Windows [Version 10.0.16299.785]

Steps to Reproduce

1. Commit Changes
2. Open History
3. Click on show binary file in related app

Expected Behaviour

Open previous files in rhino app, not just last file.

Actual Behaviour

show only last version of file.

[Daniel-McCarthy]

My biggest concern is that the history is a representation of what’s changed throughout the life of your repo, but I’m not sure how much demand there would be for users to be able to open a previous version of a file

I’d be interested in others thoughts as well, especially if there are other folks who might find value in something like this so I can understand better what it might enable and when people might use it.

I think this would potentially make a lot of sense. When you have the history between two text files, seeing the diff is usually sufficient to be able to judge what has changed and be able to make an opinion of it. Knowing what has changed is essential when evaluating history.

However, with a binary file, you may not have as much context with the change. The binary file can be a number of things that may not be able to be displayed to the user. If the binary file is an image it is possible to display the two images to potentially tell them apart and see what has changed.

But when the binary file is something like a 3D model, or some other art file that is not displayed by Desktop, being able to open both the current and previous allows them to see both in their software and understand the changes being made in the project.

That’s to say, that without this, the user may not be getting much use of history for this type of file at all. It would allow for some A B testing and compare, like you would with text file history for example. Perhaps this may add some context. I would love to hear what others think on this as well.

[billygriffin]

Wow, this is not something I’ve heard before either, thanks @hghofraniha and @shiftkey for offering some thoughts. My biggest concern is that the history is a representation of what’s changed throughout the life of your repo, but I’m not sure how much demand there would be for users to be able to open a previous version of a file - and I’m also concerned it could cause confusion between the current version and previous version. I’d be interested in others thoughts as well, especially if there are other folks who might find value in something like this so I can understand better what it might enable and when people might use it.