Git repository mail notifications

[Geert Janssens]

You may have noticed that the mail notifications for gnucash-htdocs have a new format with 
the repository switched to pure git.

The new notifications are generated by a script I found on the internet with some gnucash 
project-specific modifications. Most of the format has been discussed before on this list.

As we are now using it for the first time on a live, pure git repo some small new things have 
come up which I would like to point out and ask feedback on.

1. There seems to be an encoding issue somewhere. This is visible in the notification mail for 
the "svn_last" tag I generated:
Andreas Köhler is displayed as Andreas Köhler
I'll see if I can fix this.

2. I created a tag "svn_last" to mark the last commit in history that is still in sync with our 
now read-only svn repository. An unexpected side effect of this is that each subsequent 
notification message now starts with this tag in the subject line. Before, the subject started 
with the last commit's hashref.
I do actually prefer the tag usage. It gives an idea of what base the commit is starting from. 
On the other hand "svn_last" is not really descriptive for the current state of the website. So I 
probably should add two more tags (on on the master branch and one on the beta branch). 
I'm just wondering what would make sensible tags for the website ? We don't really do 
"releases" there. So a v2.4.x doesn't really make sense. What would ? "stable" ? "prod" ? 
"main" ? ...

3. Similar things will happen when we fully migrate gnucash and gnucash-docs to git. Both 
repositories already have a number of tags (for each release), but due to the way the svn-git 
bridge works none of these tags is actually on the trunk of 2.4 branch. Instead each tag is a 
separate branch with one commit and the (git) tag attached to it. In itself this doesn't really 
matter.

4. But it will affect the first real tags we add to the pure git repository. My understanding of 
the notification script is that when we add a tag to the repo it will search for the most recent 
previous tag on the same branch. It will then summarize the changes since that tag. Again, 
due to how the git-svn bridge works, we don't have any tags (yet) on our primary 
development branch (trunk/master). So the summary will be monstrous: all commits starting 
from the very first commit in cvs will be in there. I've seen this happen with each release 
since I added the git notification script (I had set up the system to send mails to me privatly). 
To avoid that, I would propose to add initial tags to each branch we consider active once we 
fully switch to git. At the minimum, we should add a tag for the most recent release on the 
trunk branch. That will likely be a future 2.5.x release or the 2.6 release (depending on when 
we do the last release of the 2.4 series). The one caveat: we can't add the same tag to two 
different commits. So if we want to tag releases that are tagged in svn as well, we can't use 
the same tag name. I don't know what would be best, but this is something we should keep in 
mind when we fully switch to git.

Geert