(Sorry for the repost.  The other one was an accident.)

Over the week-end, I was thinking about the thread "Re: How is working
on arbitrary remote heads supposed to work in Cogito".  I wanted to
weigh in an opinion that I've developed on it but thought it deserved a
new thread.

Somewhere in the thread something was mentioned about maintaining
<local branch>:<remote branch> pairs in the git repository when pushes
and pulls are performed.  I think the argument was actually against
keeping this information and ultimately against allowing pushes to a
branch of a different name.

I wanted to weigh in with why it would be a good idea to make note of
this information.  The only thing that would be required of the plumbing
is to specify how this information is kept and if a push or pull is
performed directly with git then make note of the push/pull
relationship.  Everything else would be up to the porcelains.

So, I envision a simple directed graph where nodes represent the
branches (wether local or remote) and the edges represent push or pull
relationships between branches.

Git already stores the nodes.

The edges, in theory, would spring into existence when a push or pull is
performed between two branches for the first time.

This graph will be extremely useful for manageing flow in a project.  It
could enable something as simple as a script that would walk the edges
and tell which ones have fallen behind.  It would also be possible to
easily pull up a visual representation of the graph (with graphviz,
maybe).  This sort of thing might prove to be a valuable orientation
tool for the developer or project manager.

It could also enable some very powerful project flow management --- in a
porcelain of course --- that would manage flow from an engineer's own
sand-box through software engineering 'gates' such as integration,
quality assurance, product maintenance and the documentation and
sign-offs required to pass through each of these gates.

It could also be used to aid in documenting and managing the, already
existent, linux tree development flow in whatever way suits.

This is a big return on investment.  Little would be required of the
plumbing to maintain these 'edges', just add to them when it performs a
push/pull on an edge that hasn't already been recorded.  Any changes or
deletions could be handled by the user or by some porcelain.

I think it is important, though, to specify how this information should
be stored to maintain compatibility between porcelains while (hopefully)
allowing for some degree of flexibility.  I don't yet know where this
line should be drawn.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: [EMAIL PROTECTED]
 Fort Collins, CO 80525              home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to