On Mon, 2007-10-22 at 12:04 +0100, Johannes Schindelin wrote:

quoted text
> <rationale>There is a good chance that git is not optimised for most 
> people's daily workflows, as project maintainers seemed to be much more 
> forthcoming with patches, and therefore maintainers' tasks are much more 
> optimised than in other SCMs.</rationale>

The following are workflows that would be very useful for my cow-orkers
and project peers.

End-user workflows:

* Clone from another SCM (mostly svn).  Make a local branch to implement
something in various commits.  Rebase to the "latest upstream sources"
when you are done, and then do the equivalent to "svn dcommit" to upload
your final changes to the other SCM.  The use case for this is to fix a
complicated bug in GNOME, which uses SVN.

* While you are doing that, produce a patchset that you can send to the
maintainers for review.  I love "git-format-patch -n --thread --stdout >
foo", but it's pretty painful to have to 1. look up git-format-patch's
options in the man page (if you use --stdout, shouldn't -n and --thread
be turned on by default?); 2. import "foo" into Evolution to then be
able to edit the zeroth mail, and then be able to use Evo's SMTP
configuration to send out the mails while preserving the threading.

* Clone a git repository which has several interesting branches.  Figure
out which branch you are interested in.  Create a local branch based on
that; do your changes there.  Keep your code up to date (rebase?  when
to fetch / pull / etc?).

* You have a personal branch with a bunch of commits:  a mess of "real
work", "remove debugging printf", "fix typo", etc.  Reformat / reorder
those patches into something suitable for submission.  [I just found out
about git rebase --interactive and it's *FANTASTIC* for this!]

Maintainer workflows:

* Start a personal project in git and publish it for others to clone.
Assume several possible setups:  dumb web server with no git installed,
git installed but no git-daemon, git installed with git-daemon running.
I've found that publishing is not trivial at all; it's a rather
cumbersome multi-step process.

* Several of your contributors publish their own git repositories.
Integrate changes from them, or review them.  This interesting because
you'll have to do a lot of navigation in repos with which you aren't
familiar, you'll have to use the merging and conflict resolution tools,
you'll have to maintain the signoffs, etc.

* Set up a public repository to which other people can push.

* Publish just some of your branches.  Do that often, say, because you
have new work to show in each of those branches.

  Federico

-
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