On Nov 2, 2007, at 8:52 AM, Junio C Hamano wrote:
... 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.
[...]
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
