Tagging a branch as "not fitted for branching" ?

Tagging a branch as "not fitted for branching" ?

[Jean-Noël Avila]

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?

Best regards,

Jean-Noël AVILA

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

[Junio C Hamano]

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.

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

[Jean-Noël Avila]

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.

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

[Junio C Hamano]

Jean-Noël Avila <avila.jn@gmail.com> writes:

> .... In your daily management of the pu
> branch for git, do you have to use the -f flag a lot?

During the day I prepare and validate all the branches I am going to
publish, and at the end of the day, I run "git push" (no options)
with something like this in my .git/config:

        [remote "origin"]
                url = k.org:/pub/scm/git/git.git
		fetch = +refs/heads/*:refs/remotes/origin/*
                push = heads/master
                push = heads/next
                push = +heads/pu
                push = heads/maint

I may be on any branch (not one of these four branches) when I need
to run "git push" before I ran out of the office to catch my bus, so
these explicit "which branches are to be pushed" configuration that
does not change what is pushed based on the current branch is
perfect match for *my* workflow.  I know 'pu' is always forced, so a
single "+" in front of only that one would allow me to rely on the
fast-forward safety for other branches to stop me from rewinding
them.

I could be also using the --force-with-lease support to validate
that the current value of 'pu' matches what I expect with versions
of Git post 1.8.5, but I happen to be the only person who publishes
there, so there is no need for an extra safety.

If it were not for +heads/pu thing, I could even have relied on the
"matching" mode, because these four branches are the only ones I
have there, and most of the local branches I have do not have any
reason to be on that remote repository.

I should caution that the use of "matching" mode or the explicit
"remote.*.push" specifications are not suitable for non-maintainer
workflows, though.  As most of the people are non-maintainers, we
are switching the default to upcoming Git 2.0 release.