On Apr 6, 2012, at 2:25 PM, Bill Burke wrote:
> Isn't it
>
> git checkout new-filter-api
>
> or
>
> git checkout -b new-filter-api origin/new-filter-api
>
> There is no -t switch.
The -t switch is there to setup an automatic tracking between the local and remote branch. Not sure what git version do you use, here's a snippet from my 'git help checkout':
-t, --track
When creating a new branch, set up "upstream" configuration. See "--track" in git-branch(1) for details.
If no -b option is given, the name of the new branch will be derived from the remote-tracking branch. If "remotes/" or "refs/remotes/" is prefixed it is
stripped away, and then the part up to the next slash (which would be the nickname of the remote) is removed. This would tell us to use "hack" as the local
branch when branching off of "origin/hack" (or "remotes/origin/hack", or even "refs/remotes/origin/hack"). If the given name has no slash, or the above
guessing results in an empty name, the guessing is aborted. You can explicitly give a name with -b in such a case.
Marek
>
> On 4/5/12 11:11 AM, Marek Potociar wrote:
>> Hello experts,
>>
>> Please review the reworked filtering API proposal. To review, please
>> checkout the remote branch:
>>
>> git clone ssh:///<user_name>/_at_git.java.net/jax-rs-spec~git jaxrs-api
>> cd jaxrs-api
>> git checkout -t new-filter-api origin/new-filter-api
>>
>> The API code is under src/jax-rs-api. Examples are under src/examples.
>> The git commit history will help you to better see the actual changes.
>>
>> What has changed (quite a lot):
>>
>> * filtering API has been split into server (container) and client part.
>> o client side: ClientRequestFilter, ClientRequestContext,
>> ClientResponseFilter, ClientResponseContext
>> o server side: ContainerRequestFilter, ContainerRequestContext,
>> ContainerResponseFilter, ContainerResponseContext, ResourceFilter
>> o Response remains a common component (went through some
>> modifications though - see bellow)
>> * Container filters are by default pre-matching
>> o There is a new @PostMatching name-binding annotation to support
>> global resource (post-matching) filters and interceptors
>> o DynamicBinding interface has been refactored into DynamicBinder
>> provider interface and javadoc has been clarified.
>> * Request changes have been rolled back - removed RequestHeaders,
>> RequestBuilder & Request API methods.
>> * Some of the removed methods were added to the filter context interfaces
>> * ResponseHeaders has been removed, Response API has been updated to
>> support common use cases and some of the ResponseHeaders methods
>> * Client API has been updated to accommodate the Req/Resp API changes.
>> * Examples have been updated to use the new filtering API. (Positive
>> fact is that in all cases the use of the new API meant less code in
>> the example filter implementation code.)
>>
>> Other changes:
>>
>> * MessageProcessingException has been moved from core into root package
>> * Client-side Target has been renamed to WebTarget to avoid a name
>> clash with java.lang.annotation.Target from Java SE.
>>
>>
>> Looking forward to your feedback. If possible, we would like to put the
>> proposal into the next EDR that is planned for 4/20, so please, make
>> sure to send your feedback by Friday next week CoB (4/13).
>>
>> Thank you,
>> Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com