Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

[Andreas Ericsson <ae@op5.se>]

Peter Baumann wrote:
> On Thu, Oct 25, 2007 at 09:15:35AM +0200, Andreas Ericsson wrote:
>> Johannes Schindelin wrote:
>>> 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.
>>
>>> 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?
>>
>>> 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.
>>
> 
> What actually wonders me why you guys do have 200 local branches. I
> usually just create a local branch from the remote IFF I'd like to do some
> work on it. And for inspecting a remote branch, a detached HEAD works just as
> fine ...
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231