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

quoted text
> 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.


quoted text
>> 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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html