On Jun 24, 10:56 am, Konstantin Khomoutov <[email protected]> wrote: > > I am interested in using git as a versioning and backup solution for > > my work. > [...] > > I have access to a networked drive and my computers' local drives. I > > would like to be able to access my repository from a number of > > computers, all of which have access to the networked drive. > > "Backup" solution can be achieved by combining `git push --mirror > ORIGIN` for "saving" data and `git fetch ORIGIN` (plus necessary fast- > forwarding of local branch(es)) for getting the data back into another > local repo, with ORIGIN being set up to point to the backup repo. > > I use similar workflow (though my "backup" repo is accessible via SSH) > and it can be set like this: > > 1) Create a bare repository on your networked drive using `git init -- > bare`. > > 2) In your work directory run `git init` to make it managed by Git. > What results, will be assumed to be our first local repo in this > setup. > > 3) Create a "remote" named "origin" pointing to your backup repo: > git remote add origin file://path/to/your/backup/repo > > It should be noted that you could call it any way you like, say, > "backup", but the name "origin" is special because that's what Git > creates for the remote repo when you clone it using `git clone`. So > using "origin" in our case makes setup more unified with the common > case. > > 4) Create a convenience alias for pushing the changes: > git config alias.backup 'push --mirror origin' > > This step is absolutely unnecessary, it just makes things simpler. > > 5) Add the files, make the root commit and "back up" the local repo by > running > git backup > which will result in running > git push --mirror origin > > 6) Now the trick is to make the "master" branch in the local repo > track the backup repo. This is just to make our local repo look as if > it was cloned from the backup repo. > The simplest way to do this is to just recreate the master branch: > a) Run `git log` and find out what's the name of the initial commit. > b) Check that commit out: > git checkout COMMIT > c) Delete the master branch: > git branch -d master > d) Get the up-to-date state of the backup repo (which will bring its > master branch in): > git fetch origin > e) Make your local master branch track that of the backup repo: > git checkout -b master origin/master > > (I'm sure there's more logical way to do this, but I have never > managed to understand how I can make an existing local branch to track > a remote branch just by running `git something`.) > > To set up another local repo, just clone the backup repo: > git clone file://path/to/your/backup/repo > and then configure the "backup" alias for it, if desired. > > Now the workflow is like this: > 1) Make some changes to a local repo. > 2) Run `git backup` to push all the changes to the backup repo. > ...and on another local repo: > 3) Get the changes from the backup repo: > git pull > 4) Return to point 1. > > Observe three subtleties: > > 1) `git pull` tries to merge changes from the remote branch it is set > to track. That is, if you are on the "master" branch in your local > repo, and do `git pull`, you will get your local "master" branch fast- > forwarded to the "master" branch as was backed up from another local > repo. So, if on the first local repo you did some work on another > branch (say, "another"), and then "backed it up", on another local > repo you probably want to get that another branch. This has to be done > by hand: > git fetch > git checkout -b another origin/another > > 2) While `git push --mirror` pushes all possible changes to the > specified remote repo, `git fetch` (which is used by `git pull` also) > omits tags which are unreachable from any fetched branches. > Unreachable tags can be useful sometimes though, and if you pushed > some of them from one local repo, you had to explicitly get them into > another using > git fetch -t > > 3) This workflow assumes you have no local modifications on your local > branch when you do `git pull`.
Hi Konstantin, Somewhere between steps 2 and 5 shouldn't there be a 'git add .' and a 'git commit -m "some message"' ? -gyro --~--~---------~--~----~------------~-------~--~----~ 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 protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/git-users?hl=en -~----------~----~----~----~------~----~------~--~---
