ATM many commit messages in git-annex branch are just an "update". But I wondered if it could be relatively simple to implement to be able to provide a custom commit message, e.g. by defining some environment variable (e.g. GIT_ANNEX_UPDATE_MESSAGE) during whatever process is initiating the actual commit? sure thing there could be cases whenever multiple processes "contributed" to the changes which are finally "flushed" by committing, but imho it could provide a good way to annotate changes within git-annex branch at least to some degree. E.g. I could use "update: added URLs to the files for datalad-archives remote" 
Such an env var could easily be supported.
It's desirable to mostly keep the mantainace of the git-annex branch out of the user's view, because it's a complication that should not need to worry about.
Keeping it in an env var does avoid complicating the discoverable interface with some parameter to specify the commit message. Another way would be to make the commit message configurable in git config. Then it could be overridden with -c. Seems like the user of this feature is likely going to also use annex.alwayscommit=false sometimes in order to construct git-annex branch commits that bundle up several changes.
Anyway, I'm curious what kind of use cases make using custom commit messages for the git-annex branch makes sense. I doubt that typical git workflows with cherry-picking patches, patch review, etc, work with that branch.
My usecase is to be able to associate changes in main branches and in git-annex branch, so instead of non-informative "update" commit message it could carry e.g.
or I might even include the branch in which changes were done, e.g. short ones become
Then looking at
git log git-annexwould allow me to quickly see what actions lead to "updates" in git-annex branchThere are a few other messages than "update" that show up in some rare occasions including (message ++ " (recovery from race #"..) and "new branch for transition".
And, there's "merging remote/git-annex into git-annex" which is common enough.
I kind of have the feeling that the rare ones are rare enough that we might want to always use them, and only override merging and update.
OTOH, maybe merging is never something one would want to add a custom message for -- it's an entirely a function of the inputs -- and so only "update" should get replaced.