Re: Triangular workflow with Central repo
Mark Ferrell 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..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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Triangular workflow with Central repo
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//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..push directive for this to work out. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
