Le 07/10/15 22:56, Stephen Kelly a écrit :
Raffi Enficiaud wrote:
The problems created by history rewrite are human-to-human, not human-to-robot:
This is not true.
Today the boost supermodule points to a particular sha of the submodule you want to rewrite the history of.
If you rewrite the history of the submodule, the commit referenced by the sha will be garbage collected and no one in the future will be able to make a checkout of the boost supermodule as it is today.
This is indeed (and sorry to say for this thread, "finally") a very good point: the problem then comes from the fact that we want to go back to time at the superproject level, which would be not possible if blobs are garbage collected. You affect usefulness of
the supermodule by rewriting history of a submodule. Just don't do it.
I understood that it is a source of annoyance for everyone, I am not a psychopath, I will not do it. I wanted to be convinced by a *good reason*, not just a potential bad implementation ("robot" or exotic "submodule update" command) or some /fear of the unknown/. What you just said is indeed a /good reason/.
You could push a branch with the current state of develop to a branch named develop-in-early-October-2015 which would prevent the shas referenced by the supermodule being garbage collected. How many times do you want to push branches with names like that? How do you defend against a zealous maintainer 'cleaning up useless branches' and breaking the supermodule history?
I which I were zealous. The reason I was bringing this topic is that this is the shortest and cleanest path to some breaking changes (and not because I do not like the shape of the history), where bad and good things happened at the same time. BTW, this point in time "develop-in-early-October-2015" is already in place... (just in case of an accident). Thanks for your insights, Raffi