On Mon, 2007-10-22 at 12:04 +0100, Johannes Schindelin wrote: > <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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
