On Thursday 12 August 2010 19:02:49 Brandon Casey wrote:
> Brian Foster wrote:
> > Bare repository ORIG's master looks like this [ I've updated
> > all of the diagrams slightly to remove some confusion -blf]:
> >
> > o--o--o--o--v1--o--v2--o--o--o [master &] HEAD
> >
> > where v1 and v2 are (annotated) tagged commits.
> >
> > Repository SLAVE is a mirror clone of ORIG which
> > (very deliberately!) lags behind (i.e., [SLAVE's master's head]
> > is one of the earlier (and usually tagged) commits
> > on ORIG). SLAVE's master was like this:
> >
> > o--o--o--o--v1 [master &] HEAD
> >
> > We wanted to update [SLAVE's master's head] to v2, so did:
> >
> > git fetch ORIG tag v2
> >
> > This gave us:
> >
> > o--o--o--o--v1 [master &] HEAD
> > \
> > o--v2
> >
> > It did not update SLAVE's [master's head] to v2, which we wanted[:]
o--o--o--o--v1--o--v2 [master &] HEAD
> Are you using --mirror only so that the branch pointer in
> the mirror repository will be updated when you fetch?
Correct.
> If you are not really interested in having a "real" mirror,
> then maybe you should set your mirror up to track a
> specific branch (or branches) in the mirrored repository.
Now that seems like an excellent idea!
The embarrassing thing is, we actually do _do_ something
similar elsewhere in the process. So we haven't got any
great excuse for not thinking of it .... ;-\
> You could have a branch named for example "for_mirror/master",
> in the mirrored repository (ORIG) that you would prepare.
> You could update the for_mirror/master branch when you were
> ready using 'git branch' like this:
>
> git branch -f for_mirror/master v2
>
> In the mirror repository (SLAVE), you would update the
> fetchspec so that the mirror mirrored the branches below
> the "for_mirror" namespace in the remote repository
> like this:
>
> fetch = +refs/heads/for_mirror/*:refs/heads/*
>
> Then, a simple 'git fetch' would fetch the updates (including
> tags) and update the branch pointer in the mirror like you want
> it to do. Tracking multiple branches this way is possible just
> by creating another branch in the ORIG repository with the proper
> name.
Another nice point about the above is it could deal
with another procedural issue we have, which is the
lack of a “staging area” for final test (a “pre-SLAVE”).
Whilst we haven't (yet) had any (known) screw-ups in
the final released system (what “mirror” SLAVE contains),
it can happen. The known screw-ups were all detected
before it went to SLAVE, but by accident (IM(H?)O).
Thanks for the idea/observation.
cheers!
-blf-
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html