Re: Making note, in the repository, of push/pull relationships

[Carl Baldwin <cnb@fc.hp.com>]

On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote:
> And presumably you have .git/branches/myremotebranch file that
> says something like "master.kernel.org:/pub/scm/git/git.git".
> Or should the last line of relationships file be spelled just
> push:master:ko-master?

Oops, I did intend to add just that to .git/branches/myremotebranch.

> > % cat .git/remotes/ko
> > push: master:ko-master pu:ko-pu rc:ko-rc
> > pull: ko-master:master ko-pu:pu ko-rc:rc
> >
> > I might argue that this is now a job for a porcelain script or
> > something.
> 
> Probably.
> 
> My primary interest in discussing this is to see Porcelain folks
> agree on what notation and semantics to use, and probably set an
> example by having the minimum base in the barebone Porcelain.

This sounds good.

> Personally I think there are two kinds of patch-flow: one that
> is pretty much static that can easily be described with
> something like your relationships notation, and ad-hoc one that
> I think should not automatically contaminate the established
> static flow your relationships notation nicely describes.  The
> corporate world may put disproportional stress on the importance
> of the former, but my feeling is that ad-hoc patch-flow that is
> outside your usual static patch-flow is just as important; see
> Documentation/howto/using-topic-branches.txt for why.

I don't doubt the utility of these topic branches.  In fact, I think it
what he's doing with this is great.  This is exactly the kind of thing
the 'relationships' could help out with.

As he creates branches from existing branches, pushes, pulls and merges
between them the relationships files would maintain a record of this.
Let's say, for example, he made a change on speed-up-spinlocks and
merged it to test.  Later, a bug is found and he fixes the bug on the
speed-up-spinlocks branch.  Now, a script could run using the
relationships files that could immediately tell that the test branch is
behind the speed-up-spinlocks branch and that they should be merged.
For someone who has a lot of different things to do this will be
valuable.

I would leave maintenance of any static work flows up to the porcelains.
If a project chose to use some sort of static flow then it can simply
populate the relationships files to help drive pushing and pulling if
some rogue developer were to use git alone or some other porcelain (thus
maintaining compatibility between porcelains).  If a porcelain wanted to
be very strict about adherance to a static flow then checking the
relationships could tell if something 'bad' has been done outside of
that porcelain.

I hope I'm being clear.  Please let me know if something is not clear.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -