Skip to main content
added 340 characters in body
Source Link
Mark Rogers
  • 297
  • 1
  • 2
  • 10

Usually often is better than a massive one.

Smaller, more frequent, pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. It's just too tough on one's mental RAM to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There may be situations, however, where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Also note that sometimes I need to cherry pick commits into a separate branches. If what needs to be cherry picked can be put into a single commit it makes it easier to move it around to other branches. This is a case where actually having few commits is better, but its not exactly the standard process if your cherry picking around.

Usually often is better than a massive one.

Smaller, more frequent, pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. It's just too tough on one's mental RAM to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There may be situations, however, where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Usually often is better than a massive one.

Smaller, more frequent, pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. It's just too tough on one's mental RAM to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There may be situations, however, where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Also note that sometimes I need to cherry pick commits into a separate branches. If what needs to be cherry picked can be put into a single commit it makes it easier to move it around to other branches. This is a case where actually having few commits is better, but its not exactly the standard process if your cherry picking around.

Copy edited (e.g. ref. <http://en.wikipedia.org/wiki/Random-access_memory>). [(its = possessive, it's = "it is" or "it has". See for example <http://www.wikihow.com/Use-Its-and-It%27s>.)]
Source Link

Usually Oftenoften is better than a massive one.

Smaller, more frequent, pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. TheThe smaller the pull request, the easier it is to review the code, even if there are more total pull requests. MostMost humans of any sort will not be able to do meaningful reviews of massive pull requests. ItsIt's just too tough on one's mental ramRAM to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. ButBut then your pull request will be small anyway.

There maybemay be situations, however, where the feature has to be released all at once. EvenEven then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Usually Often is better than a massive one.

Smaller more frequent pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. Its just too tough on one's mental ram to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There maybe situations however where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Usually often is better than a massive one.

Smaller, more frequent, pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. It's just too tough on one's mental RAM to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There may be situations, however, where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

deleted 3 characters in body
Source Link
Mark Rogers
  • 297
  • 1
  • 2
  • 10

Usually Often is better than a massive one.

Smaller more frequent pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more of total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. Its just too tough on one's mental ram to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There maybe situations however where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Usually Often is better than a massive one.

Smaller more frequent pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more of total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. Its just too tough on one's mental ram to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There maybe situations however where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Usually Often is better than a massive one.

Smaller more frequent pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. Its just too tough on one's mental ram to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There maybe situations however where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

edited body
Source Link
Mark Rogers
  • 297
  • 1
  • 2
  • 10
Loading
Source Link
Mark Rogers
  • 297
  • 1
  • 2
  • 10
Loading