Triangular workflow with Central repo

Triangular workflow with Central repo

[Mark Ferrell]

I was trying to setup a git client to deal with our version of a
triangular workflow and found that there where no configuration
directives which supported our use case.

Developers create and commit to branches named dev/<user>/TOPIC
(Branch permissions are handled by Gitolite).  If the topic is
prefixed with 'pqm/' then the revisions are treated as "proposals" for
changing the head of a higher-level branch.  E.g. pushing to
dev/bob/pqm/master results in the PQM software checking out that
revision and running tests upon the source.  If all tests pass then
the 'master' branch is updated to point at the submitted revision. The
benefit for us using this approach is that it gives developers a
private sandbox in which they can push/pull code between one another
w/out needing a separate repository per-developer (or setting up a
repo on everyones workstation), and if they choose to submit code
changes to be a new baseline they simply create a PQM branch and
submit to it.

I found that it is possible to setup git to easily deal with this
work-flow (triangular) if the pull repository is different than the
push repository, but our use case relies on the pull branch being
different than the push branch.  It would seem that git would need a
branch.<name>.push directive for this to work out.

Re: Triangular workflow with Central repo

[Junio C Hamano]

Mark Ferrell <major@homeonderanged.org> writes:

> push repository, but our use case relies on the pull branch being
> different than the push branch.  It would seem that git would need a
> branch.<name>.push directive for this to work out.

I thought that you can tell recent versions of Git to pay attention
to the remote.*.push patterns and use them as a refmap even when you
are pushing a single branch?

Here is a demonstration:

 $ (git init src && cd src && git commit --allow-empty -m foo)
 $ git clone src dst
 $ cd dst
 $ edit .git/config ; cat .git/config
 [core]
         repositoryformatversion = 0
         filemode = true
         bare = false
         logallrefupdates = true
 [remote "origin"]
         url = ../src
         fetch = +refs/heads/*:refs/remotes/origin/*
         push = refs/heads/*:refs/heads/dev/me/*
 # note that I edited out [branch "master"] section to show that
 # you do not even need per-branch configuration.
 $ git commit --allow-empty -m bar
 $ git push
 Counting objects: 1, done.
 Writing objects: 100% (1/1), 184 bytes | 0 bytes/s, done.
 Total 1 (delta 0), reused 0 (delta 0)
 To ../src
  * [new branch]      master -> dev/me/master

For simplicity I used two local repositories and used a random
pattern "refs/heads/dev/me/*", trusting that the readers are capable
of updating the example to use remote URLs and different hierarchies
as needed.