From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernt Hansen Subject: Re: MORE: Using git via USB for personal org dir and other data files Date: Sat, 28 Feb 2009 08:32:43 -0500 Message-ID: <871vti7klg.fsf@gollum.intra.norang.ca> References: <7bef1f890902272111l7611d157k984ca50251f20df6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdPJG-0000W6-Lm for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 08:32:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdPJF-0000VP-OI for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 08:32:54 -0500 Received: from [199.232.76.173] (port=48287 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdPJF-0000VK-Ko for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 08:32:53 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]:63630) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LdPJF-0004sZ-9p for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 08:32:53 -0500 In-Reply-To: <7bef1f890902272111l7611d157k984ca50251f20df6@mail.gmail.com> (Alan E. Davis's message of "Sat\, 28 Feb 2009 15\:11\:59 +1000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Alan E. Davis" Cc: emacs-orgmode Mailinglist Hi Alan, The best way to test drive all this stuff is just make some throw away repos to play with. $ mkdir /tmp/junk $ cd /path/to/your/org/git/repo $ git clone --bare . /tmp/junk/org.git $ cd /tmp/junk $ git clone org.git home $ git clone org.git work Now you have 3 repos in /tmp/junk work - pretends to be your repo at work home - pretends to be your repo at home org.git - your bare repo on the usb stick Now cd work, do stuff, git commit and git push then cd home, git pull, do more work, git commit, git push etc. Since these are just junk repos for experimenting you don't have to worry about messing them up and you can just rm -rf /tmp/junk when you're done. Comments follow: "Alan E. Davis" writes: > Regarding the synchronizing of directories on two or more machines, using= a USB Stick.=C2=A0 Further questions after a bit of experimentation.=C2=A0 > =C2=A0 > I am currently keeping two workstations up to date via a USB flash drive,= and have had, variously, both good and bad luck. Here are some questions: > > 1.=C2=A0 I understand the idea, finally, of using a "bare" repo on the fi= ash drive, at least in part.=C2=A0 But what will I do if the bare repo fail= s to merge because two versions are pushed or pulled to it from > the two machines, of a file.=C2=A0 I've wasted a bit of time and now have= gotten "meld" installed as the mergetool.=C2=A0 Still, sometimes even that= doesn't work.=C2=A0 Today I have two flash drives in use, one that > was working fine to update from one machine, but won't even accept a file= from the other.=C2=A0 I have clumsily deleted the old version from the USB= drive, and copied over the other version, done git rm > git add and git commit -a, but the file refuses to insta= ll.=C2=A0 I'm not going to ask this as a primary question, because I think = I need to just understand the underlying idea of using a > bare repo, and not editing it at all.=C2=A0 > You never merge on the bare repo. You do all of the merging on your working copies (home or work). Then pushes to the USB stick are always fast forward changes which just work. If you rebase and rewrite history you can force update on the usb stick with push -f -- just make sure you really want to overwrite the history on the usb stick with what you have now before you decide to do that. > > 2.=C2=A0 I have had poor luck with push. > > 3.=C2=A0 For this simple usage, is it even useful to think about branches= , and if so, how should branches be used? I use topic branches all the time. If I want to put a branch on the sub stick I use: $ git push usb my-branch When you fetch from the usb repo it will create any new branches as usb/my-branch. You can also delete branches when you're done with them with $ git push usb :my-branch to remove it from the usb stick repo. To remove them from your working directory later you can use $ git remote prune usb which finds any remote branch names (usb/*) that exist in your working directory that no longer appear on the remote (usb stick) and deletes them from your working directory repo. > > > 4.=C2=A0 Is it wiser to fetch than to pull?=C2=A0 I have seen this sugges= ted, but don't understand the use of fetch. pull =3D fetch + merge (or fetch + rebase) depending on the branch setup. I personally fetch first, and if git status stays it's a fast forward merge then I pull. > > > Here is a rough idea of what I think I need to do now.=C2=A0 Please comme= nt on any ommissions or problems: > > At home, on my primarly workstation: > 1. cd to a directory with a good tree (perhaps ~/org) already under git c= ontrol. > 2. insert the USB drive (I have a label "BLUE" on my usb drive.=C2=A0 On = my gnome/ubuntu box, it automounts as /media/BLUE) > 3. git clone --bare . /media/BLUE/org.git This creates the repo with all of your branches in this working directory. > > 4. git remote add BLUE /media/BLUE/org.git > 5. ??=C2=A0 git push BLUE (master?) You don't need this after the clone - the new clone on the usb drive is up to date - it doesn't hurt though :) > > > Now at work, I am on the other workstation: > 1. git clone /media/BLUE/org.git > 2. can I now do this?: git remote add BLUE /media/BLUE/org.git After you clone the repo in step 1 the remote is added automatically with the name 'origin'. This would add a second remote (at the same location) but with a different name (BLUE). You really don't need to do this -- you can just use the remote 'origin' but again it doesn't hurt anything. > > 2. work > 3. git push BLUE ??? That pushes any new commits on master back to your BLUE remote. The push will fail if the update is not a fast forward. (ie if you added stuff to the usb stick from somewhere else since you fetched last then the push will fail). In that case you need to fetch + merge first (git pull) and resolve any conflicts you might have. > 4. > > Back at home > 1. git fetch BLUE ??=C2=A0 or git pull BLUE ?? > I would just do git pull (which is fetch + merge) If you fetch only you'll have this: o--o--H (tip master on home) \ o--o--W (time of usb/master with new commits from work) and after a fetch you can easily see this in gitk $ git gitk master origin/master (or if you don't have tons of branches just gitk --all) If you pull it will advance H (your master on the home repo) so it is at W. This is normally what you want to do. > > I am confused at a couple of points here.=C2=A0 > > Much of the above I have gleaned from three posts by Bernt Hansen.=C2=A0 = Other sources on line include some postings on the very problem of syncing = machines using git.=C2=A0 > > Can I pull from /media/BLUE/org.git ? Yes you can (and for this setup I would recommend that as your normal mode of operation). AT work: $ git pull BLUE [*1*] $ git push BLUE At home: $ git pull BLUE $ git push BLUE > > Well, perhaps this is enough confusion for now.=C2=A0 Thanks for all the = suggestions on this list.=C2=A0 I think it's going to work, and I'll expand= this to other directories as well. As I said up front - just play with it in /tmp until you're comfortable. Regards, Bernt