TriBITS icon indicating copy to clipboard operation
TriBITS copied to clipboard

gitdist: Add dist-repo-version command

Open bartlettroscoe opened this issue 9 years ago • 1 comments

Currently, the documentation for gitdist tells the user how to manually run gitdist to create a RepoVersion.txt file that can be used with the --dist-version-file=<file> argument. That is sloppy and opens the door for the user to make a mistake and it allows very long and cluttered RepoVersion.txt files because developers are sloppy and someones create very long git commit summary lines. But this has not really been an issue because a well-formatted <Project>RepoVersion.txt file is automatically generated by TriBITS as described here and that is used by CASL VERA. But here are use cases where one will want to be able to create a <Project>RepoVersion.txt file without the TriBITS CMake configure (and there are many projects that could use gitdist that don't use TriBITS). In addition, this is a chance to remove duplicate code from inside of TriBITS Core.

The way to fix this is to add the special gitdist command dist-repo-version that will generate a repo version file for the current versions of each repo. By default, this would be sent to STDOUT but gitdist could also support the option --dist-version-file-out=<file> (or -o <file>) so the user could create a repo version file like:

$ gitdist dist-repo-version -o <Project>RepoVersion.txt

(we would have to add the option -o only when the command was dist-repo-version)

Some things to fix as part of this work are:

  • Print the full 40-char SHA1. (Currently, the documentation says and the current CMake code in TriBITS creates the shortened SHA1)
  • Print the commit date instead of author date
  • Clip the length of the summary lines to 120 chars

By switching to a 40-char SHA1, we ensure that these SHA1s will work for all future versions of the git repo. By switching from the author date to the commit date, we avoid ambiguity since one can replicate a commit using cherrypick or rebase. Then, if an extra repo gets filtered and all it's SHA1s change, then we can uniquely identify the matching commits by using the combination of author, the commit date, and the summary (the first 120 chars). Actually, just the commit date should be enough to uniquely identify the commit. For example, you can use 'master@{Mon May 2 09:08:48 2016 -0400}' instead of a SHA1 with git log, checkout, etc. This means that gitdist could add an option to use the commit date instead of the SHA1 stored in the <Project>RepoVersion.txt file to recover older versions of the repo. (You don't even have this option with git submodules where it only stores the SHA1.)

Also, the TriBITS CMake code (the function TRIBITS_GENERATE_REPO_VERSION_FILE_STRING()) should be updated to use gitdist dist-repo-version -o <Project>RepoVersion.txt instead of having its own CMake code that does this calling git.

NOTE: This would also allow generating a repo version file that excludes the base repo by calling:

$ gitdist --dist-not-repos=. dist-repo-version -o <Project>SubRepoVersion.txt

as described in this TriBITS backlog item.

bartlettroscoe avatar Jul 08 '16 19:07 bartlettroscoe

This would be nice to have but it is not a blocker for any near-term story. Taking out of "ready".

bartlettroscoe avatar Jul 08 '16 22:07 bartlettroscoe