Where to upload updated QSRef.pdf

[Howard Melman]

I updated the Quick Reference to add the new collection key bindings. Where should I upload it?

The last time I uploaded the docs it was to qs0.qsapp.com/home/qs/public_html/docs. Now I get a message that the host key changed and the path isn't found. I'm guessing that this was from before the hosting change.

Howard

[Patrick Robertson]

I’d say make a pull request to the GitHub repository then we can merge it in to the new site.

We changed hosts a few months back, which means your old keys/paths won’t work.

Will this be your first pull request Howard? :)

https://github.com/quicksilver/QSApp.com/tree/master/docs

(Fork the repo - top right hand corner, upload the file using your browser (or git) then submit a PR)

--
You received this message because you are subscribed to the Google Groups "Quicksilver - Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quicksilver---deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Howard Melman]

I've done a little bit with git locally and done a couple of pull requests via github about a year ago (long enough to forget any details).

For this, I'll skip making a local repository, just fork on github and upload the new pdf. I can do this on master or should I make a new branch? (this would be the details I forget :)

Howard

[Rob McBroom]

On 15 Apr 2016, at 11:11, Howard Melman wrote:

> I've done a little bit with git locally and done a couple of pull
> requests via github about a year ago (long enough to forget any
> details).
>
> For this, I'll skip making a local repository, just fork on github and
> upload the new pdf. I can do this on master or should I make a new
> branch? (this would be the details I forget :)

Short answer: master

Long answer: That’s up to you. In this case, since you’re making a
small change and are unlikely to make any more changes before this one
gets merged, using master should be fine.

Basically, any branch you use to submit a pull request will be hostage
until that request is merged. If that branch is master, that can have
ugly consequences.

If you wanted to start working on something else, you couldn’t do the
changes on master because they’d get included with the old request,
and you couldn’t make a new branch because it would also include the
stuff currently on master. There are ways around that last one, but
I’m not trying to write a book here. You get the idea. :-)

--
Rob McBroom
http://www.skurfer.com/

[Jon Stovell]

After getting burned by this once, I made it a policy for myself that I would always make changes on a new branch, even little ones. One never knows what the future holds, after all. ... But yeah, Howard could do it directly on master if he wanted to.

[Rob McBroom]

On 15 Apr 2016, at 21:23, Jon Stovell wrote:

> After getting burned by this once, I made it a policy for myself that
> I

> would *always* make changes on a new branch, even little ones.

Agreed. Once you’re comfortable managing branches, it’s so easy that
it’s worth it every time. But for people that aren’t using Git all
day every day, the right choice isn’t as obvious.

[Howard Melman]

Yeah I get it. In this case it was just uploading a pdf, not a set of sources to be built. And GitHub's UI showed upload to master the first choice. Thanks.

Howard