From a0ca5ffe70e41b57a36f568dc1d41df79313f78c Mon Sep 17 00:00:00 2001 From: Orestis Floros Date: Sat, 2 May 2020 12:51:17 +0200 Subject: [PATCH] hacking-howto: Update git section This still had some leftovers from the patch era. Since git and specifically GitHub-like developing is much more mainstream now we don't need to link introductions or even mention the idea of "patching". The deleted "them" was referencing an old sentence referring to patches, generated by the git cli. As emailing patches is not common at all for GitHub repos, I removed the sentence altogether. Also simplifies the 'branches' subsection a bit. Asking people to verify their patch on master seems too much preliminary work and I doubt that anyone does it anyway. --- docs/hacking-howto | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/docs/hacking-howto b/docs/hacking-howto index 6d8092b5..cf812069 100644 --- a/docs/hacking-howto +++ b/docs/hacking-howto @@ -48,29 +48,21 @@ tarball, but shouldn’t hurt either. * Coverage reports are now generated using +make check-code-coverage+, which requires specifying +--enable-code-coverage+ when calling configure. -== Using git / sending patches - -For a short introduction into using git, see -https://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy -or, for more documentation, see https://git-scm.com/documentation +== Pull requests Please talk to us before working on new features to see whether they will be accepted. A good way for this is to open an issue and asking for opinions on it. -Even for accepted features, this can be a good way to refine an idea upfront. However, -we don't want to see certain features in i3, e.g., switching window focus in an -Alt+Tab like way. +Even for accepted features, this can be a good way to refine an idea upfront. +However, we don't want to see certain features in i3, e.g., switching window +focus in an Alt+Tab like way. -When working on bugfixes, please make sure you mention that you are working on -it in the corresponding bug report at https://github.com/i3/i3/issues. In case -there is no bug report yet, please create one. +When working on bugfixes, please make sure you mention that you are working on it +in the corresponding bug report at https://github.com/i3/i3/issues. In case there +is no bug report yet, please create one. After you are done, please submit your work for review as a pull request at -https://github.com/i3/i3. - -Do not send emails to the mailing list or any author directly, and don’t submit -them in the bugtracker, since all reviews should be done in public at -https://github.com/i3/i3. In order to make your review go as fast as possible, you -could have a look at previous reviews and see what the common mistakes are. +https://github.com/i3/i3. In order to make your review go as fast as possible, +you could have a look at previous reviews and see what the common mistakes are. === Which branch to use? @@ -81,9 +73,8 @@ repository). The contents of “master” are always stable. That is, it contains the source code of the latest release, plus any bugfixes that were applied since that release. -New features are only found in the “next” branch. Therefore, if you are working -on a new feature, use the “next” branch. If you are working on a bugfix, use the -“next” branch, too, but make sure your code also works on “master”. +New features are only found in the “next” branch. Always use this branch when +writing new code (both bugfixes and features). == Window Managers