Jean-Noël Avila <avila.jn@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html