On Wed, Dec 4, 2013 at 5:47 PM, Noah Slater <[email protected]> wrote:
> Jason makes a compelling argument. > > Let's say you do three commits on a feature branch: > > [code] Add foo widget to core > [tests] Add tests for foo widget > [docs] Add docs for foo widget > if the tag would be code it would be indeed useless. But it was not what I suggested. Instead a tag should be related to the feature it patches. I gave more examples in another mail. > What do you then use as a commit message when you squash and merge into > master? > > And let's say we want to accept a pull request on Github that adds foo > atomically. Are we really going to send the person away and ask them > to decompose the commit into many commits, each one with a tag? > yes. This is a good practice. Like we should have unit tests, a commit should be enough atomic to not touch many parts of the repository. And hopefully coming with a test. > > I think I've convinced myself that this should, at the most, be optional. > If the system if it's optional it lost any interest. People that don't want to use it won't use it and we will stay with the same soup and meaningless commit messages forcing people to read the full change to figure.
