Cactus and Einstein Toolkit bitbucket repositories should not allow rewrites of master

[Ian Hinder]

Cactus and Einstein Toolkit bitbucket repositories should not allow rewrites of master. This can be changed in the bitbucket settings, but it is tedious to do this for all repos. A script should be written to control this setting.

Keyword:

[Barry Wardell]

I created and ran a script to this for all Cactus and ET repositories on BitBucket. It only blocks forced rewrites of master, not other branches. The script can be found at https://bitbucket.org/ianhinder/etgittransition/src/master/block-force.

[Frank Löffler]

We should probably put scripts like these in a Cactus repo - maybe a subdir of the utils repository. They could be quite useful, say if a new repository is added or should be similarly configured.

[Roland Haas]

Inside of Cactus or a to-be-created Einstein Toolkit repository?

[Frank Löffler]

I thought https://bitbucket.org/cactuscode/utilities.git. Creating a new repo for that might be overkill.

[Barry Wardell]

The script is currently part of the repository containing the scripts we used for the git transition. I'm fine with moving either this one script or the whole lot to another Cactus/ET repository, although the current repository is under Ian's account so he should probably have the final say.

[Ian Hinder]

The repository contains a file with the mapping between SVN usernames and email addresses, which should not be placed in a public repository. I am fine with moving any useful scripts (plus their history, if someone has the time) to the utilities repository.

[Barry Wardell]

Why should the mapping be considered private? The usernames were already included in the commits in SVN and the email addresses are included in the git commits, so there is no extra information which is not already public.

[Ian Hinder]

BitBucket doesn't expose the email addresses over the web, so a blind spam-harvesting web crawler wouldn't find them. It would have to explicitly clone the repositories. I suspect it is not worth their effort, as I suspect the majority of people who commit to version control are unlikely to give money to companies who spam them.