Aesthetics: How to lay out a repository for two different versions of the same application?

I have what is probably an uncommon problem. A friend and I have just resurrected a text editor from the very early days of UNIX (the RAND editor, first written in the mid-1970s). It now runs fine on Mac, Linux, and Windows (using a Linux VM).

However, we then proceeded to introduce mouse support and text highlighting into the forward-ported editor, which originally supported neither: the terminals of those days didn’t have mice and didn’t support highlighting.

The “mouse” version of the editor is developed strictly from the “nomouse” version. I want to make both versions available, the first for those people (and apparently there are some!) who want to be able to use this editor again, and the second for students of editor history. The “nomouse” version would also be useful to people who can’t get the mouse and/or highlighting support to work on their systems for whatever reason. Ncurses is not always your friend, we find.

Before stumbling my way down a Git-lined rathole, I’d like to ask for a judgement by the experts on what path would be best to follow:

  1. Put two separate directories up at the root of the repository, one for each version. This has the merit of simplicity but elides the fact that one is developed from the other.

  2. Put up the “nomouse” version first, give it an annotated tag, and then put up the “mouse” version as a commit to that branch.

  3. Start a branch right at an empty repository with just a “README.md” file, and commit one version to each branch.

  4. Some other blazingly obvious and superior tactic that this newbie hasn’t thought of.

Advice, please?

This sounds like a case for two branches, especially because you say this:

Start with a branch for the “nomouse” version, and branch off from that for the “mouse” version. You could even call the branches that if you want! :smile_cat: And if you develop anything new on the “nomouse” branch you can always merge it into the “mouse” branch.

Tags are generally used for specific versions, they’re not supposed to change later. So you could use a tag to mark the original imported code, and then your releases.

However, I wonder if you even need the separate code branches. Maybe it’d make sense to have just one code base, and make mouse support a compile time (or even runtime) option instead?

Thanks for the advice! If functionality were all I was after, this would of course be the thing to do, and in fact the “mouse” version has a command to turn off the new stuff, but the point is to preserve the old code for the sake of historical interest.

1 Like

Ah, I see! In that case I think it depends on whether you still want to work on the “nomouse” code: If you just want it on the record what that original version was a tag is good, if you want to do some sort of maintenance (e.g. to keep it working on modern systems) I recommend a branch. :slightly_smiling_face: