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 g...@git.sr.ht:~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






_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Reply via email to