Community
Participate
Working Groups
.
We had an offline chat with Szymon about it and what he described sounded reasonable.
*** Bug 367434 has been marked as a duplicate of this bug. ***
I will try to tackle this issue in .5M1.
The current shape of git URIs looks like this "/gitapi/{git-resource}/{git-resource-id}/file/{file-id}", where {git-resource} can be "commit", "tag", "diff" etc, {git-resource-id} can be "master", "d8f0b730b44875e34e25f996ab8111f041477115", "d8f0b730b44875e34e25f996ab8111f041477115..master", "I20120403-8000", etc. The "file/{file-id}" points to a folder containing the cloned repository, thus {file-id} can be "a", but also "a/folder/subfolder", where "a" is a top-level/project ID. The problem is that both {git-resource-id} and {file-id} can have multiple segments (separated with "/"). Therefore it's hard if not impossible to determine when one ends and second begins. The "file" segment cannot serve as a delimiter as it can also appear as part of {git-resource-id} or a folder name in {file-id} (or both). There are at least two ways of fixing this: * Encode either {git-resource-id} or {file-id}. The former was proposed by Szymon in comment 0. That would make number of segments constant. * Add an info about number of segments in {git-resource-id} or {file-id} e.g. /gitapi/tag/3/t/a/g/file/a where "3" indicates that the following 3 segments form the tag name ie "t/a/g". I would go with encoding the {git-resource-id} part as it would allow us not to worry about other reserved characters in the URI, see chapter 2.2. in http://www.ietf.org/rfc/rfc2396.txt
(In reply to comment #4) > There are at least two ways of fixing this: > * Encode either {git-resource-id} or {file-id}. The former was proposed by > Szymon in comment 0. That would make number of segments constant. > * Add an info about number of segments in {git-resource-id} or {file-id} e.g. > /gitapi/tag/3/t/a/g/file/a where "3" indicates that the following 3 segments > form the tag name ie "t/a/g". > > I would go with encoding the {git-resource-id} part as it would allow us not to > worry about other reserved characters in the URI, see chapter 2.2. in > http://www.ietf.org/rfc/rfc2396.txt +1 for encoding and constant number of segments.
Created attachment 213701 [details] A work-in-progress Added DecodedGitHandlerV1 class which is going to be a super class for all git handlers. The new class decodes the git segment.
Created attachment 213702 [details] mylyn/context/zip
Fixed with ff0e48d5a612b626217de8814759f9c976bbd95e. Handlers for Commit, Diff, Branch and Tag extend now the AbstractGitHandler which encodes git segment from the request. If this needs to be done for any other git handler I will fix it in a separate bug.
