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 23:57:19 -0500 Message-ID: <87myc5alhs.fsf@legolas.norang.ca> References: <7bef1f890902272111l7611d157k984ca50251f20df6@mail.gmail.com> <871vti7klg.fsf@gollum.intra.norang.ca> <87r61ie3h9.fsf@kassiopeya.MSHEIMNETZ> <87skly5o18.fsf@gollum.intra.norang.ca> <87fxhydxll.fsf@kassiopeya.MSHEIMNETZ> <87eixi6o9x.fsf@kassiopeya.MSHEIMNETZ> <7bef1f890902281810n1ccda333yada4e62082bd92c8@mail.gmail.com> <87zlg655pk.fsf@kassiopeya.MSHEIMNETZ> <7bef1f890902281903xa296051xa844059dd4e392a7@mail.gmail.com> <7bef1f890902281904n48e02018lb7935e4defd8fe66@mail.gmail.com> <7bef1f890902281905w1c76e6cs25d676d36b6e71a7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lddjw-0001Mn-QN for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 23:57:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lddju-0001KV-7H for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 23:57:24 -0500 Received: from [199.232.76.173] (port=35961 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lddju-0001KS-1u for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 23:57:22 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]:51864) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lddjt-0001pn-Q3 for emacs-orgmode@gnu.org; Sat, 28 Feb 2009 23:57:21 -0500 In-Reply-To: <7bef1f890902281905w1c76e6cs25d676d36b6e71a7@mail.gmail.com> (Alan E. Davis's message of "Sun\, 1 Mar 2009 13\:05\:28 +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 "Alan E. Davis" writes: > One more point: > > May I ask for an example of a case when branching would make sense in > the context of this synchronization usage of Git? Here are a couple: I don't use multiple branches for my org repos. But I do use branches extensively on coding projects. ------------------------------------------------------------------------ I code for a living. When working on a project I make a branch for a topic during development and keep the changes related to that topic isolated on the topic branch until they are ready to be merged into the main development branch. My repo looks something like this: o--o--o--o--A (master - main development branch) Then I start a new topic creating a branch at A o--o--o--o--A (master) \ o--o--B (topic B) New work can be added to the master branch as other development topics are merged in o--o--o--o--A--o--o (master) \ o--o--B (topic B) Now when I need to take this code with me I push master and the topic branch(es) to the usb stick so I can continue working on them offline. I'm free to continue development on my laptop and move the changes back to my workstation. When I merge the topic branch into the main branch I delete the topic (and remove it from the usb stick repo). The topic branch stays as a set of discreet commits all directly related to the topic. Commits for other topics go on other branches (yes I have branches that are simply 1 commit). Branches are cheap and easy in git. I rarely work directly on the master branch. Having the flexibility to keep topic branches clean and isolated from other changes is a huge help when developing multiple features on a project. You can merge in only the topics that are ready and keep working on the others. You are free to merge topic branches into the main branch in whatever order makes sense for the project. ------------------------------------------------------------------------ On another project I have 68 topic branches which are merged into 4 integration branches in various combinations. I only push the master, and 4 integration branches to the usb stick. I can recreate any topic branch easily from the integration branch history and I find it alot easier to manage all of these branches by only tracking the integration branches on the usb stick. ------------------------------------------------------------------------ Another example is code for a website. If this is deployed on a test webserver and a production webserver you can easily set up 3 branches as follows: o--o--o--o--o--o--o--o master (common code) \ \ \ o--o--o--o test-config \ o--o--o prod-config where test-config is the set of configuration changes to make the website work on the test environment and prod-config is the set of changes to make the system work in production. You would normally want all 3 branches available so that if you make some change that required updating configuration information on the test and prod branch you can keep the changes isolated on the appropriate configuration branch. To actually run the code in test you make an temporary integration branch (test) at master and merge in the test-config branch. The result should be ready to use on your test environment. When you're done testing you can simply delete the test branch. It's a throw-away since you can recreate it again easily as needed. ------------------------------------------------------------------------ I don't use this added flexibility on my org-mode repos. I don't have topics where it makes sense to isolate changes while organizing things. I use git with org-mode mainly as a safety net so I can easily do oops type edits, as a backup of my org notes, and an easy way to synchronize between my workstation and laptop. My organizational notes are all over the place by nature and trying to separate that into discreet topics in org-mode doesn't make any sense to me. Does any of that help? -Bernt