0

I am hoping that the wizards here can help me. I have used Mercurial in the past so I am familiar with the concept of a DVCS. However this is the first time I am using git with a slightly different workflow. Essentially it involves a hierarchical structure and possibly the use of mirror. The hierarchy I am hoping to get is as follows 

Root Repo  
^  
|  
|_____<MIRROR>______>Primary Repo  
                     ^  
                     |  
                     |________<CLONE>____> Developer  
                     |  
                     |________<CLONE>____> Developer

I would like to setup up the Primary Repo for two reasons:

  1. Location/Reduced bandwidth usage instead of every developer pulling/pushing from/to Root Repo
  2. Sanitise code through reviews and only approved code goes through to Root Repo

I have seen other workflows where Primary Repo becomes a sort of caching repo and everyone pushes to the Root Repo but this is not what I want. The other workflow I have seen is when everyone sends an email to the reviewer asking him/her to pull the changes but this is not yet feasible since the team is used to SVN and I want to keep it as familiar as possible.

What I tried till now:

  1. Clone the Primary Repo using mirror flag.
  2. Cloned from Primary Repo into local.
  3. Test modifications and then checked into local repo.
  4. Pushed code to Primary Repo.
  5. Pull from Root Rep (git remote update)
  6. git status now shows remote changes and mine are not visible
  7. Tried with a brand new clone of Primary Repo (does not show my changes)

I was wondering if this workflow is feasible (sounds like it should be). More probably I am messing up something. Any and all suggestions are welcome.

Prasad Jadhav
  • 5,090
  • 16
  • 62
  • 80
Cyrax
  • 115
  • 6

3 Answers3

0

Have a look at Gerrit+Jenkins. Jenkins can be setup to verify the build, reviewers can then approve the code during code review.

gvd
  • 1,823
  • 13
  • 18
  • We already have a Jenkins. It handles the automatic builds and review comments. This is not related to Jenkins. It is more about the Git workflow. I hope I cleared out any confusion there. – Cyrax Nov 05 '12 at 23:05
  • I thought I'd mention it as you were also mentioning sending patches for code review. Gerrit is an ideal solution for this. – gvd Nov 05 '12 at 23:53
  • I totally agree. Thanks for helping out. It is related and might be useful for someone who comes by this thread. – Cyrax Nov 06 '12 at 18:09
-1

Why are you worried about everyone pushing to one repo? Git is VERY efficient. Unless you are not dealing with source code (large images or videos), there is no reason for adding the complexity that you are proposing.

As for workflows, this is what I am using: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Unfortunately the existing workflow requires everyone push to a central repository (rebase). I do not have a say in this. Git being very efficient and versatile, I was hoping that the above mentioned workflow would work. It is sort of like a cascade workflow. – Cyrax Nov 05 '12 at 23:05
-1

What you want should be doable as follows (disclaimer - I haven't tested this):

Setup

  • set up root repo (R)
  • create primary repo (P) as clone of R. This sets R as the upstream repo of P.
  • create local developer repos (D1, D2, ...) as clone of P (again, sets P as upstream of D*).

Workflow

  • Developers develop in D*. When satisfied, they push to P.
  • Developers regularly pull from P to keep up-to-date with changes by colleagues.
  • You regularly review code in P, and push it to R(*) if deemed appropriate.

Would that solve your problem?

As to what you tried:

Pull from Root Rep (git remote update) git status now shows remote changes and mine are not visible

This looks like a misunderstanding. git remote update is not "pulling" -- pulling is git pull :-). git remote update only updates the cached copy of the remote data - you must pull to actually fetch the changes into your local branch. If you git pull the primary repo from inside the root repo, you should see the changes.

(*) You can either push into R while in P, or you can pull from P while in R - the result will be the same.

sleske
  • 81,358
  • 34
  • 189
  • 227
  • That's the setup that I am aiming for. When I tried pulling from git it refused saying this is a bare repository. I am assuming that you are still referring to P as a bare repository since I read in the git docs that 1.7 version onwards you cannot push to a non bare repo – Cyrax Nov 08 '12 at 22:20
  • @Cyrax: So, did you try a `git pull` while *inside* the root repo R, which is bare? That won't work - you cannot use pull in a bare repo. You use fetch instead - see e.g. http://stackoverflow.com/questions/3382679/git-how-do-i-update-my-bare-repo . But the common solution is to push to the bare repo. Bare repos are not really meant to be used directly, they are used from other repos (which push/pull). – sleske Nov 09 '12 at 01:04
  • Almost forgot. On a bare repository I don't think I can call git pull. I am using a mirror btw and not just a bare. – Cyrax Nov 09 '12 at 02:19
  • @Cyrax: Yes, you cannot pull into a bare repo (but you can push into it from another repo). And you should not use mirrors, just regular clones. Otherwise pushing/pulling will not work (well). – sleske Nov 09 '12 at 08:37
  • Hmm I'll try this over the weekend and report back – Cyrax Nov 10 '12 at 00:06