Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324441

Summary: Git reader does not find tags
Product: z_Archived Reporter: Carsten Reckord <reckord>
Component: BuckminsterAssignee: buckminster.core-inbox <buckminster.core-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: henrik.lindberg, matthew, philippn, thomas
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 354085    
Attachments:
Description Flags
query with tag
none
resource map for query none

Description Carsten Reckord CLA 2010-09-03 11:39:30 EDT
Using a branchTagPath in an advisory node for a component residing in git, no match is found by the buckminster git reader.

For example resolving the attached query for org.eclipse.xpand with branchTagPath="/Galileo_SR2" gives

...
org.eclipse.xpand:osgi.bundle: Trying provider 
git({0}/xpand,plugins/{1}[/home/creckord/NoBackup/buckminster/workspace/xpand,plugins/org.eclipse.xpand])
org.eclipse.xpand:osgi.bundle: tags will be searched
master
org.eclipse.xpand:osgi.bundle: No tags were found
org.eclipse.xpand:osgi.bundle: Rejecting provider 
git({0}/xpand,plugins/{1}[/home/creckord/NoBackup/buckminster/workspace/xpand,plugins/org.eclipse.xpand]): No component match was found
...
ERROR   [0001] : No suitable provider for component org.eclipse.xpand:osgi.bundle was found in resourceMap 
file:/home/creckord/NoBackup/buckminster/platform.rmap
   ERROR   [0001] : No suitable provider for component org.eclipse.xpand:osgi.bundle was found in searchPath org.eclipse.xpand
     ERROR   [0001] : Rejecting provider 
git({0}/xpand,plugins/{1}[/home/creckord/NoBackup/buckminster/workspace/xpand,plugins/org.eclipse.xpand]): No component match was found
...

Interestingly enough, buckminster says "No tags were found", but if I take a look at the repository that was cloned during the resolution, 
it has all the tags:

creckord@sylar:~/buckminster/workspace$ ls xpand/.git/refs/tags/
Galileo  Galileo_M5  Galileo_M6  Galileo_M7  Galileo_RC1  Galileo_RC5  Galileo_SR2  Helios_Final  Helios_M3  Helios_M4  Helios_M5  Helios_M6  Helios_M7  Helios_RC1  Helios_RC2  Helios_RC3  Helios_RC4  v1.0.1

--
Version info:
org.eclipse.buckminster.core.feature 1.3.1.r11518
org.eclipse.buckminster.git.feature 1.0.360.r11433
Comment 1 Carsten Reckord CLA 2010-09-03 11:41:59 EDT
Created attachment 178169 [details]
query with tag
Comment 2 Carsten Reckord CLA 2010-09-03 11:42:18 EDT
Created attachment 178170 [details]
resource map for query
Comment 3 Thomas Hallgren CLA 2010-09-03 13:11:41 EDT
Thanks for the sample. I'll use that to verify a fix. The egit/jgit bundles are currently being very actively developed. Several API changes are released in Helios SR1 and we're doing our best to keep up.
Comment 4 Adolfo Sanchez-Barbudo Herrera CLA 2011-07-06 14:20:23 EDT
Thommas,

I found this related opened bugzilla ... Could you also verify that the branches work as expected ?. 

As commented in the Bug 350210 (comment_4) I can only make the master branch be used if I use "main" as the branchTagPath of the selection criteria of an advisor node.

Since you have recently moved to Git, I guess you will need to deal with this (your maintenance build still is configured against subversion).

Regards,
Adolfo.
Comment 5 Thomas Hallgren CLA 2011-07-12 09:52:45 EDT
This bug has now been fixed. A couple of notes.

1. Checking out a tag will normally create a detached head. Buckminster will therefore automatically create a branch with the name 'tag-branch_' + tagName when this happens.

2. Checking out remote branches is considered very bad practice (it also results in a detached head). Buckminster will therefore create a local branch with the same name as the remote and track the remote branch. This is essentially the same as git checkout --track -b <branch> origin/<branch>

3. branches like remotes/origin/<branchName> or origin/<branchName> will automatically be stripped down to just <branchName> to avoid checkouts of the remote branch. In essence, such name should not be used, but if they are, Buckminster "fixes" that.

Info logging will print some information when Git clone and checkout commands are executed.

http://git.eclipse.org/c/buckminster/buckminster.git/commit/?id=96c3ef4afb248f74cf05cd30e80f62ae26a08aff
Comment 6 Henrik Lindberg CLA 2011-07-13 09:44:47 EDT
This deserves a documentation issue.
Comment 7 Thomas Hallgren CLA 2011-07-13 09:48:09 EDT
I know. I meant to ask, do we have any documentation at all on the git provider?
Comment 8 Matthew Webber CLA 2011-08-05 10:55:44 EDT
(In reply to comment #5)
> This bug has now been fixed. A couple of notes.

Do you know when Buckminster (IDE and headless) will next be updated to incorporate this fix? We're interested in getting it, as we habe also had problems checking out Git tags.
Thanks
Comment 9 Thomas Hallgren CLA 2011-08-07 06:53:21 EDT
The fix is available in the "Buckminster - Git Support" feature version 1.4.0.v20110712-1350. It has been available on our update sites since July 13.
Comment 10 Adolfo Sanchez-Barbudo Herrera CLA 2012-01-31 05:42:31 EST
Hello Thomas,

I've ended up in this bugzilla again.

(In reply to comment #5)
 
>> 2. Checking out remote branches is considered very bad practice (it also results
> in a detached head). Buckminster will therefore create a local branch with the
> same name as the remote and track the remote branch. This is essentially the
> same as git checkout --track -b <branch> origin/<branch>
>

Concerning this change.

Due to the Bug 369794 and after reading the bucky boook, I've recently added the following option in my rmap:

git.auto.fetch (= true)

As I commented in that bug, I guessed that to have the issue solved, buckminster should be checking out the remote tracking branch. This bug asserts that this behaviour is not occurring anymore.

- Is there any option to make buckminster pull from the remote repository ?
- Does the git.auto.fetch option, fetch the remote tracking branch and pull to the local one ?

Regards,
Adolfo.