The implementation of Git/SVN integration does not change the fundamental architecture of the PB IDE. In other words, it does not change the fact that source code is stored in PBLs and IDE still directly interacts with PBLs for saving the changes into objects and load source code when you open an object.

In other words, the Git/SVN integration is like an add-on to create a bridge to export source code from PBLs to commit to the repository and retrieve source code from the repository to import to PBLs. That is why it still relies on the PBLs to work. So in order for a user to be able to set everything up when they use the “Connect to Workspace” operation, the PBLs also need to be included in the repository.

However, if you really do not want PBLs to be included in the repository, you may try the following workaround:

1. When you first do the “Add to Source Control”, uncheck all the PBLs so they will not be committed to the repository. Note: Do not uncheck PBD files, because if you do not commit them, they will always show up every time you make a commit later. As PBDs are normally not updated frequently, it should not be a big problem to include them.
   
2. Push the repository to the server.
3. Connect to the workspace from another user. Note: You will see an error similar to the following. Just ignore and cancel it for now.
   
4. Copy all the PBLs from the original project on the first user’s machine and put them in the corresponding folder in the second user.
5. Do a Refresh to make sure any new changes to the objects are imported (this is only necessary when you connect to a workspace for the first time)
   
6. When you need to add a new PBL to the project, just share it with other developers so they can put it in their corresponding folder in their workspace.

As a tip:

What we do, with another source control, is to always have a separate folder as a backup for the pbls. That folder we DO include in source control, but not the pbl's that we work with which are in the library list.

Now and then we copy the work-pbls to that backup-folder and that backup-folder we then PUSH. (So they are not the pbls that you use in your library list).

This way, if you setup a new user, the user can download the pbl's from the backup folder, put them in whichever folder structure you need, and then connect to GIT to do a "refresh", "getlatest" or whatever is necessary with GIT to get started.

 In other words, not every change of an object causes the pbl to be updated with source control, only the backup version, maybe once a week or once a month.

If a newly connected user has fetched latest versions, he'd have to make sure he'd delete any objects in the pbl's marked with a +. Those will be reflecting objects that would have been removed in the time passed from the latest push of the backup folder.

HIH

If they pbl files were pushed by a user before the .gitignore file was set/uploaded, then you might have to do something like this from the commandline:

git rm --cached debug.log nbproject/

See:

https://stackoverflow.com/questions/11451535/gitignore-is-ignored-by-git

It happened to me with some files on GitLab and this solved the problem.

In all my experience I would say do not put your PBLs in source control. It just doesn't work!

Our developers workspaces & PBLs are copied to a network share when they log off. A new developer working on the project would copy the workspace & PBLs to their dev machine and then connect to source control. Do a get latest etc and you are away.

That's got to be the simplest and safest way for an source control system.

That's my 2p worth....

Here's an example of what I needed to do, using "mingw64". 

git rm --cached -r fileOrDirName

On the image you can see it took me several efforts to get it right :)

Hi,

I've been reading up on the use of Git:

first this one: https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/183-powerbuilder-2017-r2-new-feature-git-source-control-support

and then this one, which explains very clearly what to do and not to do:

https://community.appeon.com/index.php/articles-blogs/tips-tricks-techniques-articles/17-powerbuilder/227-tips-on-using-git-with-powerbuilder

I've pasted the most important stuff of this previous link at the end of my comment. (sorry for all the bold, I'm only trying to point out what is important in what follows):

This second link explains how the pbl upload works and indeed ... there is no need to separate the pbls from the source code. The advice I gave in previous answers is wrong, sorry for that, but that's how we work with other source control.

The trick is that when you first do an "add to source control" from the powerbuilder IDE, the pbls will be initially uploaded. After that initial upload, it should never upload the PBLs anymore when doing commit and push, only the exported *.sr? files will go to the server.

Do NOT do a "Clone", a new developer should "connect to the workspace" and that way he/she should get everything. "another user still needs to use PowerBuilder > Connect to Workspace to download and set up in his development environment. It doesn't work if you simply copy the entire workspace folder over to the other user's machine. "

A new developer who has connected for the first time, will get the 'old, initially uploaded' pbls, when the project was "added to source control" at the start. So the newly connected developer also has to do a REFRESH.

When you do a PUSH, the pbls don't go to the server (or at least they shouldn't ).

When you do a PULL, you should not get the pbls again, you should only get the exported files which then will be build into your local pbls.

The "Upload PBL, followed by a PUSH" option, should only be used if after creating a new pbl when after some time in the project, you have created or added a new pbl.

Is maybe one of your developers using this "Upload PBL" all the time?

You have probably read all of this before, but maybe you missed something since you said your English is not perfect.

Just my 2cts. on how I think it should work, if it doesn't then there's a bug. Good luck! Here's an excerpt of the second link I gave you:

---------------------------------------

After you have uploaded your workspace using PowerBuilder, another user still needs to use PowerBuilder > Connect to Workspace to download and set up in his development environment. It doesn't work if you simply copy the entire workspace folder over to the other user's machine. Nor will it work if you use a Git client to download the workspace. The PowerBuilder Git feature will only be activated for the other user after he uses Connect to Workspace to set up his workspace. 

Another thing is that as the associated data for the Git settings for a workspace is saved in the registry tied up to the workspace path, The PowerBuilder Git feature will be disabled if you move the workspace to another location.

#2 When to use the Refresh menu item

There are mainly two situations when you need to use the Refresh function. 

• The first time you do the Connect to Workspace to set up your local workspace. 
• After you directly modified the source code outside of the PowerBuilder IDE.

The reason behind this is that PowerBuilder IDE doesn't load the code directly from the source code files. It only displays the code saved in the PBLs. Ideally, PowerBuilder should be managing all the synchronization automatically. The reality is that PowerBuilder only pulls the source code in to PBLs when you do a Git Pull. On the other hand, it only exports an object to the source code folder when you save it in the IDE. Synchronization of anything changes happened in other manners have to be taken care of manually. 

So, as PBLs are only uploaded once during Add to Source Control. The later code changes are not reflected in the PBLs on the server. So the first time you download the code from the server, you need to do a manual Refresh.       

#3 When to use the Upload PBL menu item

Normally you don't need to use this feature. When you do the "Add to Source Control" and do the first Git Push for setting up the repository all the PBLs in your workspace will be uploaded to the server automatically. 

By default, PB will not commit or push the PBLs to the server thereafter; Only the *.sr object source files will be committed and uploaded in later operations. If there are any changes on the server in the *.sr files, they will be downloaded and imported to the PBLs when you do a Git Pull. So it kind like the PBLs are dynamically built when you do a Git Pull. But the dynamical building process requires the presence of an skeleton PBL, which is why the original PBLs were uploaded when you set up the repository. 

Now, there is one situation you do have to use Upload PBL. That is when you add a PBL to the workspace. This is so that your colleagues will be able to get the skeleton PBL when he pulls in your changes from the server. 

Note: Upload PBL doesn't literally upload the PBL. It only commit the PBL and you still need to do a Git Push to really upload it to the server. 

Hi Gimme,

Don't feel "endebted" as this is also for my own interest. For now, I don't have to use Git luckily, but maybe I can use it for personal projects or who knows what the future might bring, so it's good for me also to know how it works or fails.

You said: "We didn't do an 'add to source control' but we loaded the PBLs manually with 'Git add -A'.
I don't think that makes any difference."

To be honest, I'm not so sure. I think the best thing would be to make a small test project and do everything exactly as described, so no "git add -A". That's the only way you can be sure (or see what happens with the bug you've submitted).

I really hope this gets solved for you and anyone using Git.

kind regards