2 added 149 characters in body
source | link
  1. Correct: a pull-request is linked to a branch in your repository. If you modify the branch, you are then also modifying what you're submitting as a pull-request.

    So yes, you do have to create a branch (and pull-request) per bug fix. It might be wise to start with one and see how the maintainer reacts to that one before going on to do the rest. Open source is an inherently social process.

  2. Do make a pull-request for your whitespace changes! Speaking as someone who's sometimes a maintainer, I love these types of pull-requests: I either approve them or don't, and they take little time to process.

    What you also might run into is that the maintainer does not agree with your whitespace changes! So, beware..

  3. Hmm.. It's not clear what you're trying to achieve here. It sounds like over-documentation and not that good of an idea -- maybe you can clarify why you would want to do this?

  4. Linking to his repo in your commit message (or even in a comment in the code) is a great way to give credit. Be careful though -- make explicit that you are thanking him for his ideas and not for his code. If you have copied code, then I would e-mail him about it, unless it's very clear which license he's using for his code. If the licensing is clear (and it's a different license from the repository you're submitting the commit to) then you need to add the different license in your pull-request and also mention that in your pull-request message.

  5. This is a really good question and differs depending on who you talk to. My opinion is that you should never add your name to any commit or code you do. The main reason is that it implies "ownership of and responsibility for the code" -- it might prevent others from modifying the code because "it's yours". But now we're getting into a huge discussion about the nature of open source, so I'll stop here and say -- ask the project maintainer or just do it and see what his reaction his.

  6. You can rewrite (your local, not-yet-published) history with GIT! Learn the git rebase command -- this is one the main reasons that I love git.  It's a really bad idea to (force) push rewritten commits/history to the shared repository (github, for example). This will then screw with the repositories that the other developers have -- they will have to do difficult things when pulling your (rewritten history) changes.

[#6: Thanks @toxalot!]

  1. Correct: a pull-request is linked to a branch in your repository. If you modify the branch, you are then also modifying what you're submitting as a pull-request.

    So yes, you do have to create a branch (and pull-request) per bug fix. It might be wise to start with one and see how the maintainer reacts to that one before going on to do the rest. Open source is an inherently social process.

  2. Do make a pull-request for your whitespace changes! Speaking as someone who's sometimes a maintainer, I love these types of pull-requests: I either approve them or don't, and they take little time to process.

    What you also might run into is that the maintainer does not agree with your whitespace changes! So, beware..

  3. Hmm.. It's not clear what you're trying to achieve here. It sounds like over-documentation and not that good of an idea -- maybe you can clarify why you would want to do this?

  4. Linking to his repo in your commit message (or even in a comment in the code) is a great way to give credit. Be careful though -- make explicit that you are thanking him for his ideas and not for his code. If you have copied code, then I would e-mail him about it, unless it's very clear which license he's using for his code. If the licensing is clear (and it's a different license from the repository you're submitting the commit to) then you need to add the different license in your pull-request and also mention that in your pull-request message.

  5. This is a really good question and differs depending on who you talk to. My opinion is that you should never add your name to any commit or code you do. The main reason is that it implies "ownership of and responsibility for the code" -- it might prevent others from modifying the code because "it's yours". But now we're getting into a huge discussion about the nature of open source, so I'll stop here and say -- ask the project maintainer or just do it and see what his reaction his.

  6. You can rewrite history with GIT! Learn the git rebase command -- this is one the main reasons that I love git.  

  1. Correct: a pull-request is linked to a branch in your repository. If you modify the branch, you are then also modifying what you're submitting as a pull-request.

    So yes, you do have to create a branch (and pull-request) per bug fix. It might be wise to start with one and see how the maintainer reacts to that one before going on to do the rest. Open source is an inherently social process.

  2. Do make a pull-request for your whitespace changes! Speaking as someone who's sometimes a maintainer, I love these types of pull-requests: I either approve them or don't, and they take little time to process.

    What you also might run into is that the maintainer does not agree with your whitespace changes! So, beware..

  3. Hmm.. It's not clear what you're trying to achieve here. It sounds like over-documentation and not that good of an idea -- maybe you can clarify why you would want to do this?

  4. Linking to his repo in your commit message (or even in a comment in the code) is a great way to give credit. Be careful though -- make explicit that you are thanking him for his ideas and not for his code. If you have copied code, then I would e-mail him about it, unless it's very clear which license he's using for his code. If the licensing is clear (and it's a different license from the repository you're submitting the commit to) then you need to add the different license in your pull-request and also mention that in your pull-request message.

  5. This is a really good question and differs depending on who you talk to. My opinion is that you should never add your name to any commit or code you do. The main reason is that it implies "ownership of and responsibility for the code" -- it might prevent others from modifying the code because "it's yours". But now we're getting into a huge discussion about the nature of open source, so I'll stop here and say -- ask the project maintainer or just do it and see what his reaction his.

  6. You can rewrite (your local, not-yet-published) history with GIT! Learn the git rebase command -- this is one the main reasons that I love git. It's a really bad idea to (force) push rewritten commits/history to the shared repository (github, for example). This will then screw with the repositories that the other developers have -- they will have to do difficult things when pulling your (rewritten history) changes.

[#6: Thanks @toxalot!]

1
source | link

  1. Correct: a pull-request is linked to a branch in your repository. If you modify the branch, you are then also modifying what you're submitting as a pull-request.

    So yes, you do have to create a branch (and pull-request) per bug fix. It might be wise to start with one and see how the maintainer reacts to that one before going on to do the rest. Open source is an inherently social process.

  2. Do make a pull-request for your whitespace changes! Speaking as someone who's sometimes a maintainer, I love these types of pull-requests: I either approve them or don't, and they take little time to process.

    What you also might run into is that the maintainer does not agree with your whitespace changes! So, beware..

  3. Hmm.. It's not clear what you're trying to achieve here. It sounds like over-documentation and not that good of an idea -- maybe you can clarify why you would want to do this?

  4. Linking to his repo in your commit message (or even in a comment in the code) is a great way to give credit. Be careful though -- make explicit that you are thanking him for his ideas and not for his code. If you have copied code, then I would e-mail him about it, unless it's very clear which license he's using for his code. If the licensing is clear (and it's a different license from the repository you're submitting the commit to) then you need to add the different license in your pull-request and also mention that in your pull-request message.

  5. This is a really good question and differs depending on who you talk to. My opinion is that you should never add your name to any commit or code you do. The main reason is that it implies "ownership of and responsibility for the code" -- it might prevent others from modifying the code because "it's yours". But now we're getting into a huge discussion about the nature of open source, so I'll stop here and say -- ask the project maintainer or just do it and see what his reaction his.

  6. You can rewrite history with GIT! Learn the git rebase command -- this is one the main reasons that I love git.