I'm not sure what is "obvious" about this behavior, but there's no use
ranting about something that can't be changed.
Like many others, I use GitHub as a backup to my local work, so I commit
often. For those commits to appear in a pull request I did days prior is
fantastically backwards with my t
If you commit them to the github repo its obvious though that those newer
changes will get pulled in with the pull request. When making changes and
filing pull requests I would finish up lets say for example you got VST's
to work all that work i commit it to the local repo then the remote repo
then
On Thu, May 8, 2014 at 4:32 PM, Jonathan Aquilina wrote:
> After each set of change s create a pull request
>
Yes, and it is that mentality that I was operating from (FYI, it tosses
those newer changes that occur after the request in without asking).
-Tres
---
After each set of change s create a pull request
On 8 May 2014 21:53, "Tres Finocchiaro" wrote:
> Question,
>
> As I'm making changes to my branch they all seem to land into my last pull
> request. Is this normal?
>
> I'd much rather have one pull requests for each chunk of changes.
>
> What am
Toby was nice enough to accept the one large pull request (thanks Toby).
Please curse my name if SWH stuff acts up in 1.0.3.
Apple has SWH support now (needs testing).
-Tres
- tres.finocchi...@gmail.com
On Thu, May 8, 2014 at 3:58 PM, Tres Finocchiaro wrote:
> Thanks. That's what I feared.
Thanks. That's what I feared...
I find that a bit overkill since these changes don't conflict with
each-other and making a branch for a very small change just to delete it
down the road seems unnecessary, but if that's the approach, then that's
what I'll have to do.
--
Hi,
The recommended way with git is to have a separate branch for each issue
(e.g. "master-new_awesome_plugin", "master-iss235"). You'll then have to
submit a pull request for each branch.
- Lukas
2014-05-08 21:53 GMT+02:00 Tres Finocchiaro :
> Question,
>
> As I'm making changes to my branch
