Where should I dump workarounds?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 30, 2016 17:14:37 Dukc via Digitalmars-d-learn wrote:
> Well, I was working on std.range.chain (I'm new to contributing),
> and when trying to test locally:
>
> ...\phobos\std\range>rdmd -unittest -main package
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\path.d(1319): Error:
> pure function 'std.path.buildPath!char.buildPath' cannot call
> impure function 'std.path.buildPath!(const(char)[][]).buildPath'
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\path.d(1319): Error:
> @safe function 'std.path.buildPath!char.buildPath' cannot call
> @system function 'std.path.buildPath!(const(char)[][]).buildPath'
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\path.d(1319): Error:
> function 'std.path.buildPath!(const(char)[][]).buildPath' is not
> nothrow
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\path.d(1315): Error:
> nothrow function 'std.path.buildPath!char.buildPath' may throw
> package.d(8718): Error: template instance std.path.buildPath!char
> error instantiating
>
> Error in a totally different place! If my code caused this, I
> have no idea how: I haven't touched unittests nor std.path.
>
> Since I don't think you like if my pr (if I manage to even do it)
> contains fixes to other stuff than what I'm trying to do, I
> wonder where I should start patching this. Should I make a new
> branch off master and when done, merge it into the branch I have
> now? Or should I make an entirely new fork?

Well, normally, you wouldn't be using master to do pull requests at all. You
create a branch for a particular fix, push that up to github, and then you
create a PR from that branch. You can then have multiple, independent
branches with fixes at once, and your master branch can then always match
whatever the official master branch is. I don't think that anyone who
contributes more than once or twice is creating pull requests from their
master branch. And personally, I think that it's far too valuable to have
your master branch match the official master branch to ever do anything on
my own master branch.

Whether separate PRs or one are better for what you're doing, I can't say,
because I don't know what you're doing. But if you have an independent fix -
particularly if the main thing that you're doing is an enhancement rather
than a fix - then I'd say that you should create a branch for that and
submit it. You can then create another branch from that one to work on
whatever it is you're doing that needed that fix. Then, if you finish that
before the first is merged, you'd either need to wait for the first one to
be merged, or you'd need to remove the first fix's commits from the second
branch (easy enough with git rebase) and create a PR from that with a
comment that it depended on the other PR. If you wait to create the second
PR (either because the first gets merged before the second is ready or
because you just choose to wait), then you can rebase the second branch so
that its changes go on top of the updated master (which should work without
removing the first branch's commits from the second branch before rebasing
if no other changes were made to the first branch before it was merged, but
I'd probably just remove those commits from the second branch to ensure that
there were no merge issues), and then you can create a PR from that.

But git makes branching very easy (even if the commands are more confusing
than they should be), so it makes a lot of sense to create separate branches
for each fix, regardless of what gets merged when.

In case you're not very familiar with git rebase, here's a relevant SO
question (where I got to feel like an idiot for mixing up the git commands):

http://stackoverflow.com/questions/7297379

- Jonathan M Davis