I appreciate that Git offers the opportunity to experiment without
affecting others. At the moment we achieve this with subversion
branches, and would probably do the same under git (with my limited
knowledge of git). In this way the code is revision controlled
centrally, and unreliant on any one developers computer.
Having said that offline working does present problems for us with
subversion, what I'm looking for is a way to locally revision control
changes and then to push them to the central server when possible. Git
certainly address this.
I would like to agree with you on your personal hygiene point, but if
some work is lost (experimental or not) then this will have an impact
on our organisation because it will have to be repeated (and may not
turn out the same). Yes, the devs are capable of keeping their area
tidy, but if a backup schedule takes the risk out and means they can
concentrate on the job in hand then this must be better. Of course
they should still tidy up, but at least nothing can be lost.
So that's my reasoning behind having per developer de-centralised
repositories on the network rather than local. I had not realised that
it was such a corner case setup.
Without a definite 'no' my next steps will be to try it out, once I've
figured out the basics of git and git-svn anyway.
Thanks for your responses,
On Jul 8, 4:14 pm, Konstantin Khomoutov
> On Fri, 8 Jul 2011 05:50:41 -0700 (PDT)
> Craig <shadycr...@gmail.com> wrote:
> > There's no accounting for users! (Not that I qualify yet...)
> > The problem with using a VCS to do backup is that you have to rely on
> > the users to do it, backups should run independently of the user.
> > It's guaranteed given time that some project or code will end up bring
> > useful but not committed and subsequently lost.
> > Really only units of work or discreet changes should be committed,
> > rather than the end of the last bug fix and the start of the next.
> > Without getting too sidetracked can anyone answer my original
> > question?
> While you're correct about me sidetracking the discussion, I feel
> oblidged to point out that liberating the developer from using one
> central repo (like in Subversion) exactly provides the possibility to
> play with different wild ideas, write crazy code and so on without
> "spoiling" the main repository. This has been touted numerous times
> as one of the upsides of DVCSes. Hence if you have a place to push
> your work without the fear of disturbing other people the problem
> becomes purely social. So I think what's needed is providing the devs
> with their backup repos and explaining them that backing up their work
> is just a matter of personal hygiene. After all I can barely beleive
> that people who managed to master Git are so stupid not to understand
> these matters provided you provided them with the necessary
> Returning to the technical side, I'd be afraid about stuff like .
> Of course, YMMV depending on precise systems setup but still I doubt
> convoluted setups such as the one you're proposing receive much testing.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at