foreword ;-) : Most people (including me) work with git in a client-server mindset I think („there's this remote repo on the dedicated server, from which you pull and push and not touch otherwise...“) I recall however, that git
is basically absolute peer-to-peer, there is not truly a central server.
So, here's my question:
Are there any problems to have one git repo my machine (~/frank/repo
), and one on my “household” fileshare (smb://myshare/somewhere
) connecting them mutually to each other as remote repo and work on either one?
- The benefit being, that at home several PCs in the LAN could directly work on that fileshare server and/while when I am on the road, I will work on my laptop.
- Doing the pulling/rebasing next time I hit home. So yeah, neither side can push, only commit while away, but not a problem for me.
- I simply want to avoid a third git repository (the classic „server“).
- both btw being “non-bare” repos (as in working repos), not running a git server/daemon on any port. Truly just a fileshare...
purpose:
I am not doing source code work in this scenario, only „document shuffling“, so now branching or major merge conflicts to be expected. But I do want to have some basic versioning and security against accidental deletion, and a bit of journaling info (who added when what), thus rsync
, xcopy
, will not suit my needs...
I have some past experience with a local bare repo I used to add as second remote (besides github), to push against when trying out things. No server/daemon/thread involved back then, too. The only thing I am essentially about to change is to use a „non-bare“ this time and also work in there,to)