|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819216 is a reply to message #1819180] |
Fri, 10 January 2020 07:12   |
Eclipse User |
|
|
|
I'm hesitant to answer this because I expect you'll use that knowledge to take this choice away from the user and impose on them your personal choice.
In general look closely at your user.setup (Navigate -> Open Setup -> User) to see where and how such things are stored. And please keep in mind that the design intent is to give users this choice, not to force your personal choice on all users. Sharing the same clone across multiple workspaces that can be open at the same time is far less than ideal. It's clearly not possible to work on different branches in different workspaces using this approach. But I've explained that to you already...
|
|
|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819219 is a reply to message #1819216] |
Fri, 10 January 2020 07:28   |
Eclipse User |
|
|
|
> I'm hesitant to answer this because I expect you'll use that knowledge to take this choice away from the user and impose on them your personal choice.
Looks like you hesitant to impose your personal preference. ;-)
> In general look closely at your user.setup (Navigate -> Open Setup -> User)
Thanks, I try to find this. Multiple clones of the same repo to work on different branches are nothing I have ever heard anyone suggest from the Git community. Such a setup still feels like a memory from the good old cvs / svs days to me.
If you have a pointer to such a recommendation coming from a Git related source (e.g., Github, Bitbucket) etc., please let me know.
For reference: I migrated multiple clients from cvs/svn to Git, contributed patches to the Git command line and EGit tooling, wrote a book on Git command line tools and worked for the Github company in the past.
If multiple parallel checkouts are needed: the Git command line supports multiple working trees for the same repo to cover you scenario. See https://dev.to/oliverjumpertz/using-multiple-working-trees-in-git-122d
|
|
|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819222 is a reply to message #1819219] |
Fri, 10 January 2020 08:21   |
Eclipse User |
|
|
|
No Lars, that is simply an unfair and baseless comment. I provide choices and I've explained in detail previously the reasons for those choices. Given this is about providing choice, at best you can argue that impose what I think is best by virtue of which choice comes first (as the default).
But as I've said in Bugzilla, most of what I say seems to fall on deaf ears. It seems somehow pointless to repeat myself. Perhaps each of us (me included) is deaf to information that does not conform to our expectations or our mental model of the world as it is or should be...
If you do have pointers that suggest it's best (or highly recommended) to only ever have one clone on disk and that all work should take place in this single local clone, please let me know. All I know from my own past experience is that I had different development environments with different target platforms and different IDE versions to work on different branches of the same remote Git repository and both installations were open at the same time. Fortunately we don't need to do maintenance stream support anymore. But surely this was the case for the platform as well, where the API baselines and the target platform for the master branch and the maintenance branch were different. So I don't see how having a single clone is ideal (or even workable) for this use case. Of course I'm not familiar with multiple working trees nor how to configure such things (with EGit), so perhaps there was/is some great way to do that which would save some disk space and some cloning time...
In the end, regardless of the layout choice/style, whether there actually will be multiple clones on disk purely depends on whether you've created multiple different installations using that same project setup.
|
|
|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819223 is a reply to message #1819222] |
Fri, 10 January 2020 08:36   |
Eclipse User |
|
|
|
> Perhaps each of us (me included) is deaf to information that does not conform to our expectations or our mental model of the world as it is or should be...
I hope I never questions your personal way of working. If you like cloning multiple times to support certain scenarios that is fine to me. I never needed that (Git branch switching works fine for me) and the original Oomph tooling did (before you added it) not support that way of working which is AFAIK the norm if standard Git tooling is used.
In general I dislike if a tool force me to use a different approach that the tooling which is used under the hood. If I clone via Git command line or EGit the resulting directory does not include the branch name, hence any tooling which wraps the Git clone operation should IMHO offer the same approach.
Saying that this requirement is similar to "fall on deaf ears" show a strong personal preferencem for the personal way of working. Supporting and accepting different way of working than the personal one is important IMHO for tooling be get accepted.
So in my personal summary: It is IMHO great that Oomph now allows to clone similar to the standard Git and EGit tooling. Not to great is that the option to pre-configure this is not documented.
|
|
|
|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819229 is a reply to message #1819224] |
Fri, 10 January 2020 09:20   |
Eclipse User |
|
|
|
As I mentioned in this Bugzilla in response to your request, there is a choice for the layout style that you asked for:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536533#c41
So the tool gives many choices, including the one you prefer. That choice is remembered and reused for your personal use from then on.
Using multiple clones one can of course always pull to pick up remote changes. So when working on a master stream and a maintenance stream,(in separate IDEs) I would work first on the master stream and commit those changes. Then I would decide if I needed/wanted those in the maintenance stream as well, I would pull in that IDE and cherry pick what I wanted. Then I generally needed to amend what I cherry picked commit because the version number incrementing scheme for a master stream is different from the one for a maintenance stream...
|
|
|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819230 is a reply to message #1819229] |
Fri, 10 January 2020 09:28   |
Eclipse User |
|
|
|
> As I mentioned in this Bugzilla in response to your request, there is a choice for the layout style
Yes, thank you for that. That is excactly what I meant with: "It is IMHO great that Oomph now allows to clone similar to the standard Git and EGit tooling" statement.
> Then I would decide if I needed/wanted those in the maintenance stream as well, I would pull in that IDE and cherry pick what I wanted.
Your process to use a server to bring branches together sounds not very gitty to me . ;-) Also this way of working would not allow to use the popular Gitflow branching model (https://blog.axosoft.com/gitflow/)
But the power of Git is that its supports different ways of working and if this process works fine for you, than that is good and OK. Let me repeat: I never intended to question your way of working.
|
|
|
|
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819240 is a reply to message #1819234] |
Fri, 10 January 2020 11:37   |
Eclipse User |
|
|
|
I see that Attribute Rules are only possible in the user.setup; it corresponds to org.eclipse.oomph.setup.User.getAttributeRules() so indeed only the user can configure/choose these.
The git.container.root ought to work, but I don't know where your testing failures might come from. Perhaps from having both a value and a default value on the variable? Perhaps from not using the project setup you think you are using? Perhaps because of the scope in which this variable is declared (it's induced from Git.ecore), it's simply not working to override it no matter what you do. In any case, it should not be necessary to override it because of course only the user knows what's a valid location on their machine and as requested the changes for https://bugs.eclipse.org/bugs/show_bug.cgi?id=559008 are already committed.
|
|
|
|
Powered by
FUDForum. Page generated in 0.04123 seconds