support package-lock.json #954
Conversation
|
now, we have failing checks... Maybe we can provide a pr at |
Codecov Report
@@ Coverage Diff @@
## master #954 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 44 44
Lines 2109 2109
Branches 99 99
=====================================
Hits 2109 2109
Continue to review full report at Codecov.
|
|
Until |
|
Sorry? I don't understand what you're trying to say. |
|
Issue: chaijs/chai-as-promised#184 |
|
@jens1o I would appreciate if the PR you create are from your fork. |
|
Yeah, I saw this just after I created it, sorry. Won't happen again. |
|
@JimiC, @jens1o, personally I don't care about where the PR is coming. I mean, in this repo we're all maintainers and as a team, in my opinion, working in the same repo is the way to go. There's no benefit in keeping a fork. This was invented in order to collaborate with repositories where you don't have any privilege. Once you're allowed to push to the repo you can create branches. Indeed, it's easier for the team members to collaborate with each other: if they need some help it's easier to add things to your colleague's branch. No need to add a remote for every member of your team if you want to know what are they working on or make some modifications to their suggested changes and so on. That being said, I'm ok with you working on a fork if that's the way you prefer to work. No problem with that. I just wanted to point out that for me that wouldn't be the first option for working as a team. |
|
@robertohuertasm Personally I like keeping the main repo clean. Imagine each collaborator creating a branch for each thing they are working on. It can easily become a mess. I've seen it happening and that's why I'm in favor working with fork/branch flow. On the contrast creating as many branches as they want on their own fork doesn't affect anyone. |
|
@JimiC, I gently disagree. The rule of thumb is that feature branches should be kept local until ready to be merged and then, and only then, pushed to the remote repo. Then it's time for revision, merging and finally deleting the feature branch (via PR or MR depending on the Git service). You're aware that until a branch is not pushed it only exists in your local copy so you can create all the branches you need without cluttering the remote repo. I've been working like this for a long time now and I've not found any kind of messes. But of course, these are just practices and everyone is entitled to do what they think is best for them. 😉 I just wanted to tell you my preference and give you the reasoning behind it, not trying to impose my vision to anybody. PS: Just out of curiosity @JimiC, do every member of your team (at work) work with a fork of the main repo? |
|
Personally, I also see the advantages, because when I do it here, I don't have to fetch the upstream, but I can work how I want without additional steps. Until today, I didn't knew how @robertohuertasm would react, that's why I kept it in my fork. |
|
@robertohuertasm I was merely expressing a personal belief. Because I work on diff machines (at work and at home) I tend to push my branches to make them available from everywhere. This way I can continue to work on a feature, bugfix, concept wherever I am. Regarding your P.S. question, every member takes up a project so it's basically a one-man team. So the Git-flow is somewhat indifferent. |
Fixes #953
Changes proposed:
Things I've done: