Re: [PATCH] git-remote exclude

On Monday 2007 January 15 21:56, Junio C Hamano wrote:

I do not think you are interested in "not these two but
everything else".  You are interested in maint, master, next, pu
and man.  You can get away by saying "not these two but
everything else" only because you are implicitly trusting me not
to publish insane number of random throw-away branches left and
right.

Nope.  I think I'm right.  You're right that I'm trusting you not to publish 
an insane number of branches, but that holds for the glob-mode only, 
regardless of whether the NOT fetches are in place.  The sort of thing I 
imagine happening is that as maintainer you suddenly say - I think 1.5.0 is 
so good that we'll maintain it for longer than usual.  In which case we would 
suddenly get a branch for maint-1.5.0.  I would want that branch, but I still 
don't want man, html and todo.

 - If there are new ones found in the future, please let me know
   and I'll decide then.  or...
 - If there are new ones found in the future, I would not want to
   be bothered with them.  or...
 - If there are new ones found in the future, I want them too.

 - If there is one that was there but now isn't, ask me if I want to remove
   it

The choice between the last three will heavily depend on the
nature of the project and also your work habit to a certain
degree.

True; so all those should be possible to specify in the config.

A remote could frequently throw in random small-topic branches
that are short lived, and are totally uninteresting for somebody
who wants to track the big picture branches.  You would say the

That's true.  However, if there were discipline in the naming, this wouldn't 
cause a major problem:

 fetch = refs/heads/export/*:refs/remotes/origin/*

Now, only the branches under export/ will be sent across automatically.  You 
can make whatever topic branches you want without polluting the automatic 
namespace.

first if you primarily work in a particular area of the project,
because you will always be interested in the primary integration
and you may or may not be interested in a new topic.  You would

Again, in a project of that size, the branches could be conventionally stored 
in particular namespaces.

  fetch = refs/heads/topicA/*:refs/remotes/origin/topicA/*
  fetch = refs/heads/topicB/*:refs/remotes/origin/topicB/*

If a single repository has 1000 branches, that is a sign that
there is something wrong in the project's organization.  No
single person should need to look at 1000 branches -- that goes
directly against the distributed nature of git.  Humans do not
scale well.

Without saying how those 1000 branches are organised, I think that it is an 
incorrect generalisation to say that something is wrong.  I have tens of 
thousands of files in my home directory.  I cannot possibly look at all those 
files; and yet it's not disorganised.

To me, one of git's strongest features is the ability to have hierarchically 
organised branch names.  It solves the scalability problem in one fell swoop.

But you cannot optimize humans the same way.

No; but you can optimise them in a different way.  Trees are the way, as long 
as the number of choices at any level is within reasonable limits, then you 
can sort through thousands and thousands of items easily.

I actually think the way to go with this globbing stuff is to make it possible 
to specify more accurately what you want.  The weak area at the moment is the 
fact that it's not possible to do a non-recursive glob.  That is to say that

 fetch = refs/heads/*:refs/remotes/*

would grab x/foo, y/bar, and z/baz.  I know you keep your topic branches in 
places like jc/some-topic and js/some-other-topic.  If you ever pushed them, 
then the default glob would pull them all.  If we could have a non-recursive 
glob, then you could safely push them (making things all the more 
distributed) without impacting the master, maint, next, etc branch pulls.

Helping this kind of project organization is what git inherited
from BK as well.  The key to scaling is to limit the product of
the level of details times the size of the area one person needs

All agreed.  However, limiting the detail is not necessarily the same as 
hiding the detail.  If those 1000 branches can be arranged in such a manner 
as to make 990 of them easily ignored, then that's just as good as hiding 
those 990.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com