Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » Predefining the Git clone location rule and Root Git-container folder
Predefining the Git clone location rule and Root Git-container folder [message #1819180] Thu, 09 January 2020 15:11 Go to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

Hi,

I would like to pre-select the Git clone location rule and Root Git-container folder in my Dartboard setup file.

index.php/fa/37120/0/

I guess that is as simple as knowing the right key for "InducedChoices" . But right-mouse click does not suggest any value.

I looked at https://help.eclipse.org/2019-12/index.jsp?topic=%2Forg.eclipse.oomph.setup.doc%2Fjavadoc%2Forg%2Feclipse%2Foomph%2Fsetup%2Fgit%2FGitCloneTask.html but didn't find a description for that.

Please advice.

Thanks, Lars
  • Attachment: oomph.png
    (Size: 198.96KB, Downloaded 796 times)
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
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...


Ed Merks
Professional Support: https://www.macromodeling.com/
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 Go to previous messageGo to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

> 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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
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.


Ed Merks
Professional Support: https://www.macromodeling.com/
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 Go to previous messageGo to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

> 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 #1819224 is a reply to message #1819223] Fri, 10 January 2020 08:45 Go to previous messageGo to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

Just out of curiosity to better understand your "one clone for every branch I need to work on" way of working: How to you cherry-pick, rebase and merge between branches?

[Updated on: Fri, 10 January 2020 08:58]

Report message to a moderator

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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
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...


Ed Merks
Professional Support: https://www.macromodeling.com/
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 Go to previous messageGo to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

> 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 #1819234 is a reply to message #1819230] Fri, 10 January 2020 10:36 Go to previous messageGo to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

> In general look closely at your user.setup (Navigate -> Open Setup -> User) to see where and how such things are stored.

If I set the git.container.root this is currently ignore by the tooling. I tested this like this:

1.) Deleted Oomph configuration in the .eclipse folder via rm -rf org.eclipse.oomph.* to avoid previous choises to interfere
2.) Added git.container.root to both the global entry and the Git entry with the same content as I do not know if a global one will be picked up by the Git task, I guess yes but as it did not work, I tried adding it also to the Git one

index.php/fa/37132/0/

3.) Restarted the installer to get rid of any caching
4.) DnD the Dartboard.setup onto the installer
5.) Check the values on the installer screen after switching the Git clone location rule.

index.php/fa/37130/0/

Anything wrong with my testing?

Maybe Git clone location rule need to be set as well to consider git.container.root?

I see a node in "user.setup" containing an attribute node:

index.php/fa/37131/0/

<attributeRule
attributeURI="http://www.eclipse.org/oomph/setup/git/1.0#//GitCloneTask/location"
value="${git.container.root/}${@id.remoteURI|gitRepository}"/>

In the Oomph UI I do not see such an entry. Also the icon does not match anything I see. How can I set this?


[Updated on: Fri, 10 January 2020 10:37]

Report message to a moderator

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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
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.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Predefining the Git clone location rule and Root Git-container folder [message #1819242 is a reply to message #1819240] Fri, 10 January 2020 12:11 Go to previous message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

Thanks for the reply Ed.

Would you consider adding the option to preconfigure the git name strategy in the future of changing the default to the same as EGit is using? If yes, I will open a bug on this.

> 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

Thanks that reduced the need to override this property, I will still try to make it work and if not successful I will upload the profile in case you want to have a look.
Previous Topic:How to create a repository id in a generated target?
Next Topic:Testing setup profiles - Do I need to restart the installer
Goto Forum:
  


Current Time: Fri Apr 19 09:39:04 GMT 2024

Powered by FUDForum. Page generated in 0.02681 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top