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