Changes

This will create a directory underneath which will then contain the complete package source.   

This will create a directory underneath which will then contain the complete package source.   

Note that git clone will not overwrite a previous directory containing an earlier (or the same) version  of the package. This is so that you do not inadvertently overwrite precious changes you might have made.  

Note that ''git clone'' will not overwrite a previous directory containing an earlier (or the same) version  of the package. This is so that you do not inadvertently overwrite precious changes you might have made.  

To check that all changes have been written to git, run ''git status'' in the directory and it will show you (in red) all files which are different from the ones on the gitea server.

To check that all changes have been written to git, run ''git status'' in the directory and it will show you (in red) all files which are different from the ones on the gitea server.

As described above you can pull down the repo for a specific package using the git clone command. Or you can use the gitea web interface to grab which ever file you want and edit it as required, even using the provided gitea editor. You may be able to configure your desktop editor to interact with the remote gitea/git.  

As described above you can pull down the repo for a specific package using the git clone command. Or you can use the gitea web interface to grab which ever file you want and edit it as required, even using the provided gitea editor. You may be able to configure your desktop editor to interact with the remote gitea/git.  

My preferred modus operandi is to use a running (and fully updated) SME11 VM to which I have full file access from my desktop using the sshfs package.  This allows me to make any changes using my preferred source code editor (geany in my case) and fully test any changes in place, and then copy the changed files back to the build system ready for local rpm build and test before updating to gitea/git and then doing a koji build.

My preferred modus operandi is to use a running (and fully updated) SME11 VM to which I have full file access from my desktop using the sshfs package.  This allows me to make any changes using my preferred source code editor (geany in my case) and fully test any changes in place, and then copy the changed files back to the build system ready for local rpm build and test before updating to gitea/git and then doing a koji build. YMMV.

 

YMMV.

=Local rpm build=

=Local rpm build=

=Saving the Source code to Gitea=

=Saving the Source code to Gitea=

''git status'' is very useful to see what changes have been made as compared to the version in the remote gitea/git server. The changed files are flagged in red before that have been locally staged and green afterwards.

''git status'' is very useful to see what changes have been made as compared to the version in the remote gitea/git server. The changed files are flagged in red before they have been locally staged and green afterwards.

''git pull'' can be used to bring any existing clone directory up to the latest on the server. However if the local version has been changed since the original clone and not pushed back and therefore deviates from the remote version which has been updated itself then an error message is seen and the pull will fail. Unless you have good reason to retain your local changes, the easiest way is to delete the local directory and re-clone.   

''git pull'' can be used to bring any existing clone directory up to the latest on the server. However if the local version has been changed since the original clone and not pushed back and therefore deviates from the remote version then an error message is seen and the pull will fail. Unless you have good reason to retain your local changes, the easiest way is to delete the local directory and re-clone.   

''git all --all'' will add all the local changes to the list to be pushed back to the repo. You can also use ''git add'' to just add one file. Also note that the contents of ''.gitignore''  can be edited to cause file types or names to be ignored by the --all parameter.

''git all --all'' will add all the local changes to the list to be pushed back to the repo. You can also use ''git add'' to just add one file. Also note that the contents of ''.gitignore''  can be edited to cause file types or names to be ignored by the --all parameter.

=Tagging and starting a build=

=Tagging and starting a build=