nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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.
This commit is contained in:
Orestis Floros 2020-05-02 12:51:17 +02:00
parent 4f0a93c3d9
commit a0ca5ffe70
No known key found for this signature in database
GPG Key ID: A09DBD7D3222C1C3
1 changed files with 11 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
docs/hacking-howto
View File

@ -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