emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bernt Hansen <bernt@norang.ca>
To: "Alan E. Davis" <lngndvs@gmail.com>
Cc: emacs-orgmode Mailinglist <emacs-orgmode@gnu.org>
Subject: Re: MORE: Using git via USB for personal org dir and other data files
Date: Sat, 28 Feb 2009 23:57:19 -0500	[thread overview]
Message-ID: <87myc5alhs.fsf@legolas.norang.ca> (raw)
In-Reply-To: <7bef1f890902281905w1c76e6cs25d676d36b6e71a7@mail.gmail.com> (Alan E. Davis's message of "Sun\, 1 Mar 2009 13\:05\:28 +1000")

"Alan E. Davis" <lngndvs@gmail.com> 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

  reply	other threads:[~2009-03-01  4:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-28  5:11 Alan E. Davis
2009-02-28 11:58 ` Ian Barton
2009-02-28 13:32 ` Bernt Hansen
2009-02-28 20:00   ` Sebastian Rose
2009-02-28 20:01     ` Bernt Hansen
2009-02-28 22:07       ` Sebastian Rose
2009-03-01  1:10         ` Sebastian Rose
     [not found]           ` <7bef1f890902281810n1ccda333yada4e62082bd92c8@mail.gmail.com>
     [not found]             ` <87zlg655pk.fsf@kassiopeya.MSHEIMNETZ>
     [not found]               ` <7bef1f890902281903xa296051xa844059dd4e392a7@mail.gmail.com>
2009-03-01  3:04                 ` Alan E. Davis
2009-03-01  3:05                   ` Alan E. Davis
2009-03-01  4:57                     ` Bernt Hansen [this message]
2009-03-01  4:10                   ` Bernt Hansen
2009-03-01 15:07                     ` Sebastian Rose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87myc5alhs.fsf@legolas.norang.ca \
    --to=bernt@norang.ca \
    --cc=emacs-orgmode@gnu.org \
    --cc=lngndvs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).