On 9 May 2018 at 08:10, Brian May via luv-main <luv-main@luv.asn.au> wrote:
Russell Coker via luv-main <luv-main@luv.asn.au> writes:
It seems that I have to create the master repository with "git init --bare" and then push from the slave after adding a file. Adding a file on the master is also apparently a bad idea.
I think that a shared repository (where every one commits changes to) is not meant to have local (unchecked in) changes as it makes things messy. There are several styles of managing shared work - if you want several checkouts synching in at different times - one common bare repository makes this simpler to agree on the official version. But you can have multiple trees - then usual style is to have a tracking branch for each tree. Each person can then merge in via their tracking branch and when up to date (like subversion) and then push their changes to that tree. One style is each feature is a separate branch with developers committing to that feature branch. As features stabilise some one will merge that branch into a stable branch for testing / release. git is *much* faster than subversion and handles very large packages like the kernel. It also allows you to re-write your history (unlike subversion) and handles multiple simultaneous threads of history which can be merged together and preserve their separate time lines unlike subversion. I've used both subversion and git and despite some painful learning I much prefer git. It is worth persevering with - but take it in steps. It's really worth understanding that it uses hashes to index the code snapshots - which makes it vastly faster to see if two directories/files are changed. Andrew