Re: literate programming, development log -- ideas? (ominbus reply)

["Samuel Banya" <sbanya@fastmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]

Hey Tim,

Wow that's an awesome idea too aka to create local branches on each machine, and then switch over the master branch to pull them in.

Do you have any video references for this kind of thing?

I like videos first, and then documentation.

It would really help me out since I'd love to try to figure this kind of thing out, since I am pretty close to just using rsync for my Git notes going forward, but needed that kind of convincing otherwise.

On Sun, Jun 13, 2021, at 12:46 AM, Tim Cross wrote:
> 
> "Samuel Banya" <sbanya@fastmail.com <mailto:sbanya%40fastmail.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. 
> 
> 

[-- Attachment #2: Type: text/html, Size: 4010 bytes --]