@hghofraniha thanks for the feedback! I'm actually surprised this hasn't come up before (maybe it has, and my memory is failing me right now) but maybe this is something we can support in the app.

The biggest problem here is that while we can easily display the diff of changes in a repository, opening a specific version of a file is not easy - either we'd need to checkout that commit so the working directory has that version, or we extract the specific version of the file to a temporary location, which the default program can then open.

Here's a rough flow I can think of that might achieve this:

• In "History" view, find a commit with an older version of the file you're interested in opening
• As it's a binary file that Desktop doesn't understand, the diff shows "Open this version in external program" (previously we show Open file in external program but I want to include version in the message to indicate that it's not likely to be the current version)
• When the user clicks to perform the action, Desktop will extract the blob from the repository to the OS temporary directory, using a pattern like {SHA}-{filename} so that we can avoid clashes if the user looks at multiple versions of a file
• Once that file exists on disk, perform the existing behaviour of opening this new file in the default program

I'm going to cc @desktop/product on this to also get their thoughts on this suggestion and other questions they might have.

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.

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.

@Daniel-McCarthy Thanks! Your reasoning makes a lot of sense to me - out of curiosity, how do you envision this actually working in the app from a user's perspective, if we did choose to implement it? I'm just trying to get a feel for discoverability and potential for confusion.

@billygriffin That's definitely an interesting question that I'm not fully sure on.

On this screen it would be easy to use some of that extra screen real estate for some buttons or other UI work to allow for it:

However, two things come to mind with that.

• In order to access that functionality, the user depends on GitHub Desktop to accurately determine this file type is binary and display this screen.
• Does this functionality need to be limited to binary files? If we made it available for all file types then we can not rely on UI work for only this binary file page.

My instinct for how I would expect to do this as a user would be to go to the History tab, scroll down to the commit I want, select it, right click the file I am interested in, and select Open (Previous/Past/Superceded) file with Default Program.

In this case it could be another entry below Open in Default Program, or hovering over an Open entry could show several options to select from. However, you have stressed avoiding confusion, and this also makes me think of previous issues regarding Discard Changes vs Discard All Changes.

I'd love to hear what others think on this and how they would prefer it.

@billygriffin I'm very interested in this functionality but for any file type. Sourcetree already has the ability to do that, where you can go into history, and double click/right click>open any file from that point in history. It'll download that version of the file in a temporary location and open it.

Once or twice (such as today, hence why I'm here) I've needed the functionality, and I have to instead go to github, navigate to the file, go back through the history and view the full file at that point.

The UI would be something like this (did it in paint so kept it simple haha, I would imagine the option to open the old version being at the top though, with an option underneath to open the current version):

If it was set to double click too, I don't think anyone would be browsing the history with the expectation of opening the most recent file. To me it feels kinda natural that the default open should be loading that specific version.

Hopefully I can resurrect some interest in this, as I would be interested in this feature too. I'm working on a hymn book of between 4 - 500 hymns with a small team. Each hymn is on it's own timeline of completion (Someone first gets all the notes put in, another works on the chords, another on dynamics, another on formatting, etc.). Some of the formatting and notation changes are debatable, so to be able to compare versions easily would add a lot of value to the desktop version of github. There aren't any programmers on the team, so having the desktop version is more user-friendly for non-programmers.

RE: #6535 (comment)

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.

See also:

• Feature request: show image previews for images tracked by lfs #2981
  • Add LFS object data get using git lfs smudge. Blob images for #2981 e… #17686
• Support for .dds image file preview #5337
  • Support preview for DDS images #17564