From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: literate programming, development log -- ideas? (ominbus reply)
Date: Sun, 13 Jun 2021 10:46:54 +1000 [thread overview]
Message-ID: <87o8cafuex.fsf@gmail.com> (raw)
In-Reply-To: <da7024b2-2d35-4176-89ec-7421730fbbca@www.fastmail.com>
"Samuel Banya" <sbanya@fastmail.com> writes:
> Not sure if it counts as off-topic for this thread, but does everyone use Git to manage their Org docs and notes?
>
> I ask because of Greg's previous post.
>
> I've noticed that some times after git merge events across a few machines (ex: I forgot I had already pushed notes for my private notes on one machine,
> and had to merge the results from another machine), I'll get weird "HEAD" and "END" statements inserted by Git.
>
> Also, combined with some tasks duplicating as a result was annoying.
>
> Was debating if this is just something I'd have to deal with, or if there might be a better versioning workflow (ex: just using rsync, etc)
>
> Would be curious on everyone's thoughts.
>
> ~ Sam
>
I use git as the master and then checkout to whatever machine I'm working
on. I tend to have at least 3 different machines I'm working on (home
Linux, work Linux and Macbook).
On each machine, I will checkout from master and then create a 'local'
branch where I make any local changes. When I'm finished working
locally, I will commit to the local branch, switch to the master branch,
do a pull. If no changes are pulled, then I will merge in the local
branch and push up to the master repository. If changes are pulled, then
I will make a decision whether to use rebase to add those changes to my
local branch or just merge. Deciding on which depends on the types of
things changed, size of what has changed etc.
I find rebasing and merging is often the best approach to keeping commit
logs fairly clean and linear. However, that will depend on what is being
changed and the amount of changes. Frequent pulling and either merging
and rebasing is useful.
Creating new branches (both just locally and within the master
repository) is a very lightweight operation. I use lots of branches and
will regularly go back through and get rid of old branches when no
longer needed (i.e. changes in the branch have been merged into master
or the branch topic is no longer relevant/needed etc). Understanding the
difference between a rebase and a fast-forward merge is important.
Likewise, using branches effectively is critical. My master branch tends
to be quite clean - I almost never make changes directly in the master
branch. Everything happens in another branch and later merged into the
master when ready.
next prev parent reply other threads:[~2021-06-13 1:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 11:43 literate programming, development log -- ideas? Greg Minshall
2021-06-07 12:00 ` Juan Manuel Macías
2021-06-08 17:15 ` literate programming, development log -- ideas? (ominbus reply) Greg Minshall
2021-06-08 17:21 ` Samuel Banya
2021-06-09 8:59 ` Eric S Fraga
2021-06-09 22:21 ` Dr. Arne Babenhauserheide
2021-06-10 22:07 ` Samuel Wales
2021-06-11 0:13 ` Samuel Banya
2021-06-11 14:30 ` Juan Manuel Macías
2021-06-11 15:02 ` Samuel Banya
2021-06-09 14:52 ` Maxim Nikulin
2021-06-10 13:28 ` Greg Minshall
2021-06-11 19:51 ` Christian Barthel
2021-06-13 0:46 ` Tim Cross [this message]
2021-06-13 15:48 ` Samuel Banya
2021-06-13 23:13 ` Tim Cross
2021-06-09 8:57 ` Eric S Fraga
2021-06-13 0:31 ` Tim Cross
2021-06-13 4:27 ` Greg Minshall
2021-06-13 7:29 ` Tim Cross
2021-06-14 6:14 ` Greg Minshall
2021-06-07 12:08 ` literate programming, development log -- ideas? Eric S Fraga
2021-06-13 0:24 ` Tim Cross
2021-06-13 15:44 ` Samuel Banya
2021-06-14 12:57 ` Greg Minshall
2021-06-07 13:53 ` Dr. Arne Babenhauserheide
2021-06-07 17:59 ` briangpowell
2021-06-07 23:17 ` Dr. Arne Babenhauserheide
2021-06-08 2:06 ` Samuel Banya
2021-06-08 3:23 ` Greg Minshall
2021-06-08 3:31 ` Samuel Banya
2021-06-08 6:15 ` Greg Minshall
2021-06-08 16:59 ` Greg Minshall
2021-06-07 19:19 ` Jack Kamm
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=87o8cafuex.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).