- Oberon - mailman3.inf.ethz.ch

A2 startup. Was Git usage for A2.
by peter＠easthope.ca 02 Jul '23

02 Jul '23

The subject of my earlier message was badly chosen. "A2 startup" would have been better. ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Git usage for A2.
by peter＠easthope.ca 01 Jul '23

01 Jul '23

Starting UnixAos is simple enough. cd <myWorkingDirectory> aos Starting repository based UnixA2 involves a2.sh, a2.txt, oberon.ini, directory "work" and pseudo-volume WORK. Definitely a larger challenge for a novice. I've added some explanation at the foot of this section. https://en.wikibooks.org/wiki/Oberon/A2#Git_in_a_Unix-like_System Difficulties? Errors? Feedback appreciated. Thx, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re (2): Re (2): Git usage for A2.
by peter＠easthope.ca 29 Jun '23

29 Jun '23

From: Michael Schierl <schierlm(a)gmx.de> Date: Sun, 25 Jun 2023 18:38:45 +0200 > > Now you might think "Why did I respond to Peter's first question?" > > I don't get this. I respond to a question when I think I can answer it, > not related whether it is their "first" or not "first" question. Thanks. Some mailing list readers can be annoyed when an answer to a question brings several more questions. > I assume you mean after the empty directory has been filled with > both the work tree and the local repository? Yes. Also found https://en.wikipedia.org . The 2nd paragraph mentions "... every Git directory on every computer is a full-fledged repository ..." Here, the diagram helps to understand the relationships. https://en.wikipedia.org/wiki/Git#Data_structures > > HYPOTHESIS: a file in the local repository is never edited directly. > > A file in the work tree can be edited directly. Possibly more accurate. A file in the local branch is rarely edited directly. A file in "work files" can be edited directly. > [Staging area] Surely mentioned at lots of places :-) Near the lower right corner of the diagram and other places. > The staging area is part of your local repository ... > ... > Git solves this using the staging area. > ... > When doing a commit, you have to decide whether you want to commit > from the staging area (if you give no flags) or from the work tree (if > you give the "-a" flag). > So in your example using the staging area you would do > ... > Without using the staging area, you would do: > ... My instructions for using A2 from a repository in a *nix system are here. https://en.wikibooks.org/wiki/Oberon/A2#Git_in_a_Unix-like_System Corrections and suggestions from anyone welcome. Thanks! ,,, P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re: [Oberon] Re (2): Git usage for A2.
by Michael Schierl 25 Jun '23

25 Jun '23

Hello Peter, Am 25.06.2023 um 18:00 schrieb peter(a)easthope.ca: > From: Michael Schierl <schierlm(a)gmail.com> > Now you might think "Why did I respond to Peter's first question?" I don't get this. I respond to a question when I think I can answer it, not related whether it is their "first" or not "first" question. > Git doesn't give a name to the "empty directory" does it? "Repository > container directory"?. I assume you mean after the empty directory has been filled with both the work tree and the local repository? Some people just call it a "git clone" like the command that created it. But it is misleading when you did not create it by the clone command. And to be honest I never had a need to refer to it specifically. >> git checkout -b somebranch --track bar/somebranch >> git branch -D main > > What about bar? > git checkout -b somebranch --track bar/somebranch When you want to work on a branch, you have to decide which repository it should come from. In that case, you create a branch called "somebranch" which tracks the branch "somebranch" of your "bar" remote repository. "tracking" means that if you fetch, pull or push while you have this branch active (checked out into your work tree) and do not specify a remote branch, that remote branch will be used. > HYPOTHESIS: a file in the local repository is never edited directly. > A file in the work tree can be edited directly. Very rarely at least. There are a few workflows where you may want to edit files in the repository directly (ones in the repository root, not some of the ones with hash names), but there should always be a way to avoid it if you feel uneasy. >> For completeness, "add" will move changes from your working tree to >> your staging area, > > Staging area? Not mentioned elsewhere. What, where is staging area? Surely mentioned at lots of places :-) If you don't trust Google, the Git Book <https://git-scm.com/book/en/v2> got you covered in <https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Reposito…> The staging area is part of your local repository where you can select what you want to commit in your next change. While you do not need to use the staging area, maybe it is helpful to know that it exists. Assume you are working on a new feature where you added X.Mod, heavily modified Y.Mod and added 2 lines to Z.Mod. While at another place of Z.Mod, you had to add 3 more lines which are not part of the feature, but need to be there while you test the new feature (either because they work around a bug you have not found time to track down or because they are part of another feature that modifies some other files). When you now want to push the changes relevant to that feature to a remote repository (to discuss them, or to submit them for inclusion upstream), you don't want to include those 3 lines in Z.Mod, yet maybe you don't want to delete them or you might forget adding them later. Subversion provided a "restore after commit" feature for that workflow, i.e. you mark your file "restore after commit", delete those 3 lines, commit the rest and the 3 lines magically appear again. Yet still, when you get interrupted before you finish your commit, those 3 lines are not in the file and you may wonder why something else does not work. Git solves this using the staging area. Some commands (e.g. "git add -p" or git gui) provide the way to choose the lines you want to stage. So on disk, Z.Mod is still with all 5 lines changed, yet when you do your commit (later), Z.Mod will only add 2 of them. "git diff" will show the 3 unstaged different lines and "git diff --staged" will show the 2 staged different lines). "git status" will show that the file is partially staged. When doing a commit, you have to decide whether you want to commit from the staging area (if you give no flags) or from the work tree (if you give the "-a" flag). So in your example using the staging area you would do git add -p Z.Mod # -- select which lines you want to add -- git add X.Mod Y.Mod # add changes in whole files to staging area git diff --staged # to see what you will commit git commit Without using the staging area, you would do: git add -N X.Mod # to add a new file without staging it cp Z.Mod Z.Mod.tmp # -- edit Z.Mod to remove the extra lines git diff # to see what you will commit git commit -a mv Z.Mod.tmp Z.Mod Regards, Michael

1 0

Re: [Oberon] Re (2): Git usage for A2.
by peter＠easthope.ca 25 Jun '23

25 Jun '23

From: Michael Schierl <schierlm(a)gmail.com> Date: Sat, 24 Jun 2023 13:53:30 +0200 > Apologies if you receive it twice. One copy here, thanks. Now you might think "Why did I respond to Peter's first question?" Fortunately the list is fairly quiet these days. =8~) > "git clone" is just a convenience command that calls "git init", "git > remote add", "git fetch" and "git checkout" with the most common > options (in addition to making a new directory for your repository if > you did not specify an existing empty one). There are cases where you > need options that are not exposed by "git clone" so you have to go the > long route. Helpful. Thanks. > In particular, it does not matter if you do in an empty directory ... Git doesn't give a name to the "empty directory" does it? "Repository container directory"?. > git init > git remote add foo https://foo > git remote add bar https://bar > git fetch foo > git fetch bar Among the three equivalent forms you gave, that one shows the foo and bar parallelism best. > git checkout -b somebranch --track bar/somebranch > git branch -D main What about bar? git checkout -b somebranch --track bar/somebranch > I deleted the main branch since it points to the main branch of the > repository you cloned from, or an empty orphan branch in case of "git > init". I need to think about that. > fetch (lfs or not) loads data from a remote repository to your local > repository, and checkout makes data from your local repository > available in your work tree. HYPOTHESIS: a file in the local repository is never edited directly. A file in the work tree can be edited directly. > "commit" will move from your staging area and/or > worktree to your local repository, commit is inverse of checkout? > "push" will move from your local repository to remote repositories. push is inverse of fetch? > For completeness, "add" will move changes from your working tree to > your staging area, Staging area? Not mentioned elsewhere. What, where is staging area? Thanks, ... P. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re: [Oberon] Re (2): Git usage for A2.
by Michael Schierl 24 Jun '23

24 Jun '23

