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

[Junio C Hamano <gitster@pobox.com>]

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.