Re: [Amforth] git question/moving to sourchut

[Dieter S. <di...@sc...>]

Dear all,


first, erich, thank you for your kind remarks on my notes!


git is just a tool, and the project/users should dictate its usage.

So if you find a way which suits you, then this is the way to do it.

On the current setup:

If you have all the releases in a file tree, you can use all kinds of 
(shell) tools to compare/find

and do not depend on git. It uses a bit more disk space than branches, 
but nowadays that should

be no big issue. Using git tricks (like I demonstrated) is a bit of a 
vendor-lock-in.

other ideas:

* whoever is not interested in the releases could do a "sparse checkout" 
and only get trunk/.

* if there is need for tags, those can be introduced anytime.


kind regards,

dieter



On 25.04.21 12:10, Erich Wälde wrote:
> Dear AmForthers,
>
>
> despite Dieters excellent demonstration of how to deal with branches:
>
>> Dear Erich,
>> One of the easiest ways to look for the evolution of a file is
>> $ git log --all --graph
>> This lists all commits, where  was changed, and rather nice ascii-art graphs.
>> The --all flag looks into all branches.
>> If you want to do more sophisticated actions per file/branch, you will have to use "git plumbing" functions.
>> Plumbing functions are for low-level tasks, and are more appropriate for scripts.
>> For example:
>> file=tools/amforth-upload.py
>> for branch in $(git for-each-ref    --format='%(refname)'   refs/heads); do
>>      br=$(echo $branch | sed "s/.*///")
>>      echo $br $(git show $br:$file | md5sum | cut -f1 -d" ") ; done
>> done
>> produces a list of md5 sums for each branch where file occurs.
>> git for-each-ref    --format='%(refname)'   refs/heads : produces a list of branches
>>
>> git show :                       : prints the contents of the file at branch
>> The rest of the code is just for nicer outputs.
>> There are a multitude of methods to perform a given task in git.
>> Sometimes there are just too many flags and commands...
>> Kind regards,
>> Dieter
>
> I found another reason to stay with the releases folder as a
> folder.
>
> I do have quite a collection of "projects" using AmForth. Since
> they were created at diffent times and for different purposes,
> they point to specific releases of AmForth most of the time.
> Just a quick look through one of my trees:
>> ew@ceres:~/Forth/atmega2 18 > find . -iname makefile -exec grep '^AMFORTH=' {} \; | sort -u
>> AMFORTH=~/Forth/amforth/releases/4.0/core
>> AMFORTH=~/Forth/amforth/releases/5.0/core
>> AMFORTH=~/Forth/amforth/releases/5.5/core
>> AMFORTH=~/Forth/amforth/releases/5.5/core
>> AMFORTH=~/Forth/amforth/releases/6.3
>> AMFORTH=~/Forth/amforth/releases/6.4
>> AMFORTH=~/Forth/amforth/releases/6.6
>> AMFORTH=~/Forth/amforth/releases/6.8
>> AMFORTH=~/Forth/amforth/releases/6.8
>> AMFORTH=~/Forth/amforth/releases/6.9
>> AMFORTH=~/Forth/amforth/trunk
> This option ceases to exist with branches. I am of course not
> willing to check out the correct Version, even automatically, in
> order to build AmForth just now in just this folder.
>
> Yes, yes. I know, it is not git'ish.
>
>
> In order to experiment I created another repository at
> https://git.sr.ht/~amforth/code-tree
>
> These commands were used to create it:
>> cd path/to/your/favourite/place
>> mkdir amforth.git
>> cd amforth.git
>> svn2git https://svn.code.sf.net/p/amforth/code --rootistrunk
>> ls
>> # releases/  trunk/
>> du -sm .
>> # 569   .
>> git remote add origin gi...@gi...:~amforth/code-tree
>> git push --set-upstream origin master
> sourcehut helpfully points out, that it does not see a License
> file :)
>
>
> So we see unfolding that "migrations" are possibly more involved
> than anticipated. The true effort involved remains unknown until
> you actually made it.
>
> So, any other ideas?
> Move the releases folder into what is now trunk?
> Move the external, bit rotting amforth-community repository into
> what is now trunk, too?
>
>
>
> Cheers,
> Erich
>
>
>
>