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: Nov 2, 2007, 10:03 UTC
Message-ID: <417C801B-5DFF-4753-AB32-0FA1EB30C8E2@zib.de>
In-Reply-To: <7vk5p15bkv.fsf@gitster.siamese.dyndns.org>

On Nov 2, 2007, at 8:52 AM, Junio C Hamano wrote:

Show 5 quoted lines

> ... it still holds that what the developer wants to do is not
> just "to push", but "to push after making sure what he is going
> to push is in a good enough shape to be pushed".  Your _workflow_
> is forcing to integrate right away before pushing; don't blame
> git for this.

I don't blame git for forcing the developers to merge. I blame git for not supporting this workflow well enough.

I still believe that

- in a pull-oriented workflow (Linux kernel, git) there's less
   need to handle unexpected changes on the remote you want to
   push to. 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).

- in a workflow that is base on shared branches (CVS-style),
   the remote heads certainly will advance unexpectedly, and
   git push should support developers to cope with this situation.
   In addition push should push back to the remote branch a local
   topic was originally branched off. This makes the need for
   pushing to a branch named differently on the remote side more
   likely than in a pull-oriented workflow, where you would
   publish under your local branch name and ask someone else
   to pull.

[...]

Show 10 quoted lines

>
>> We haven't figured out much more of our workflow. The first
>> milestone is to migrate from CVS to git continuing to use a
>> CVS-style workflow.
>
> I think that is an interesting admission.  As somebody else on
> the thread already said, if you are sticking to CVS workflow,
> there are things that can and cannot be naturally done with
> git.  Don't break git when you hit the situation in the latter
> category without understanding how the world works.

Fair enough. I absolutely agree that it will never be a design goal of git to directly support a CVS workflow ;)

But I strongly believe that there is a more universal question
behind. It makes sense to have good support for a workflow
that is based on a shared repository. A shared repository
can be a way
- to make it easy for the average developer to get started.
   Only clone to a local working repository is needed, but no
   publishing repository.
- to facilitate that commits will be pushed to at a central
   place. The default is to push back to the shared repository
   (btw, it's easy to setup hooks to do some access control to
   avoid havoc). This may increase visibility of changes. It may
   help doing backups. It may be easy to encourage early integration.

For small projects with developers available for direct communication it may even be an option to have just this single shared branch.

For larger project a better infrastructure and more control over the changes is certainly a good idea. And git greatly supports more complex workflows. That's the main reason why I decided to choose git in the first place.

But for me the question is how can git be efficiently used to support a workflow based on a shared repository. It should be easy and safe to use and only few commands should be needed to get started.

>> error: remote 'refs/heads/master' is ahead of local 'refs/heads/
>> master'. Use --verbose for more details.
>
> I'd rather have "Read section XXX of the user's guide".

Ok; do I need to write the section first or is there? ;)

And maybe we could do two things (at least for msysgit):

- Rename or link user-manual.html to git-user-manual.html,
   which would allow saying "git help user-manual".

- Support HTML anchors, such that
   "git help user-manual#section5" would open the user manual
   and jump to the right section.
	
	Steffen