Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
> 
>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
>>
>>> But I think I have to drive my message home again: if what you desire 
>>> becomes reality, you take away the clear distinction between local and 
>>> remote branches.  In fact, those branches are neither local (because 
>>> the next pull will automatically update them with remote changes, but 
>>> _only_ if they fast-forward) nor remote (because you plan to work on 
>>> them locally).
>> Exactly, because I do not work on those branches alone. These are 
>> _shared_ branches. I can work on such a branch with a group of 
>> developers. I'm willing to accept this bit of chaos.
> 
> It is not just a chaos.  I see a serious problem here.  On _your_ 
> computer, you do _not_ have a shared branch.  Which is visible _even_ in 
> your modified work flow when you have unpushed changes.
> 

Ofcourse it is. People might pull from it. That's the whole point of a
distributed model.

quoted text
> So your desired illusion that your local branches are anything but local 
> branches will never be perfect enough.
> 
>> Your rebase workflow is not possible if more than one dev wants to work 
>> on the topic branch together.
> 
> Why not?  I do it all the time.  CVS users do it all the time, for that 
> matter.
> 

For 200 branches at a time, where any of them might have changed? Do they
*really* go into all those branches and make really, really sure they run
git pull before they ever do anything? Isn't there a teensy weensy risk of
them forgetting that sometime when they really meant to do it?

On the other hand, if they absolutely *must* fork a branch at a specific
point in history (rather than "the latest published work this branch has"),
won't they run gitk/qgit/git-log/whatever, regardless of where their branch
head is?

quoted text
> 
> The problem I see here: you know git quite well.  Others don't, and will 
> be mightily confused why pull updates local branches sometimes, and 
> sometimes not.

Do you know this, or are you just guessing? I'm getting the exact same
confusion with the current behaviour. "Why the hell doesn't git update
all the branches I told the damn stupid tool to auto-merge when I pull?"
frequently echoes around the office. My co-workers aren't interested in
learning about git internals, or its reasons for doing what it does.
They don't give a damn about local vs remote namespaces for their branches.
They want to get some work done the smoothest way possible, but with our
small forest of repositories and the bushel of branches in each repo
makes life difficult for them, because they just can't imagine that
git doesn't do what they told it to, which is "this branch tracks that".
They may work on "this", but still want it to track "that" so they don't
have to run "git-update-all.sh", or "git-walk-everything.sh" or any other
of a dozen small and near-identical scripts floating around the office.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
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