Git repository mail notifications

[John Ralls]

On May 28, 2013, at 6:36 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> 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.


Is this for commit-mail a.k.a gnucash-patches? You make it sound like every mail will recap history
back to the last tag. That doesn't sound useful.

We can just make a light tag (no message) on the last release commits; to prevent name collisions we 
can prefix them with "gnucash-docs" or "gnucash", so yesterday's tag will be "gnucash-2.5.2". I can't
think of a useful tag for htdocs. It's not a repo that really has milestones. Maybe just tag the commit
after svn_last with gnucash-htdocs-<branch name>?

Regards,
John Ralls