May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
> On 5/24/11, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > The tests are
> > currently fully passing on Windows.
>
> But the thing is, the autotester uses a changeset dated May 22nd, but the latest changeset on github (https://github.com/D-Programming-Language/phobos) is May 16th, and that is the one I've cloned from and it has failing unittests.
>
> So I'm not sure where to go from there.
Just grab what's on github. It's the latest. The autotester grabbed something from May 22nd last, because dsimcha accidentally committed some code to the main repository instead of his own. He reverted it. No more checkins have been made since then, so the autotester hasn't grabbed anything new yet. github always has the latest code.
Besides, if you look at the output on github, it's giving the same output as your original post. Note that it's a printout saying that a test is broken _not_ a test failure. It's a reminder that a test (and possibly related code) needs to be fixed. No unit tests are actually failing. An AssertError is thrown whenever that happens. What's on github is fine.
- Jonathan M Davis
|
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
Ah, I thought it was an actual test failure. Yes, I should have checked the build results, silly me. :) Thanks for all the help Jonathan & others. |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
Hmm I've gotten into some trouble. I've made a pull request for my first fix from a new branch: https://github.com/D-Programming-Language/phobos/pull/56 Then I wanted to do another fix so I created a new branch, made the fix, pushed to my phobos fork on github. Then I did a pull request from this new branch, but in the new pull request it also showed two commits, the new one and the older one from the previous pull request. Should I have made multiple commits for each fix and do only a single pull request? |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
I closed down the second pull request btw. |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
On 2011-05-24 11:45, Andrej Mitrovic wrote:
> Hmm I've gotten into some trouble. I've made a pull request for my first fix from a new branch: https://github.com/D-Programming-Language/phobos/pull/56
>
> Then I wanted to do another fix so I created a new branch, made the fix, pushed to my phobos fork on github. Then I did a pull request from this new branch, but in the new pull request it also showed two commits, the new one and the older one from the previous pull request.
>
> Should I have made multiple commits for each fix and do only a single pull request?
If you do each fix on completely separate branches, then you shouldn't have this problem. It sounds like you didn't start with a clean branch. Each branch needs to be made off a clean master (as in it has none of your changes in it) or it'll have all of the changes that differ from the main repository's master. That's one reason to always keep a clean master and make no changes on it directly. Any branches that you make from it are going to be clean.
Now, combining related changes into a single pull request (especially if they're small) is fine. In fact, if the changes are small and at all related, it would probably be preferrable, since then there's less administration to deal with. However, remember that each pull request can be accepted or rejected individually, so if there's any real chance that one set of changes would be accepted and another rejected (particularly if they're not really all that related), then they should probably be separate pull requests. But remember that there's always the possibility that you'll be asked to make adjustments to your pull request, so it's still possible for parts of your initial request to be accepted and others rejected. Just use your best judgement on whether your changes are related enough to be done as a single pull request or whether they should be done separately.
- Jonathan M Davis
|
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
I think I know what happened. After I've pushed my first branch, I immediately created a second branch while I was still in the first branch. I think I should have switched to the main branch and then created the second branch. Otherwise, these two changes were just sample code fixes which get displayed in the docs. I guess you could say they're related, and they're really small changes anyway. |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
On 2011-05-24 12:34, Andrej Mitrovic wrote: > I think I know what happened. After I've pushed my first branch, I immediately created a second branch while I was still in the first branch. > > I think I should have switched to the main branch and then created the second branch. When you create a branch, it's a copy of whatever branch you were on when you created the copy. A branch doesn't have to come from master. So, if you branched from a branch, then all of your changes from the first branch would be in the second. > Otherwise, these two changes were just sample code fixes which get displayed in the docs. I guess you could say they're related, and they're really small changes anyway. Well, documentation fixes in general can probably be lumped together - especially website documentation as opposed to ddoc - at least as long as they're not major changes. If you're rewriting whole sections of documentation, then you might want to do separate pull requests. But small documentation fixes would probably be better put in a single change request to avoid the administrative overhead of multiple pull requests. Where you really get into issues with combining pull requests is when you combine completed unrelated bug fixes, and it doesn't sound like you're doing that. - Jonathan M Davis |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
These two were from ddoc. They're just typo's that were fixed, simple to review and merge with master. But I might have gone overkill with the DPL.org pull request: https://github.com/D-Programming-Language/d-programming-language.org/pull/9 For that one most errors that were fixed were just code sample typo's, but in other instances I've added some missing documentation (they're rather small additions). I hope it's not too much for a pull request, otherwise I'll have to figure out how to separate them into multiple pull requests. |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
Also for one commit almost the entire module is labeled as changed, I've no idea how that happened (perhaps too many changes confuses github?). The commit in question is this one: https://github.com/AndrejMitrovic/d-programming-language.org/commit/70fb8902ebd7a63fa88e06700d776fb5dc876d99 |
May 24, 2011 Re: github: What to do when unittests fail? | ||||
---|---|---|---|---|
| ||||
> Also for one commit almost the entire module is labeled as changed,
> I've no idea how that happened (perhaps too many changes confuses
> github?). The commit in question is this one:
> https://github.com/AndrejMitrovic/d-programming-language.org/commit/70fb890
> 2ebd7a63fa88e06700d776fb5dc876d99
My guess would be that you ended up changing the line endings.
- Jonathan M Davis
|
Copyright © 1999-2021 by the D Language Foundation