Memos to me, going to scratch them together and file them without comment.

	

Mainly I write this as memo to myself.

Did think about howto layout the branches best for minilib.

I came to the conclusion, the "master" branch shouldn't include all 
scripts and so on, I'm using for the development.

Furthermore, I like to check, whether the minilib compiles not only 
within the current working dir.

E.g., in the directory tools is the tool "shrinkelf".
Which shrinks elf binaries.

I did make the compile (by mistake) dependent on this tool.

In the real development branch I didn't notice the dependency;
lthough I already made a simple test environment,
ll test went through without problem.

Only when I checked out later the updated master branch,
realized, it wouldn't be possible to work with a copy of minilib
without getting error messages.


Since the interdependencies are already hard to track,
I did need a possibility to check.
____

So, here's my layout: (google wasn't soo helpful, so I better keep it here,
also for myself)


Keep a local repository directory: 
in the target dir, `git init --bare`

add this to the devel repo:
`git remote add local file://path-to-dir`

push there as normally.
Create a "git" subdirectory, containing two files:

_devel.files_
  include all filenames and paths there, 
	which are to be included in the devel-branch.

_master.files_
 all files, which are to be included in the devel and master branch.


create another directory, in this directory:
`git clone file://path-to-dir/reponame`


then .. 
Basically checkout git/master.files and git/devel.files
`git checkout origin/devel git`

checkout only these files
`git checkout origin/devel $(cat git/files)`


try whether everything's right.
`make test` or whatever

Then: `git push`.


So - that's how it is possible, to have different branches containing 
different filesets; while also checking whether the filesets work.


It's also the way, how I can keep a repository tracking closely 
all the changes I do, while developing, 
while making clear it's a "development branch".


So - there's 

- minilib/master
	The main branch, to be cloned, usable and tidy

- minilib/devel
	The devel branch; here are e.g. the scripts I use for generating headerfiles
	out of templates, and so on

- minilib/devel-HEAD
	My working backup dir.
	For others to see what I'm working on,
	as well as keeping a backup / being able to eventually revert changes I did.

(written 2019 / 03. "usable and tidy", ... ahem.
 and I detached the devel-head locally, for a some time now. Intentionally.)

	

... Personally I don't prefer markdown.

There are some things wrong - I edit mainly within vim.

And I'd prefer having sort of the same layout within vi, 

as when rendered online.

E.g. linebreaks. Now I'm adding many \
 tags. 
Which is. Not so good.

Another example: headings.
It's just the wrong direction - 
One \# should be rendered smallest
and \###### biggest.


Just now I'm checking the other possiblities.

Ok. Firstly, it works. Just add another ending then .md
A list of supported formats is at ->https://github.com/github/markup

;) 

- textile Seems to be intuitive to me. 
  ->(https://www.promptworks.com/textile/writing-paragraph-text#simple-paragraphs)
  .. Im nearly convinced by textile.
	Orgmode seems to be a bit of an overkill.
	And hard to use without all these predefined keys.
	the textile guys got many things right. 
	Like \_something_ to be rendered kursively.
	This just feels right.
	Or the thing with the linebreaks.

	Although I admire tex and its ability for rendering,
	rendering for the web somehow has another target.
	I guess, it's the difference of the intention.


- orgmode -  Looks good. Very good. It's more a whole organization system, 
   based on tags.
 It's originally for emacs. But there's also a vim plugin out there
 ->https://github.com/jceb/vim-orgmode
 it's also an outliner, todo list, and so on..