Re: Tagging a branch as "not fitted for branching" ?

> Jean-Noël Avila <avila.jn@gmail.com> writes:
>
>> Most manuals on git state that it is bad practice to push -f a branch
>> after have meddled with its history, because this would risk to upset
>> the repositories of the coworkers. On the other hand, some workflows
>> use branches to propose modifications, and need some rewritting of the
>> history after some review steps. In this case, the branch should only
>> be seen as a mere pile of patches. Having this two-sided discourse is
>> often misunderstood by casual git users.
>>
>> The proposed solution would be to be able to flag the branches with a
>> special tag "not fitted for branching" that a collaborator could use
>> when pushing it. This tag would be passed on to any pulled
>> remote. When another collaborator would then issue a "git checkout
>> -b", the command would fail with a warning message, unless forced with
>> -f'.
>>
>> Is this feature already present? If not, would it be of any interest?
> Since nobody seems to be responding...
>
> I do not think there is anything like that.  I am not personally
> interested in it very much without seeing much details on how we go
> about implementing such a feature.  Note that I am not speaking on
> behalf of the project, or as its maintainer, but just as one of the
> active contributors to the project, so my "not interested" is in no
> way final.
>
> There are ways other than "checkout -b" to end up having your
> commits on top of a forbidden commit.  Are you going to cover all of
> them and at what point?  You may rebase your work based on 'master'
> (which is not one of these forbidden branches) onto it.  You may
> start your WIP on top of 'master', realize that you need something
> that is cooking only in 'pu' (which is a forbidden-to-be-built-on
> branch), and then do a "git checkout -m pu^0" in order to further
> experiment with it in an ideal world in which that prerequiste of
> yours already has graduated, and then decide to keep the WIP on a
> branch that you are not going to publish with "git branch wip" after
> commiting it on a detached HEAD.  Requiring "-f" during such an
> exploratory, idea-forming programming exercise might be a bit too
> much, and I cannot offhand see where the good place is to require
> "-f" in the first place.  At the final "git branch wip" step is too
> late, as you have already expended a lot of effort to build that
> WIP, and your saying "git branch wip" should be an enough clue for
> Git that you do mean to save it.
>
> At the first glance, I do agree (and to only this part I can say "I
> am interested in") that it might be a good idea if we had a bit more
> formal way to convey that branch 'pu' is not something you may want
> to base your final work on, but I am not sure if such a tag would
> help very much in practice or would be seen as a mere unnecessary
> roadblock that prevents them from freer experiments once the
> developers get used to the convention of their projects.