Bug 347943

Comment 1 Tomasz Zarna 2011-06-06 12:24:50 EDT

We had an offline chat with Szymon about it and what he described sounded reasonable.

Comment 2 John Arthorne 2011-12-23 10:23:58 EST

*** Bug 367434 has been marked as a duplicate of this bug. ***

Comment 3 Tomasz Zarna 2012-03-15 09:00:51 EDT

I will try to tackle this issue in .5M1.

Comment 4 Tomasz Zarna 2012-04-03 09:32:40 EDT

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

Comment 5 Szymon Brandys 2012-04-03 09:51:47 EDT

(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.

Comment 6 Tomasz Zarna 2012-04-06 08:31:39 EDT

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.

Comment 7 Tomasz Zarna 2012-04-06 08:31:43 EDT

Created attachment 213702 [details]
mylyn/context/zip

Comment 8 Tomasz Zarna 2012-04-19 13:15:54 EDT

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.