Le 07/10/15 17:44, Agustín K-ballo Bergé a écrit :
On 10/7/2015 12:26 PM, Raffi Enficiaud wrote:
Test runners are not necessarily prepared to deal with history rewrites, since those are a frowned upon practice in "public" branches (I'm surprised it's even being considered here).
That is also a surprise: why so? the runner API is running the run.py script that is cloning/pulling things: it does not check out any branch, so it does not care if develop changed by history rewrite. I am very curious to see what type of errors, and what are the exact causes, we had at that time: do you have an idea? because to me - see below - this should not be a problem for a bot. Maybe you can point me to the corresponding thread (if you have time)?
A force push would cause spurious failures in those runners,
The /only/ (not to say it is a minor) inconvenience I can see so far is when someone checks out a public branch locally, and a remote history rewrite messes up completely the local branch, so "git reset --hard" is needed. History rewrite causes no problem with "git fetch". The problems created by history rewrite are human-to-human, not human-to-robot: 1- a human checks out develop of a submodule, for eg. working on the submodule 2- history rewrite happens remotely on a submodule 3- problems to be compared with: 1- a robot checks out the superproject 2- history rewrite happens remotely on a submodule 3- robot can continue updating the superproject
which forces (pun intended) someone to look at it, notice that someone misbehaved, decide on a fix, pester the sysadmin for weeks until the fix is applied, etc.
There is no such as thing like "misbehaviour". The topic of this thread is to discuss about policies of boost wrt. to operations /permitted/ by git rewriting the history. So far, I heard about common or less common practice, but nothing written in black on white.
At least, that's how it went last time.
Can you point me to the thread? Thanks, Raffi