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

["Jean-Noël Avila" <avila.jn@gmail.com>]

Le 29/04/2014 01:34, Junio C Hamano a écrit :
> 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.

Thank you for your reply.

I had not looked at other scenarios and the use cases that you bring up 
show that this feature would be far more complex than first estimated. I 
was more focused on the simplest case that is the broadest in the github 
fashion. Basing a work on a remote 'pu' branch when using advanced 
branch management commands may not raise any warning, or these warnings 
could be muffled with a config property.

After thinking a bit more on this, the initial idea encompassed another 
feature: enable people to push without "-f" when they have created these 
kind of branches. In your daily management of the pu branch for git, do 
you have to use the -f flag a lot? Would it be helpful to just tell git 
"I know what I am doing on this branch"? In this feature, the tagging 
would only be local.