Pull from remote branch not working

[Kosock]

I'm new to the server side git-source-control:
We managed to set everything up with a remote repository (own company GITLab) with different branches for our development and test server environment.
On the development server we committed some new classes, pushed them to remote and then merged them to the test branch using GITLab. Looks fine on the GITLab side.
Unfortunately when we execute the “pull changes from remote branch” on our test server (same Namespace) there are no errors:

Pulling from branch: test
Fetch done
Files that will be modified by git pull: 
    None
Already up to date. Git Pull will not be executed.

But we would expect the new files pulled.
Any hints where to look if we set up something wrong? Thanks for the help.

[isc-tleavitt]

@Kosock did you set up an SSH key pair on the test server? See https://docs.gitlab.com/ee/user/project/deploy_keys/

[Kosock]

That was a good hint, I created that key pair but I just had a typo in the path to the key file in the setup. Now it did recognise changes.

But I we get a SourceControl Error:
We get now with just Classes added and .gitignore addes the following Error:

Here the output:

Pulling from branch: test
Fetch done
Files that will be modified by git pull: 
    A        .gitignore
    A        cls/HS/Local/GitTestKlasse.cls
    M    HS.Local.Namespaces.DICOM.Testklasse2.CLS    cls/HS/Local/Namespaces/DICOM/Testklasse2.cls
Updating e06b801..39d7b73
Fast-forward
 .gitignore                                    | 1 +
 cls/HS/Local/GitTestKlasse.cls                | 6 ++++++
 cls/HS/Local/Namespaces/DICOM/Testklasse2.cls | 3 +++
 3 files changed, 10 insertions(+)
 create mode 100644 .gitignore
 create mode 100755 cls/HS/Local/GitTestKlasse.cls

Furthermore I have still a warning

Can it be safely ignored or should we look into it since IRIS is running as irisusr, but the iris.service configuration starts it in root's context and environment.

Thanks for further help!

[isc-tleavitt]

The <SUBSCRIPT> error is interesting/unexpected. If you could reproduce it, would appreciate if you could file an issue.

#259 indicates need for a workaround for the "permission denied" errors - planning to tackle that soon.

[Kosock]

Ok I'll will try again with a cleaner repository and if still persistent I file an issue.

Another question: Can I delete my current local git repository and just start with a clean one or do a fresh pull from the current we use?
Will that sync everything up again or may that lead to conflicts since the information of the classes egg. that are added to source control are stored somewhere else then in .git of the repostitory?

[Kosock]

Well since we tested quite heedlessly :) an messed up the branch.

I wanted to delete the local git repository on the server and then clone it from a new blank branch from the remote repository again via git commands while connected to the server via terminal. Is there a problem doing so or do I do need to reset something in addition on IRIS / Intersystem “based” files or Database entries? (sorry if I’m not quite clear since English is not my mother tongue)

I noticed that the source control does not recognize that there not any changes triggered when I do the pull via Studio and everything is up to date in the local repository but not in IRIS (like added classes).
So I have a question about how the source control works to better understand where do you save the information which classes are already added to source control or is it just via the information you have in the local git repository and using the commands just makes sure to copy and get files from the local git repository?

Thanks for the patience and help!

[isc-tleavitt]

@Kosock ah - that makes more sense. There are import/export all capabilities that might help if there are changes not picked up via an incremental diff / git pull. Ultimately we would like this to be more automatic (#153), but there are some ways in which this is tricky/dangerous (particularly around deletes) and it needs a fuller design.

It's fine to just delete the local repo (really want to get the whole folder - .git and all the files), then re-clone. The trick with cloning is getting file permissions right, both for the repo itself and for the files in it; recent versions of Git get unhappy when you're trying to work with a repo owned by a different user (and reasonably so, from a security perspective). If you want to run the git clone yourself, just run as irisusr at the OS level before doing so; alternatively, you can run the Configure() method which (as of 2.2.0) will offer to clone/init if the local repo is not initialized yet. This clone/init will get the filesystem ownership right even if you're running at yourself at the OS level.

[Kosock]

@isc-tleavitt that helped thx. I do still get the Warning:

Can we ignore it or do you have a hint how to fix that?

Other then that with the a clean brunches it works now. I guess the error above was cased since we manually added files to the Repository "root" level using the GITLab WebUI and not either Studio or Visual Code. Which in our normal workflow is not allowed anyway.

[Kosock]

@isc-tleavitt I'm not sure if that is an issue, but what do you use as GIT Web UI? Is that component updated with updates to the source-control or separately? We noticed that if you switch between stashed changes the content on the right side doesn't update and stays the same from the topmost stash. It works fine while viewing the commits in a branch but not for the stash - or is that correct since it only should display the topmost stashed?

Do you have any idas on the "root" permission problem? Thx again for you help!

[isc-tleavitt]

@Kosock feel free to file a GitHub issue re: the diffs for stashed changes.

Re: the root permission problem, as I said, the fix will be #259 (if not one of the workarounds discussed there). Unfortunately the way it needs to be implemented will rely on some newer IRIS features that are only in some of the newest maintenance releases. (2022.1.3 and 2023.1.0, I believe.)