Allow options for cookie domain, secure, and httponly

[marcguyer]

• Are you creating a new feature?
  • Why is the new feature needed? What purpose does it serve?
    • enables setting optional cookie params
  • How will users use the new feature?
    • via config options or manually via new constructor args
  • Base your feature on the develop branch, and submit against that branch.
  • Add only one feature per pull request; split multiple features over multiple pull requests
  • Add tests for the new feature.
  • Add documentation for the new feature.
  • Add a CHANGELOG.md entry for the new feature.

[samsonasik]

please rebase against develop branch to show only your commits in the PR. You can use the following steps:

1. checkout develop and pull upstream develop

git remote add upstream https://github.com/zendframework/zend-expressive-session-cache.git
git checkout develop && git pull upstream develop

2. checkout feature/cookie-options and rebase

git checkout feature/cookie-options && git rebase develop

3. Force push to feature/cookie-options branch

git push --force origin feature/cookie-options

I created a blog post about it at https://samsonasik.wordpress.com/2015/09/16/practical-git-4-rebasing-conflicted-task-branch-against-primary-branch/

[marcguyer]

Guys, I've done quite a bit to attempt to comply with this request but as yet I'm unable. I have a few questions/comments:

1. Why would I git remote add upstream https://github.com/zendframework/zend-expressive-session-cache.git? Isn't that just the same as origin?
2. After remote add upstream, When I attempt to git checkout develop, I get:

$ git checkout develop
error: pathspec 'develop' did not match any file(s) known to git
hint: 'develop' matched more than one remote tracking branch.
hint: We found 3 remotes with a reference that matched. So we fell back
hint: on trying to resolve the argument as a path, but failed there too!
hint: 
hint: If you meant to check out a remote tracking branch on, e.g. 'origin',
hint: you can do so by fully qualifying the name with the --track option:
hint: 
hint:     git checkout --track origin/<name>
hint: 
hint: If you'd like to always have checkouts of an ambiguous <name> prefer
hint: one remote, e.g. the 'origin' remote, consider setting
hint: checkout.defaultRemote=origin in your config.

That sounds reasonable, so I go ahead and git checkout --track upstream/develop, then

$ git pull upstream develop 
From https://github.com/zendframework/zend-expressive-session-cache
 * branch            develop    -> FETCH_HEAD
Already up to date.

Ok, so I don't think anything meaningful has happened yet... Moving on anyway:

$ git rebase develop
Current branch feature/cookie-options is up to date.

Right, still nothing happening... So I attempt to run the force push just to see, but of course I do not have push permission for origin:

$ git push --force origin feature/cookie-options
fatal: remote error: 
  You can't push to git://github.com/zendframework/zend-expressive-session-cache.git
  Use https://github.com/zendframework/zend-expressive-session-cache.git

Maybe origin was a typo, so I try upstream since it's using https: instead of git::

$ git push --force upstream feature/cookie-options
remote: Permission to zendframework/zend-expressive-session-cache.git denied to marcguyer.
fatal: unable to access 'https://github.com/zendframework/zend-expressive-session-cache.git/': The requested URL returned error: 403

... and that makes perfect sense since I should not be allowed to push to origin, right?
3. I've tried to understand how I have mwop's "Bumped version" commit in my PR to see if I could gain some context to solve that but I'm confounded by how that occurred. I've retraced all steps and even recreated all steps with a new clone but the result is the same.

Sorry, I'm at a loss at this point. I'd very much like to understand.

[samsonasik]

You can check your .git/config inside your local repository. The origin should be your fork repository, the upstream, or whetever you would like to name it, is the current repository, so consider your local .git/config has the following:

# ...
[remote "origin"]
	url = git@github.com:marcguyer/zend-expressive-session-cache.git
	fetch = +refs/heads/*:refs/remotes/origin/*

[remote "upstream"]
	url = https://github.com/zendframework/zend-expressive-session-cache.git
	fetch = +refs/heads/*:refs/remotes/upstream/*
# ...

You need to sync with latest upstream, and rebase against it. Push force is to origin (your own), not to upstream (this repo).

[marcguyer]

The origin should be your fork repository, the upstream, or whetever you would like to name it, is the current repository

Not if you follow the Recommended Workflow for Contributions. In that case, the base repo is the "origin" and there is a second remote that is my fork.

I issued a second PR #7 just now that I think will take care of what you want. When issuing the PR, I changed the base branch from master to develop which is what I think you want anyway for a feature, right? If that works, let's close this one.

[samsonasik]

Oh, I'm sorry, then you need to push force "marcguyer" for that. The .git/config will look like:

# ...
[remote "marcguyer"]
	url = git@github.com:marcguyer/zend-expressive-session-cache.git
	fetch = +refs/heads/*:refs/remotes/origin/*

[remote "origin"]
	url = git://github.com/zendframework/zend-expressive-session-cache.git
	fetch = +refs/heads/*:refs/remotes/upstream/*
# ...

The process is same. You rebase from against zendframework repo. The last one is push --force your own repo.

[michalbundyra]

@marcguyer So it can be closed in favour of #7?

[geerteltink]

Duplicate of #7