Test the interference of spec-up versioning and git commit versioning per copied file

[henkvancann]

• [ ] Action Kor: B. Judith's point: a spec will never show a definition that the author did not make or refer to. So we need to be able to flexibly offer "latest" and "original" on the terms, while the entire document can use Spec-Up's copy-based versioning. If you make a younger copy (because that is what Spec-Up does via Specs.json) then the history of the terms commit history will PREFERABLY start again from the date of the latest version of the entire document. 'Preferably' because we still have to see how this can work using GitHub.

Run a test : create splitted files dir with two {term}.md's, create a new spec-up version, change one {term}.md to see / show what happens with the commit history.

[henkvancann]

Kor performed test and reports:

1: Original file with some commits: https://github.com/kordwarshuis/git-history-test/commits/main/file1.txt

2: Copy: https://github.com/kordwarshuis/git-history-test/commits/main/versions/1/file1.txt

I think this indicates that you do not see the history of the original file from the copy

[kordwarshuis]

Explanation

The file “git-history-test/versions/1/file1.txt (“COPY”) is a copy of the git-history-test/file1.txt (“ORIGINAL”) with an added edit (the text “change 3” is added).

History for ORIGINAL

https://github.com/kordwarshuis/git-history-test/commits/main/file1.txt

What you see is a history of the edits of this file (“first commit”, “change 1”, “change 2”)

History for COPY

https://github.com/kordwarshuis/git-history-test/commits/main/versions/1/file1.txt

What you see is the history of the edits of this file (“Copy to new dir, change 3”) What you do NOT see is the history of the ORIGINAL (the file that COPY was copied from).

How to reproduce these urls:

• Go to https://github.com/kordwarshuis/git-history-test

Show info on ORIGINAL:

• Click on “file1.txt”
• Click on “History” (top right)

Show info on COPY:

• Click on the folder named “versions”
• Click on the folder named “1”
• Click on “file1.txt”
• Click on “History” (top right)

Next step: show “diffs”

You can go one step further and look at the “diff”. To do so click on the commit. For example “Copy to new dir, change 3” if you are looking at the history of COPY.

Afterthought

If the filename is created from the term according to certain rules (space becomes a dash, etc) then the filename can also be used as a way of making connections, after all, the term is unique and from the term the filename is created so then the filename in /version.1.0.0 will be the same as in /version.1.0.1

[henkvancann]

My impression is that we don't need the "copy all" approach of the versioning in Spec-Up, but maybe I don't oversee all implications of just sticking to git tags and branches.

https://chat.openai.com/share/75a8c5cd-d4d7-4d5b-811f-b139d44a70c2

In the approach of just using git tags and branches for snapshot and github diff we would not get the problems you obviously get (the test results above) to create an uncompromised history strain.

[henkvancann]

Since we're able to do a git diff on a file between different branches, we good to overwrite files and keep multiple versions of sets of files in separate branches.

Basic Command: To compare a specific file between two branches, you use the git diff command followed by the names of the branches and the path to the file. For example:

git diff branch1 branch2 -- path/to/file

In this command, branch1 and branch2 are the names of the branches you want to compare, and path/to/file is the path to the file within the repository whose differences you want to examine.

I could also specify specific commit hashes in both branches to do the diff on.

This ends the test successfully. Conclusion: try to avoid copying files, because git keeps track of versions and makes the diffs observable and you could gain full control over historical versions of a document.