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