On Oct 25, 2007, at 9:57 AM, Andreas Ericsson wrote:

quoted text
> 50+ repositories, with stable, testing and maint branches. Some  
> repos have more
> than that, so it amounts to roughly 200 branches. Each branch can  
> be modified by
> anyone (we're a small company - everyone still works everywhere),  
> but all changes
> should be done to the tip of the upstream branch. Especially for  
> maint this is a
> bit of a problem, since we frequently have consultants out and  
> about, and they
> sometimes find a bug that they commit locally to their own repo.  
> They're in a
> hurry though, and have no connection to the mothership repo so they  
> can't git-pull
> to get up to date. They aren't exactly developers, but savvy enough  
> to fix a few
> simple bugs, but the concept of the locally-modifiable branches not  
> being updated
> to their remote-tracking counterparts with each git-pull is just  
> incomprehensible
> to them. To me, that suggests that we're doing something wrong.

Johannes described a workflow using rebase. It would create
a very clean history avoiding long "parallel roads" and it
mimics what experience git users would probably do: Just work
if you have no connection but cleanup your work by using rebase
before pushing it.

Johannes, and Peter, too, propose to delete local branches
asap to avoid the third copy besides the copy on the server
and the copy in remotes. They suggest that local branches
should be absolutely reserved for local work.

However, my feeling is that the current tools make it too hard
to work the way described. Therefore it's hard to sell such a
workflow to an unexperienced developer. For example checking
out a remote branch for doing some local work, pushing this
work, and cleaning up requires

    git checkout -b <branch> origin/<branch>
    # work work ...
    git push origin <branch>
    git checkout <don-t-work-here>
    git branch -D <branch>

These are a lot of commands and some of them look quite
redundant.  Nearly every command contains <branch>. Why isn't is
sufficient to tell the name of the branch I'm working on once.
And '-D' looks even dangerous to me because it overrides all
safety checks. This should not be needed in daily work.

Here are some questions:
Do you think a workflow using rebase is feasible for
unexperienced git users?
What would be needed to bring such a workflow down to a few,
simple and reliable commands?

I think the general question is what I described in a previous
mail: You have a shared repository containing stable and topic
branches. Provide a workflow that is as simple as possible
for as many as possible developers. The average developer
should need nothing more than equivalents of "cvs update",
"cvs commit" for daily work if there are no conflicts. Note,
there are no redundant branch names allowed in the commands.
If a developer doesn't switch branches there's no need to
tell the branch name. "git pull ; ... ; git push" is simple
but it has the problem of reporting errors that average devs
don't understand.

	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