Re: Branch topology

[Ben Pfaff]

John Darrington <address@hidden> writes:

>      Maybe my vision for as-needed experimental branches is really the
>      same as your proposed branch #3?
>
> It sounds similar, if not identical.  What you don't make explicit, is
> the relationships between the branches.  As I see it, each of your
> branches listed above, must be the parent of the subsequent item, but
> I'm not sure if that's what you had in mind.

It's what I have in mind.

>      In addition, I'll probably have half a dozen or so branches in
>      various stages of development going locally on my development
>      machine at any given time.  Over at Nicira, I've probably had as
>      many as a dozen.  Git makes it trivial to create, merge, and
>      discard branches, so it's my habit to use one per feature that
>      I'm working on.  It appears that many Git users work this way.
>
> I don't know if this concept fits the git paradigm, but I think of
> branches as nothing more than "big" change sets.  If a developer
> thinks it's useful to create his change set in separate activities,
> then it's logical for him to branch it.  However, I'd like that all
> such branches are at least visible to other developers, even if
> they're not ready for general consumption.  That way, it avoids
> duplication of work, avoids (at least some) later merge conflicts and
> keeps developers pulling in the same direction.

For medium- to long-term branches, sure, it makes sense to make
them public.  Jason's already started doing this, although so far
it's misconfigured such that it's only "public" to people with
accounts on math.gcsu.edu (I'm pretty sure that's accidental),
and I'm going to also as soon as I have anything to share.

For short-term branches and things that are simple or trivial,
it's just as easy to just email patches around.
-- 
Ben Pfaff 
http://benpfaff.org