Re: Moving from CVS to git

[Boruch Baum <boruch_baum@xxxxxxx>]

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
> emacs-w3m-version.
>
> My idea is to use the filter attribute describted at
>
>     https://git-scm.com/docs/gitattributes.
>
> You can see my experimental implementation at
>
>     https://github.com/tsuchm/emacs-w3m
>
> However, this implementation still has a problem that all people who
> clone Git repository will have to invoke appropriate Git config
> commands.
>
> 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
        reference tag.

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.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0