From: Jean-Noël Avila Date: Tue, 29 Apr 2014 07:37:06 GMT Subject: Re: Tagging a branch as "not fitted for branching" ? Message-ID: <535F56A2.9020900@gmail.com> In-Reply-To: Le 29/04/2014 01:34, Junio C Hamano a écrit : > Jean-Noël Avila 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.