Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

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

Steffen Prohaska <prohaska@zib.de> writes:

> - in a pull-oriented workflow (Linux kernel, git) ...
>   ... There's maybe also less need to push to heads named
>   differently on the local and the remote (though I'm not sure
>   if this really true).

That's far from true but is irrelevant to the discussion of
supporting shared repositories better.

> - in a workflow that is base on shared branches (CVS-style),
>   ...
>   In addition push should push back to the remote branch a local
>   topic was originally branched off.

Why?  If it is shared, and if you are shooting for the simplest
set of commands, wouldn't you work this way?

	$ git clone $public my-work-dir
        $ cd my-work-dir
        $ git checkout -b --track foo origin/foo
        $ hack hack hack, commit, commit, commit *on* *foo*
        $ git push $public foo

I think the recent git defaults to --track anyway so the third
step do not spell out --track.

With your "remote.$public.push = HEAD", the last step would be
"git push" without any parameter.

If you do use private topics, then the story would change this
way:

        $ git checkout -b --track foo origin/foo
        $ git checkout -b topic1 foo ;# or origin/foo
        $ hack hack hack, commit, commit, commit on topic1
        $ git checkout -b topic2 foo ;# or origin/foo
        $ hack hack hack, commit, commit, commit on topic2
        $ git checkout foo
        $ git merge topic1
        $ test test test; # test _your_ changes
        $ git merge topic2
        $ test test test; # test _your_ changes
        $ git push ;# again push 'foo' out

This may fail to fast forward.  You may at this time want to
"git fetch" first, rebase topic1 or topic2 that conflict with
the other side on top of updated origin/foo, rebuild foo and
push the result out, like this:

	$ git fetch
        $ git rebase origin/foo topic1
        $ git branch -f foo origin/foo
        $ git checkout foo
        $ git merge topic1
        $ git merge topic2
        $ test test test
        $ git push

>   ... This makes the need for
>   pushing to a branch named differently on the remote side more
>   likely than in a pull-oriented workflow,

So I do not understand this remark.