On Jun 24, 10:56 am, Konstantin Khomoutov <khomou...@gmail.com> 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 git-users@googlegroups.com
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to