Patrick Steinhardt <ps@xxxxxx> writes:
> I wonder whether this really was an intentional choice or whether it is
> simply a bug that led to useful behaviour. In any case, git-replace(1)
> itself does not mention your behaviour at all -- it simply talks about
> the "name of the replace reference".
Yup, I am reasonbly sure that this was not a designed behaviour. If
this were discovered during the original review, I would probably
have suggested tightening the rule to ignore anything with extra
levels in the middle. It can be argued that it is too late, but
with this ...
>> The only way this didn't "work" is in the commit decoration process,
... where the "funny" replace refs are honored in some but not all
situations, it also can be argued that it is highly unlikely anybody
sane is actually depending on this "feature", so such a tightening
may not hurt too much.
The reason why I would slightly prefer tightening the rule, rather
than making the loophole even larger by adjusting the code for "the
commit decoration process", is what it means to have two different
replacement objects for the same object, which would naturally be
prevented from happening if we did not allow extra levels in the
middle. Would one always consistently trump the other? When a
filesystem rebalances, would we just pick one at randomly based
purely on the first one readdir() happened to return? It smells
to lead to nothing but a confused mess.
Maybe the answer is "don't do it, then". The same answer, however,
can be given for creating any extra level between refs/replace and
the object name itself, so... I dunno.
> If we can agree that this is something that we want we should definitely
> amend git-replace(1) to document this new format.
>
> Which raises the question: is this something that we want? Are there any
> arguments that would speak against loosening the format of replace refs
> now?
"What if refs/replace/{a,b,c}/$name point at different objects?"
would be a solid reason why we shouldn't do this, but I personally
do not feel too strongly about it, as "don't do it, then" may be a
reasonable answer for such an insane scenario.
