From: Junio C Hamano <junkio@cox.net>
Date: Tue, 16 Aug 2005 21:09:08 GMT
Subject: Re: Making note, in the repository, of push/pull relationships
Message-ID: <7vll318u8b.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050816171142.GB20016@hpsvcnb.fc.hp.com>

Carl Baldwin <cnb@fc.hp.com> writes:

> If I may, let me give an example of something I think could serve the
> purpose a little more simply and generically.
>
> Let's say I start with the following:
> % ls .git/refs/heads
> master
> mylocalbranch
> myremotebranch
> ko-master
> % cat .git/branches/ko-master
> master.kernel.org:/pub/scm/git/git.git
>
> I would add something like this:  (I didn't put much thought into the
> actual directory and file names, forgive me.  ;-)
>
> % cat .git/branches/relationships
> pull:ko-master:master
> pull:master:mylocalbranch # The next two document my flow locally
> pull:mylocalbranch:master
> push:master:myremotebranch # I push my master to a remote that I control

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?

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

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.