[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving from CVS to git
On 2018-12-03 14:41, TSUCHIYA Masatoshi wrote:
> We are still working to convert our CVS repository to Git.
> The problem is the treatment of $Revision$ string which was
> automatically converted by CVS, and which was used to decide
> My idea is to use the filter attribute describted at
> You can see my experimental implementation at
> However, this implementation still has a problem that all people who
> clone Git repository will have to invoke appropriate Git config
> If you have a better solution, please let me know.
Here's an idea that doesn't require every client to perform any manual
configuration, and has benefit of distinguishing between an 'official'
version that has been approved by the project and merged into master,
and other possibilities. However, I can't guarantee that it's a 'better'
solution or doesn't have its own unique problems.
1) The project administrator(s), and only the project administrator(s),
would install a client-side git hook 'post-merge' which would update
the revision string.
This would ensure that people not using git, or not even cvs, will
have a correct revision number on their downloads from the official
repository server. Whenever an admin merges a pull request, the hook
would auto-magically update the string, so the update would be part
of the merge's commit, thus when the admin pushes the merge to the
server, the version is hard-coded.
1.1) Instead of using 'git log' and 'cut', one could assign a tag to
the reference commit, and then use 'git describe', which would
output a string including the number of commits since the a
2) The `eval-when-compile' would try to assign the revision string using
`git-describe --all'. If this fails, it would use the hard-coded string.
This would mitigate any confusion between a version based upon an
unaltered commit from the official server, and a version based upon
some other commit. For example, in the case of a contributor
forgetting that he was using his own development commit(s) on some
git branch, the version string would display the branch and hash, and
in the case of a user who had 'rewound' her local repository in order
to use an old version of the project, that would also be reflected.
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0