Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

From: Carl Baldwin <cnb@fc.hp.com>
Date: Aug 15, 2005, 16:23 UTC
Message-ID: <20050815162324.GA9857@hpsvcnb.fc.hp.com>
In-Reply-To: <7vacjmqnu7.fsf@assigned-by-dhcp.cox.net>

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

On Sat, Aug 13, 2005 at 12:48:32AM -0700, Junio C Hamano wrote:

Show 46 quoted lines

> Carl Baldwin <cnb@fc.hp.com> writes:
> 
> > On Fri, Jul 29, 2005 at 08:10:51AM +0000, Petr Baudis wrote:
> >> Exactly. I want much more freedom in pushing, the only requirement being
> >> that "the to-be-replaced remote head is ancestor of the to-be-pushed
> >> local head". I think (am I wrong?) git-send-pack localhead:remotehead
> >> would work just fine for me, the only thing I need is the support for
> >> different local and remote head names.
> >
> > Sorry to join the game so late.  I've only read this thread now.
> 
> Just in case you have not noticed, the push in 0.99.4 and
> onwards does exactly that.  Please see git-push-script.txt in
> the Documentation/ directory --- oops, there is no such thing.
> 
> Please see git-send-pack.txt instead, and if you feel like it, I
> would appreciate a patch to add the missing documentation for
> git-push-script ;-).
> 
> What's not supported well yet is the opposite --- downloading
> multiple refs and dealing with them.
> 
> Johannes Schindelin calls this "reverse push", and I think that
> is really a good name to describe what it does.  It takes a
> remote repository and possibly multiple refs, downloads the
> objects to complete the named remote references, and updates the
> local refs only if the remote refs are fast forward children of
> the local refs being replaced, just like "push" fast forwards
> the remote refs using the local refs.  In other words, given
> <src> and <dst> repository, the following should do the same
> thing:
> 
>     On <src> repository machine, with GIT_DIR being the <src> repository:
>     $ git push <dst> <ref-local-name>:<ref-remote-name>...
> 
>     On <dst> repository machine, with GIT_DIR being the <dst> repository:
>     $ git pull <src> <ref-remote-name>:<ref-local-name>...
> 
> Johannes posted a script on the list a couple of days ago, which
> should work well, except that it was written before the
> git-fetch-pack command was updated to natively download from
> multiple refs, so it does not know how to fetch multiple refs at
> a one go.
> 
> -jc
>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -