 I think we'll get delayed for the meeting. That's okay. I'll ask you separately. So I'll share my screen now. So I think the first thing we can discuss is related to get to choose it. Or yeah, we should discuss the progress with what with the get to choose it. So, so we had an interesting conversation in the last meeting about about features that we provide to users which are not supported by JGit how to use how to get that information from JGit and how to how to get that information to get to a chooser so that it can recommend the right implementation. So I'll just explain the problem, the problem here so that everyone's on the same page. So currently the user while choosing an additional behavior would not know if that feature is supported by JGit or not. So the way it is designed is that after for an example if a user chooses get LFS pull after that after that operation is run, the user will know that that operation is not supported through an exception that is thrown by JGit. So now the challenge here is that we need to use this information. We need to get this information for the get to choose it. Now the biggest problem here is that get to choose it is working before creating before the creation of the client. And JGit or CLI get would be called when the client is created and we are using the operations. That is how it works. So if we need that information for an example if we need to know is the user get LFS pull supported or not. If we need to know that before the creation of client we had two options. So I had a discussion with Fran as well in the Gitter chat. So what I was saying there was that the problem is that JGit the way so that the checkout or any operation which is implemented by JGit is implemented through certain commands like checkout command or these are interfaces which provide the capabilities of different features provided in a checkout. So when it implements it it does not create any kind of a method to access the variables the field values like LFS pull or so I need the field values to know what the user has chosen. And then I can if they are not null I can say okay JGit doesn't support that and we can throw an exception or do whatever we want to. We haven't hard coded anywhere that okay if we see get LFS pull somewhere we say false or we say true. It's always the way it is checked is that we we look for a non-null value if we see a non-null value we throw an exception. So there was no way for us to get that information out of JGit with the current implementation. And so one of the ways I could do that was to change the the way checkout command is being implemented or clone command is being implemented within JGit API implementation. But that seemed like so for me what was easier and cleaner was to create a separate command which would not be dependent on any implementation because it because if the command depends on the implementation which is JGit or get. I would first have to create a client and then I can get that information but I need the information before the creation of the client to do so what I did was that I created a new command which is not an interface. Usually the all of the commands for the clone commands of the checkout or the push commands they are implementations of a general interface called the get command. My command is not being implemented by any interface. It's is not it's not coming from any interface. It's it's a separate class which so what it does is it it contains all the features I've aggregated all the I've collected all the features which are not supported by JGit. We can instantiate it before calling any client and then we can use the decoration. We usually do off commands from extensions. So for any command if we want to add the information which a user is provided to the command we use decoration tools. I've used something similar to decorate or let's say determine what other options user has chosen and and then the unsupported command contains all of that information and it can determine if JGit is to be used or not. It just provides a Boolean that if JGit can be used or it cannot be used and then that Boolean can be taken by the get tool chooser to modify its recommendation. In fact, not modify its recommendation. I've I've changed the constructor now earlier the constructor only needed a get SCM source object or repo URL to instantiate. Now it would need a Boolean flag as well which would tell it which would be the which would be the information that it can be used JGit or not. So if if there are certain features within the plugin which are not supported by JGit and they are being used by the user, we would not recommend JGit. Even if it's optimal according to the repository size. So I've raised two PRs for that one in Git plugin and one in Git client plugin mark I think you've seen the client plugin you thank you for creating those tests. And for the Git plugin one I think I haven't created the test but I have created a place where I think I can show that part of code where we are using get tool chooser and how we are going to adjust the flow of how we we are determining every how are we taking the decisions just a second. This is the comment which would so so in the Git SCM class we have a class we have a method called create client. So it is the place where we create the Git client for any operation we want to provide. So so what I'm doing here is here is the unsupported command which is being instantiated before any creation of client. I am using a new decoration method it is it is only implemented by those extensions which which wish to convey the information that hey I am not being used by I cannot support JGit. And so I am implementing this method so so these extensions what they would do is they would add that information to this instance this object instantiated unsupported command. And once we have that what is going to happen is I create the estimator here. I am getting the URL and then here when I'm calling the get instantiating the get tool chooser it is going to take the URL and also it is going to take a decision taken by the unsupported command which is to determine the support for JGit. How it takes this decision is basically we we have a flag if we see that we have a non-null value for any of the feature which is not supported by JGit. We would just say cannot use we would return a false for JGit and the get tool then can make a decision can make the right decision of not recommending JGit if if any feature is not supported by JGit and this way we would not break any existing use cases. So if a user is expecting that for example if a user has chosen get LFS pull and if we were not implementing any kind of functionality like this and let's say the repository sizes small repository. What would happen is that for him earlier get LFS pull was working but now it would not because we've chosen JGit for him. Since now we're taking the decision additional decision of checking if the feature is compatible or not we would not break as far as I've thought about it we would not break any existing use cases with the introduction of this decision. So and then ultimately when we have the estimate the get tool chooser we would just get the get tool and then we can feed it to the to the get this is the method which creates the get client and then we get the client. So this is how I am. I believe this is how we would. We would use get tool chooser anywhere within the get plugin. These would be these steps would be would have to be taken to ensure that we do not break any existing use case and side by side provide the optimal implementation we wish to. So we have the PRs for it the code is written I of course I need to add the tests I don't have the test now we would have. I've seen that we have at least 10 features which are not supported by JGit. So I guess I would need a lot of use test cases to cover all of this cases and how in those scenarios, we're not recommending what we should not. So that's a task for me. Apart from that I the second thing which which is important for the get to chooser is the extensions, the extensions, which will implement the extension point we have provided which would give us the information of the repository size through rest So with the github so currently how I implement before the demo I implemented an extension in the github branch source plugin. So the way I implemented it was that I I sent the github repository URL to the plugin and then I asked the plugin to give me the size of the repository and so I did not involve any credentials user credentials throughout this process. So this request rest API request was going unauthenticated as an unauthenticated user. So this was this would currently work only for a public repository not for a private private repository. That is the first I would say a feature which is missing that we were not supporting private repository estimation. The second thing is that I was talking to Liam, Liam is the repository owner of get a broad source plugin. So he was saying that providing the github URL is not enough because there are enterprise servers which would have entirely different custom customized names which would not even contain github. So we need to think about a different way to provide them a unique. I would say maybe combination of the repository URL and user ID or user name. Wait, wait, wait a second. Okay, I'm not understanding that one at all. Because if I'm corporate if I'm running github enterprise. It's got URL somewhere and the repository URL absolutely encodes the full information it could be my my server dot example dot com slash mark you ate slash some secret repository dot get. But but that URL absolutely does identify that repository. Can you help me understand more what Liam was trying to tell us because the HTTPS URL to a repository is absolutely unambiguous that that is a repository maybe inside a corporation it may not have the word github anywhere, but it is absolutely unambiguous. So, so, so what so I implemented how I implemented that validation. Okay, is this a github URL or not I just, I just put a check that if the string contains the word github. Okay, great great so Liam's right then yeah because the github enterprise installation at CA technologies where I worked, I don't think it had the name github anywhere in it. So yeah, okay, got it. That is what he was saying that we I need to change the way I'm validating. Yeah, that's okay that's fine it's not that it's not that he was saying there's more information needed it's just that that the URL may in fact not have the word github anywhere in it. So, what should we should be validate the URL. If you have the URL in that logic of validating it should I send a request to it and then check if it's. I just pass it I pass it to the, let the branch source decide, I wouldn't put any extra validation on a personally I would just let the branch source decide what it does with it. I don't know if it's the github branch source plug or like the github branch source plugin itself would know that it's a good branch source right so good. I was at least responsible to decide. Yeah, because the other tricky bit here is that you need an API token instead of like an SSH credential, and some people will try and favor SSH credentials you may not have. You can configure that without an API token. And I'll think you can actually. Anyways, need to look into that. And those branch source plugins know all about those complexities right and they worry about those complexities Oh, I need to make an arrest request but all I have is an SSH token how do I do that and the answer is you don't you have to get another token so. Go ahead we shop sorry so forgive the forgive the side trip I was just concerned that there was something I hadn't understood. Thank you. I, I think so I would need to, because I would need to implement the extensions in any of the branch source plugin so I think I would look more into how I can do it, look more into the code and implement them. Okay, so, so currently what I was thinking was to first simply for consolidate the implementation with GitHub and Merget, if it's available with them then in GitLab, then we can maybe proceed to other plugins as well. Now, I had one question with the, with the, the tool chooser, which mark you commented about it about thing that we can have the cash if the if we have a multi branch project and it has a cash gate repository directory. A pipeline for a project which is implemented a separate project which is implementing a checkout step can also access that cash repository. Okay, and how would that happen. The master, the Jenkins the Jenkins master the Jenkins, probably eventually called controller, the Jenkins controller has a caches directory, and it doesn't care what context you're asking for asking for information about that cash directory. So if the URL, the repository URL is known to the Jenkins cache, it can be its size can be answered, whether or not the job asking the question is multi branch or freestyle or, or multi config or simple pipeline. Okay. So, as far as I know, we need this functionality of locking a cache and then examining it is provided within the SCM source class. It's not provided within the Git SCM class. Right. I think the cash implementation is actually in the Git plugin. If you, if you look at. Okay. Okay, I'll. I haven't, you know, I think I haven't looked at that in detail I would look more about that. Well, I think you're actually already using it. This we'd had a conversation in one of your poll requests about making sure that we did not bother to acquire a lock on that cash, because all we're doing is asking about the size of the thing. And you had you had implemented in your poll request that it was opening the cash but not require not acquiring a lock on it. I'm using it when I have a Git SCM source object. Okay. I'm not, that's how I'm using it. I'm sorry, I'm not, I'm not following that. That still seems like a perfectly safe thing to do. What did I miss help me understand. So what I'm saying is that if I am, if I'm trying to instantiate Git to choose a within the Git SCM class, would I have the Git SCM source object there available. I know because that's a different project right as far as I understand. Get SCM source is a class which is used when we are trying to scan multiple branches. It's a separate multi branch project. And when I'm trying to use, let's say a separate pipeline project where I'm just checking out the branch, a single branch. I am using the Git SCM class. And what I'm trying to say is that would I have the access to that object. How would I access the cash then. I think just by asking for asking to to see if there is a cash if a cash exists for this URL for this repository URL and if it does read it. Okay, so I let me just open the get to choose it for what I want to say I'll communicate better with it. So if I want to access the, okay, so Mark, if you can see here when I so I have a function which is which uses the cash and determines if the size of the repository using the cash. So I expect a key SCM source object, and I use that object to get the cash entry and then I use a static method provided by abstract get SCM source to get the gas directory. So I think that I can I oh I can use this to. I can use this in Git SCM class to get the cash directory. I think so isn't isn't the key there the cash entry key. Actually the repository URL. I don't, I'm not sure. My hope was, my hope was that that that cash entry value is the repository URL. If I'm wrong on that, then we've got to go look what they what the index is into the cash. But I would be I was expecting it was either the repository URL or some variant of the repository URL and as such, you can just ask the thing through that static method get cashier. Do you have this if you don't, I can't estimate with it if you do. I'll estimate with it. I understand the point now I was not aware that the cash entry is actually the repository URL. Okay, I just implemented it. The same. Okay, I'll, I'll, I'll, I'll first see what the cash entry is and then if it's the repository URL then we don't need a source object to to get the cash. Okay. So the first thing this is it for the get to choose it. The things we have to do. So now the question is that what the planning for phase three what, what should we do apart from get to choose it and the release we have to do for the fix we did redundant fetch. The first thing I thought was to implement get blown maybe but then the reason to implement it one of the reasons to implement it would be that it's it has a better performance and get fetched. And I've shared a document indicator channel where I've compared I wrote a lot of benchmarks I wrote three benchmarks different different benchmarks for to compare their performances I only have the result for one here. All of the three benchmarks so the first benchmark we will see this is a test for a single repository, which is around 300 MB. And what we see across different platforms is almost similar performance there's a second difference but there's an error rate of one second as well. So not be too sure even if this is a one second difference there. Then I ran another benchmark with where I vary the size of the repositories to see with different sizes how would get blown versus get fetch work and I did not see any difference. In that case, I also create experimented with running the same benchmark with on sent to a seven with get one pointed. And there as well I could not see any performance difference noticeable performance difference it was around half a second, the difference between get blown and get fetched. Now this can mean two things the first that there's no difference the second that my benchmarks might be wrong. And why I would say so is that the reason why I'm how I'm implementing get blown. I'm using the launcher, which is provided, which is the implementation for CLI get to perform a to launch a gate operations I'm using it to call get blown. I hope that I'm that's, that's, that's the way to do it. Okay, so that's the way to do it then I'm in the results say that there's not much of a difference. So then would we want to implement get blown is there a use is there a benefit to implement that feature that operation. Instead of getting it plus get fetch. So that's for me there is for me there is not given that give I wouldn't much rather invest your time, providing get tool, providing the branch source implementations to giddy to get hub to get lab to bit bucket to to to leap to to to the other branch source providers. I think it's much more valuable than spending time on this on adding get clone as an alternate implementation of a subset of the capabilities that the plugin already offers the, the get clone can't do all the things that in it plus fetch can do. And therefore, when we if we were to implement clone it would be purely a subset and a subset that the user then has to be very intelligent and decide do I want to use in it plus fetch or do I use clone and if I use clone. Do I get the benefit, you know, it's an awful lot of analysis that I don't think we really want the users do you think about. Okay, I'm open to others disputing that's that I don't, I'm, I'm certainly not the sole mentor here but I, my sense was this is not enough of a difference to justify your investment in it. Okay, so the other mentors have anything to say. Definitely. For you say it will be too difficult to make that analysis and go with any particular decision. Okay. I would, I would beg you to include this in a in the summary report because I will refer to it frequently when people complain to me that they want clone implemented it's like no I'm sorry we really did a rigorous benchmark and the benchmark says this. It's not just me saying at the benchmark says this there is not enough difference to justify our energy to write a whole new implementation. Okay, I can I'll even add the other expert benchmark cited I'll add all of those results to have a more comprehensive report it then I can add that. So, so if you're not doing that so what my question is that do we want to implement and consolidate what we have there and then that is what we deliver for this project or do we want to look for something else as well. So, for this phase, would we so would we want to do we want to explore another area of performance improvement. I frankly, I'm not sure where I could look for that. As much as I've seen the get plug in and depends once I've done I don't know where I can find where is where is it. Is there any area where I could find a sizable difference between performance or something where we could work to improve it. The thing I had in my mind was, was, was this PR I've seen, which I'm not sure if we would want to look into it. I lost it, I think. I think the number is 500. I went into I think I've written it into. Okay. So, this is something the mentors can decide if, if we would want to work. This idea using the game file system cash is a different for the presentation. You are, you are a brave, brave man that is very impressive. This was an entire GSOC GSOC project proposal to consider taking this thing on. Yes, anything you can do to help this move forward would be great. But for me, there's much more value in first assuring that we get the branch source plugins, all the way to done, so that they're contributing an answer to the to the question to the tool question right for me those. And I expect that's already going to be challenging for you because the giddy, the giddy plugin, the BitBucket plugin, the GitLab plugin, the GitHub branch source plugin. Each of those will have its own different and unique things that you're going to discover. And I don't even know what the to leap or to the plug plugin does, but it is also a branch source. Okay, okay, so, so, so then what we can. So the deliverable is for us then the get to choose it with the extension of the support we are promising with the plugins we have. I think that should be the first priority for us because we want to when we release that feature it should actually work as we promised it to. If, so if we're able to do that within a certain time period and we still have some number of days where we could work on something else, would we think about this or should we focus on first focus on prioritizing the release of get to choose around the future, the extension for support and everything. Okay, so as of my preference, maybe I should be quiet friend you want to give your preference first I others others are welcome to chime in here that's, I tend to be opinionated and loud, and I don't want to overwhelm others with my opinionated loudness. I think that you're right reopening this box, I would just try to. Yes, I would try, I would try to a to finish all the all the effort with the process, but as I told you, I think that's going to make sure that you kind of can keep focused and finish that off and then you know if there is extra time that maybe we talked about like what else. Okay, okay, I understand and I love. Okay, that's how we move forward. So, I think we have finished the time I just have one question, and that's question that that question is related to jay get. So, Mark, and I wanted to ask, when does a user do people even use jay get my reason I'm asking the motivation behind is that we are providing a feature which this get to choose or which would would work well if a user is using jay get for a large size repository. Then is the that is the scenario where any user would see a noticeable difference in performance after implementing this after adding this feature to the plugin. So, do we even have those cases where people are using jay get for less not just say the size of the repository maybe that might not be something we can know but why do people use jay get one one one way I know is one reason is that for places where get is not installed jay get can be used. But then I don't understand why can we not why can we not have yet in any in any environment or why would we use jay get. So, so, I'll give you a very specific example. CI that Jenkins.io builds the Jenkins website as one of its tasks. It has info slash Jenkins.io and in that things output it's cloning a 60 megabyte repository using jay get. And that 60 megabyte repository keeps growing. By now it may actually be more like 70 or 80 megabytes because people keep adding pictures to it. Yes. And so, as, as we may reach the break point the point where the tipping point where command line get would be much better for that repository than jay get. We may have already reached that point. The reason that the original implementer of that thing did not install command line get is he I think was fundamentally lazy and didn't want to. He thought I don't want one more tool on things that's not install command line get. And the choice to not install command line get turned out that it broke all sorts of other testing, because there are many different components which assume command line get is available. And therefore we have command line get, we also are still using jay get. So, so I have an example now we could we can call it contrived because I don't we don't have hard data for how many installations have enabled jay get at least I don't I'm not aware of a way to get that kind of hard data. But but it's a valid point that if they don't have jay get enabled, we probably can't refer can't suggest jay get to them. Or if they don't have CLI get installed we can't choose CLI get. Yes, I was I was just wondering how it would affect how this feature would affect the users when they're releasing this and and how much of a practical usage this feature would have. But, okay, I think I, that's okay so. I am going to work on the test the first would be now since I think the PR for the get to choose it is complete now in terms of the features it wants to provide and the decision it needs to take that is complete now it was missing the jay get compatibility issue and that is also I've raised a PR for that. So now I can move on to consolidating the support for extensions. I have already raised a request for get a brand source I would first I would try to merge get that merged and then I would, or I would parallely work on get lab and take another plugin as well. So I'll try to. That is my first task, and the second would be to add test cases to more test cases to this pull request and the second one I've raised the unsupport command feature. And so, so is your sense that unsupported command has shown well enough for you it's working the way you're expected we could safely merge it to get client plugin so that you could have a readily usable bill that has get client plug it has has the capability in it. So, I think locally it doesn't, doesn't matter to me because I would have the snapshot jar in my m2. So, so I would say for the unsupport command unsupported command, I think it doesn't, it doesn't have anything which would require intensive interactive in the get client plugin. But again, it's, it's, it's a new command is it should it be a command should it be something else should it be shifted to the get plugin, not be kept within the get client plugin. My point is that if you people could review it and, and so I'm, I'm what I'm confident about is that the feature is providing what I need it's providing the information I need. But other than that, is it consistent with how we develop other classes and get plugin and should this week, this be the way it should be developed or I just want the mentors to review it that request and I for my personal development, I would have the snapshot. I actually also try. Yes, yes, Mark. You answered it perfectly it's not blocking you to not have this PR merged. That's that is great. Okay, so that that gives us the flexibility to review it to think deeply about it to compare it in context. Perfect. That's all I needed. Okay, yes. So I can, I would have a snapshot jar for the client and then even if I have I implement the extensions on the brand source plugins I would have their snapshot to positive jar than my M2 so I don't think I would be blocked by any pull request status. Great. Yes. So I think that is it then for this meeting. Anything else anyone wants to discuss. Are you okay with the things that have have come come out in this meeting I I know saying that we're not doing get cloned probably is a hard one because hey that was that's a major chunk of implementation. Are you okay with with that approach. Yes, I think for me as well if for me the only reason to to recommend new features is that I need I get to code more and I get to learn more but then what I have what I think I should remember is that we have to think about usability. That's the most important thing if if if I just think about writing more code and not think about if that thing is even will be used by the users or will be used in any place in the gift plugin then I don't think it makes sense. So, so I think we've we've had a logical discussion about what we can do in. What's the first thing we should do, because if you're promising a new, a new feature which improves performance certain cases at least it should do that. First, and then if we have time then I can look into we can discuss and if we have the time we can look into more challenges we could solve. Yes. And my only issue was that have I done enough for performance improvement within the get plugin. So that's that's what I was trying to explore and so, and I think that was why I'm asking these questions. Yes. Great. So, let's proceed forward then. Yeah, I think, I think we've got lots and lots of work yet remaining I'm a little worried that we may not get to release by end of end of the time period even so so there's there are so many things, so many parts and pieces that just fire release we will certainly release get client will need to reach get plugin. We probably need to release GitHub branch source and Bitbucket branch source and giddy and get lab and. Yes. I understand your concern mark and, and I think we should move forward in full steam, developing them first and consolidating their releases. Yes, that's that's that's a great plan. Great. Thank you. I'll post the I'll post the recording. Thank.