$ git remote add nblair https://github.com/nblair/uPortal.git $ git fetch nblair $ git checkout master $ git merge nblair/UP-3226
That adds your github clone as a remote resource I can interact with, then fetch information from your repository, then merge your UP-3226 branch into the branch I currently have checked out (master in this case). If I then do a git push that is effectively the same thing as you doing a pull request on github and me clicking the "merge" button.
Note that a couple handy views when doing this stuff are:List of branches and their sync state: https://github.com/nblair/uPortal/branches Diff between your branch and master: https://github.com/nblair/uPortal/compare/master...UP-3226
I'm taking lots of notes on all these git questions and am going to get a wiki page put up this week and some more questions to the dev list to see what people prefer.
-Eric On 10/23/11 8:18 PM, Nicholas Blair wrote:
The fix turns out to be a little simpler; I adjusted how CachedPortletData values are stored in the cache when validation method is being used.I have a question now to follow that goes along with the ongoing Git discussions:Should I just issue a Pull request right away? Or is there a way for the reporter of the issue to snag my changes, try them out locally to confirm?Here's my change: https://github.com/nblair/uPortal/commit/c743c295ea6fe868bace8c0069333d2d6b308043On Thu, Oct 20, 2011 at 4:58 PM, Jen Bourey <[email protected] <mailto:[email protected]>> wrote:Hi all, I think I've encountered some misbehavior in uPortal 4's validation-based resource URL caching. To summarize, it looks like portlets send back blank responses when a portlet thinks the ETag matches, but the content itself has expired out of the portal's cache. I think I can currently demonstrate this behavior using the Jasig Test Portlet's Cache Control (CacheControl Validation Method) Test. If you click the "Get JSON content" button, the first request will appropriately send back a 200 OK response with content, and a subsequent click will result in a blank 304 Not Modified response. However, if I wait longer than two minutes, then click the button, I appear to get a 200 OK response with no content. First of all, I think we might want to update the functional test portlet's CacheTestController.writeJsonContentWithValidationCaching method to validate the ETag included in the request. It would be useful for the test case to be able to distinguish between requests that include a still-valid ETag and a request that has an Etag that doens't match our conception of "current". Beyond our test cases though, it seems that the portal needs to be able to respond to a request that has a still-valid ETag, but for which content has expired out of the portal's cache. In the case of resource URLs, it seems like it should be OK that the content is missing from the cache, since we don't actually want to send the content itself back. I think we just want to send back a 302 header and move on. Has anyone else encountered this behavior in the test case? Does my reading of the intended behavior for resource URLs sound correct? - Jen -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