[[re-sending this from my Gmail account since my primary address's provider seems to be blocked to send to the mailing list due to an expired Spamhaus listing. Apologies if you receive it twice.]] Hello, Am 23.06.2023 um 04:19 schrieb peter(a)easthope.ca: > After finding https://git-scm.com/docs/git-remote I wonder > why git clone https://gitlab.inf.ethz.ch/felixf/oberon.git > works before > git remote add https://gitlab.inf.ethz.ch/felixf/oberon.git "git clone" is just a convenience command that calls "git init", "git remote add", "git fetch" and "git checkout" with the most common options (in addition to making a new directory for your repository if you did not specify an existing empty one). There are cases where you need options that are not exposed by "git clone" so you have to go the long route. In particular, it does not matter if you do in an empty directory git clone https://foo . git remote rename origin foo git remote add bar https://bar git fetch bar git checkout -b somebranch --track bar/somebranch git branch -D main or git clone https://bar . git remote rename origin bar git remote add foo https://foo git fetch foo git checkout -b somebranch --track bar/somebranch git branch -D main or git init git remote add foo https://foo git remote add bar https://bar git fetch foo git fetch bar git checkout -b somebranch --track bar/somebranch git branch -D main Afterwards you have the same repository with the same branches and files, regardless which one you cloned first (if any). I deleted the main branch since it points to the main branch of the repository you cloned from, or an empty orphan branch in case of "git init". >>From a little reading, the large file repository is separate from the > git repository. Even without lfs, you have - your local repository (oberon/.git) - your working tree (oberon/* without .git) - one or more remote repositories Note that your local repository contains local branches (where you can commit to) as well as remote branches (which mirror the contents of a remote repository at the point in time you fetched the remote last time). > fetch brings a large file to my large file repository whereas checkout > makes the large file available in the git repository? fetch (lfs or not) loads data from a remote repository to your local repository, and checkout makes data from your local repository available in your work tree. The lfs commands use the same nomenclature, i. e. "lfs fetch" will download large files to your local repository while "lfs checkout" will make them available in your work tree. (For completeness, "add" will move changes from your working tree to your staging area, "commit" will move from your staging area and/or worktree to your local repository, and "push" will move from your local repository to remote repositories. "pull" is a convenience command for "fetch" followed by either "merge" or "rebase"). Regards, Michael

1 0

Re (2): Git usage for A2.
by peter＠easthope.ca 23 Jun '23

23 Jun '23

Michael, Thanks for your very helpful reply. Documents for git and for git-lfs being separate adds to the difficulty. For the Oberon-A2 world, I'm working on documentation here. https://en.wikibooks.org/wiki/Oberon/A2#Git_in_a_Unix-like_System Far from complete and several questions to answer. From: Michael Schierl <schierlm(a)gmx.de> Date: Thu, 22 Jun 2023 23:06:29 +0200 > ... assuming you have set your default remote. After finding https://git-scm.com/docs/git-remote I wonder why git clone https://gitlab.inf.ethz.ch/felixf/oberon.git works before git remote add https://gitlab.inf.ethz.ch/felixf/oberon.git >From a little reading, the large file repository is separate from the git repository. > git lfs fetch -I Linux64.zip origin main > ... > git lfs checkout fetch brings a large file to my large file repository whereas checkout makes the large file available in the git repository? Thanks, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re: [Oberon] Git usage for A2.
by Michael Schierl 22 Jun '23

22 Jun '23

Hello, Am 22.06.2023 um 05:50 schrieb peter(a)easthope.ca: > Seems plausible. =8~) > > Now how is Linux64.zip retrieved? Try this to download the latest revision of Linux64.zip into your .git directory: git lfs fetch -I Linux64.zip assuming you have set your default remote. If you did not, you can do something like git lfs fetch -I Linux64.zip origin main In case you don't only want the latest version, you can either give --recent or --all as additional parameter, to either get a few recent versions or all versions of that file. You can also omit the -I to get *all* lfs versioned files (but probably you don't want that). Once fetched, you can check it out (or more precisely all files you fetched since your last lfs checkout, that correspond to your currently checked out commit) into your working copy: git lfs checkout Hope this helps, Michael

1 0

Git usage for A2.
by peter＠easthope.ca 22 Jun '23

22 Jun '23

git-lfs installed in Debian 12 with no difficulty. =8~) The git-lfs manual gives this example. git lfs track "*.iso" So I did, "git lfs track Linux64.zip". Response was "Linux64.zip" already installed Seems OK. No error complaint. =8~) Next the example instruction is "git add .gitattributes". No response from executing it but the hidden file is there. $ ls -ld .gitattributes -rw-r--r-- 1 root root 279 Jun 21 20:24 .gitattributes Seems plausible. =8~) Now how is Linux64.zip retrieved? Thx, ... P. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Git usage for A2.
by peter＠easthope.ca 21 Jun '23

21 Jun '23

Hi, According to https://gitlab.inf.ethz.ch/felixf/oberon I've created a local copy of the git repository. For the executable, I must choose between two options. Install git-lfs or retrieve a needed zip file directly. Appears git-lfs is the more comprehensive way. Is there a reason not to work with git-lfs? Any tips about configuration and use? Thx, ... P. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0