[Notes] [Git][BuildStream/buildstream][aevri/contributing_gitlab] 2 commits: contributing: non-WIP should always be landable

[Angelos Evripiotis <gitlab mg gitlab com>]

Title: GitLab

Angelos Evripiotis pushed to branch aevri/contributing_gitlab at BuildStream / buildstream

Commits:

• 5e838749
  by Angelos Evripiotis at 2018-11-07T13:05:49Z

  contributing: non-WIP should always be landable
  
  I was recently surprised that we don't prefer addressing review comments
  in 'fixup!' commits.
  
  Coming from GitHub, I've found that fixup commits make it easier for
  reviewers to see what has changed since their last review. The idea is
  to use '--autosquash' before landing to clean up the history again.
  
  It's a pleasant surprise that it's easy to keep track of what changed in
  merge-requests between pushes, so we can always keep the history clean.
  
  Document this, so folks like me can see the light sooner.
  

• 8d844696
  by Angelos Evripiotis at 2018-11-07T13:06:43Z

  contributing: emphasise the 'why' in commits
  
  Explain why it's useful to mention the decisions made for a change and
  provide links for background, e.g. issue numbers.
  
  My general experience of git histories is that folks don't do enough
  explaining, so it's great we have a contributing section for it.
  
  I've found it's easier for folks to stick to rules when they know the
  practical reasons for them, so provide some.
  

1 changed file:

• CONTRIBUTING.rst

Changes:

CONTRIBUTING.rst

---

...	...	@@ -128,6 +128,12 @@ If a commit in your branch modifies behavior such that a test must also
128	128	be changed to match the new behavior, then the tests should be updated
129	129	with the same commit, so that every commit passes its own tests.
130	130
	131	+These principles apply whenever a branch is non-WIP. So for example, don't push
	132	+'fixup!' commits when addressing review comments, instead amend the commits
	133	+directly before pushing. GitLab has `good support
	134	+<https://docs.gitlab.com/ee/user/project/merge_requests/versions.html>`_ for
	135	+diffing between pushes, so 'fixup!' commits are not necessary for reviewers.
	136	+
131	137
132	138	Commit messages
133	139	~~~~~~~~~~~~~~~
...	...	@@ -150,6 +156,16 @@ number must be referenced in the commit message.
150	156
151	157	Fixes #123
152	158
	159	+Note that the 'why' of a change is as important as the 'what'.
	160	+
	161	+When reviewing this, folks can suggest better alternatives when they know the
	162	+'why'. Perhaps there are other ways to avoid an error when things are not
	163	+frobnicated.
	164	+
	165	+When folks modify this code, there may be uncertainty around whether the foos
	166	+should always be frobnicated. The comments, the commit message, and issue #123
	167	+should shed some light on that.
	168	+
153	169	In the case that you have a commit which necessarily modifies multiple
154	170	components, then the summary line should still mention generally what
155	171	changed (if possible), followed by a colon and a brief summary.

—
View it on GitLab.
You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.