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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 31, 2007, 21:09 UTC
Message-ID: <B16F7DA1-E3E5-47A4-AFD3-6680741F38F1@zib.de>
In-Reply-To: <7vve8nglrt.fsf@gitster.siamese.dyndns.org>

On Oct 31, 2007, at 7:51 PM, Junio C Hamano wrote:

Show 20 quoted lines

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Oct 31, 2007, at 9:45 AM, Junio C Hamano wrote:
>>
>>> I would not doubt it would be safer for _your_ workflow, but you
>>> should consider the risk of making things more cumbersome for
>>> workflows of others by enforcing that policy.
>>
>> Together with the '--create' flag it would be safer in all
>> cases, because it would always do _less_ than what git push
>> currently does. The safest choice would be if "git push"
>> refused to do anything until configured appropriately.
>>
>> "safer" is independent of the workflow.
>
> By your definition, a command that does not do anything by
> default is safer regardless of the workflow.
>
> That may be theoretically true --- it cannot do any harm by
> default.  But that is not useful.

If different workflows have contradicting needs, doing nothing by default might be a good choice. Not theoretically, but in practice.

Show 10 quoted lines

>> I'm mainly interested in using git against a shared repo,
>> and make it as simple and as safe as possible to use in
>> such a setup. I suspect that git is more optimized for the
>> workflow used for the Linux kernel and for developing git,
>> which heavily rely on sending patches to mailing lists and
>> pulling from read-only repos.
>>
>
> You forgot a lot more important part.  Pushing into publishing
> repositories.  And the discussion is about git-push command.

Exactly, here are two examples:

If you push only to publishing repositories that are read only by others, you'll never encounter the problem that 10/10 tried to solve. The publishing repository is never changed by others. You are the only one who pushes to this repository. Therefore the remote never advances unexpectedly.

A shared repository behaves differently. Others push to the repository as well. Hence, branches can advance unexpectedly.

Another difference is the way changes are integrated. In a workflow without shared repositories, only pull is used for integration, while push in only used for publishing the changes. After a push you always need to request someone else to pull. For example:

- Alice publishes branch foo.
- Bob clones Alice's repository and checks out foo as his
   local branch bar.
- Bob later publishes his branch by pushing bar to his
   public repository and asks Alice to pull.
- Alice pulls bar from Bobs public repository and merges
   with foo. She then publishes the integrated changes
   by pushing foo to her public repository.

My point is: there is no need to push from branch bar to branch foo. Alice and Bob both push to branches that are named identical in their private and their public repositories. Only pull is used to merge changes from the branch named bar to the branch named foo.

This is different if you work with a shared repository. Bob checks out the shared branch foo to his local branch bar and later he needs to push bar back to the shared branch foo. Bob needs to push changes from his local branch bar to the branch foo in the remote repository, a branch with a different name. This need does not emerge when working with two publishing repositories, as described above.

This was the extended version of what I meant above. The workflow used for the Linux kernel and for developing git is focused on pull. Push is normally only used for publishing branches under identical name. The interesting stuff happens during the pull.

	Steffen