Re: [boost] git reset and force push

Subject: Re: [boost] git reset and force push
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-07 18:18:13

Le 07/10/15 23:27, Agustín K-ballo Bergé a écrit :
> On 10/7/2015 5:44 PM, Raffi Enficiaud wrote:
>> 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.
>
> You seem to be assuming that external test runners run the Boost
> regression test suite, that's not necessarily the case. It's not
> uncommon for libraries or applications that rely on Boost to proactively
> build against what will be the next version to catch errors ahead of time.

Still they do not need to know what other submodules are doing, they 
need to know what their own submodule is doing. Your example does not 
justify anything (see below).

>
>> 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)?
>
> Others have addressed this already, and there's plenty of material on
> the webs too.

So you're just claiming that there are many /unknown and non-cited/ 
resources, providing /evidence/ impossible to quote and /material/ 
impossible to reproduce: what you are claiming exactly again?

I am sorry, but a "just don't do it" is something I cannot buy, nor the 
"others have said", nor "problems occurred" without at any point of the 
discussion being able to name or reference what we are talking about.

>
> I've only felt the need to jump into this thread when positions started
> to be counted, up until then I did not think it was even worth the time
> discussing it.

Yes, quantifying is good, thank you for having taken part of the count. 
Quantifying is as important as good reference supporting claims though.

"Others" gave a precise example where operations fail based on what I 
suggested and the history of the discussion (again to be understood: not 
from the developers of the submodule in question checking out a specific 
version, but from users of the superproject).

The case presented is just but one example of how
> rewriting history can be disruptive; as a person who frequently uses
> Boost from git, my position would stay the same even if every bot in
> existence would be modified to tolerate history rewrites.

Again your position sounds rather religious to me, and your claims are 
hardly convincing.

I've **never** said rewriting history is not disruptive BTW. I said that 
**in the current superproject setup**, since the superproject is only 
interested in SHA1, rewriting history should work for most of us (mortal 
or robots) because we are not checking out particular branches of a 
submodule (but checking out SHA1).

And in fact it does: if you do not checkout any submodule branch and if 
you always go forward in the superproject history, it just works. Only 
two "ifs", but important ones.

>
>>> 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.
>
> That's of course subjective, the operation exists and the tools allow
> you to use it.

This is the exact opposite of subjective: this is just factual.

- is there any policy wrt. to this? no
- git allows me to do that? yes
- what if I do it in the current settings of the superproject? convinced 
by a clear case of superproject disruption from the answer of Stephen 
Kelly (hey, thanks again Stephen!): going back in time may not be 
possible if blobs are garbage collected.

> My opinion is that using it on a public branch is
> misbehaving.

There we are: thanks for underlining the following two important words 
this time: /"My opinion"/.

Kind regards,
Raffi