wxpyimgview: explicit conversion to int (OSGeo#2704)

CHANGES

@@ -1,5 +1,6 @@
 <<<<<<< HEAD
 <<<<<<< HEAD
+<<<<<<< HEAD
 CHANGES in GRASS GIS 8.x
 =======
 CHANGES in GRASS GIS 8.x compared to GRASS GIS 7.x
@@ -27,6 +28,15 @@ https://trac.osgeo.org/grass/wiki/Grass8/NewFeatures82
 
 List of releases:
 
+=======
+CHANGES in GRASS GIS 8.x
+
+https://trac.osgeo.org/grass/wiki/Grass8/NewFeatures80
+https://trac.osgeo.org/grass/wiki/Grass8/NewFeatures82
+
+List of releases:
+
+>>>>>>> 6cf60c76a4 (wxpyimgview: explicit conversion to int (#2704))
 - GitHub list: https://github.com/OSGeo/grass/releases
 - Overview list: https://trac.osgeo.org/grass/wiki/Release
 - History: https://grass.osgeo.org/home/history/releases/ (starting 1984!)

CONTRIBUTING.md

@@ -1,24 +1,3 @@
-# Introduction
-
-GRASS GIS is written in more than one programming language. While most
-of the source code is written in C, about 30% is written in Python. A
-compiler is needed to convert the C/C++ source code into executable
-files ("binaries"). In contrast, Python is an interpreted language that
-can only be executed with Python software.
-
-Now, in order to create an installable binary package from a source
-code package, the so-called "compilation step" is required. While the
-source code consists of thousands of C and Python files (plus HTML
-documentation), the included "makefiles" tell the build system to
-generate binaries from the source code in the correct order, render the
-manual pages, etc.
-
-The way to install the compiler tools and Python depends on the operating
-system. To make this easier, we have collected copy-paste instructions
-for most operating systems in our wiki:
-
-[Compile and install instructions](https://grasswiki.osgeo.org/wiki/Compile_and_Install)
-
 # Contributing
 
 There is more than one way of contributing to GRASS GIS.
@@ -36,6 +15,143 @@ leads you through a first time setup and shows how to create a pull request.
 To contribute effectively, please familiarize yourself with our
 [Programming Style Guide](./doc/development/style_guide.md).
 
+<<<<<<< HEAD
+=======
+### First time setup
+
+* Create an account on GitHub.
+* Install Git on your computer.
+* Set up Git with your name and email.
+* Fork the repository (by clicking the `Fork` button in the upper right corner
+  of the GitHub interface).
+* Clone your fork (use HTTPS or SSH URL, here we will use HTTPS):
+
+```bash
+git clone git@github.com:your_GH_account/grass.git
+```
+
+* Enter the directory
+
+```bash
+cd grass/
+```
+
+* Add main GRASS GIS repository as "upstream" (use HTTPS URL):
+
+```bash
+git remote add upstream https://github.com/OSGeo/grass
+```
+
+* Your remotes now should be "origin" which is your fork and "upstream" which
+  is this main GRASS GIS repository. You can confirm that using:
+
+```bash
+git remote -v
+```
+
+* You should see something like:
+
+```bash
+origin  git@github.com:your_GH_account/grass.git (fetch)
+origin  git@github.com:your_GH_account/grass.git (push)
+```
+
+For the following workflow, it is important that
+"upstream" points to the OSGeo/grass repository
+and "origin" to your fork
+(although generally, the naming is up to you).
+
+### Update before creating a feature branch
+
+* Make sure your are using the _main_ branch to create the new branch:
+
+```bash
+git checkout main
+```
+
+* Download updates from all branches from the _upstream_ remote:
+
+```bash
+git fetch upstream
+```
+
+* Update your local _main_ branch to match the _main_ branch
+  in the _upstream_ repository:
+
+```bash
+git rebase upstream/main
+```
+
+Notably, you should not make commits to your local main branch,
+so the above is then just a simple update (and no actual
+rebase or merge happens).
+
+### Update if you have local changes
+
+If `rebase` fails with "error: cannot rebase: You have unstaged changes...",
+then move your uncommitted local changes to "stash" using:
+
+```bash
+git stash
+```
+
+* Now you can rebase:
+
+```bash
+git rebase upstream/main
+```
+
+* Get the changes back from stash:
+
+```bash
+git stash pop
+```
+
+### Creating a new feature branch
+
+Now you have updated your local _main_ branch, you can create a feature branch
+based on it.
+
+* Create a new feature branch and switch to it:
+
+```bash
+git checkout -b new-feature
+```
+
+### Making changes
+
+You can use your favorite tools to change source code or other files
+<<<<<<< HEAD
+in the local copy of the code. When making changes, please follow the
+[Programming Style Guide](./doc/development/style_guide.md).
+
+>>>>>>> ebc6d3f683 (wxpyimgview: explicit conversion to int (#2704))
+### Testing changes
+
+Testing helps to ensure that the changes work well with the rest
+of the project. While there are many different ways to test,
+usually you will want to compile the source code (see below),
+add test code (using _grass.gunittest_ or pytest), and run code
+linters (automated code quality checks).
+
+There is a series of automated checks which will run on your pull request
+after you create one. You don't need to run all these
+checks locally and, indeed, some of them may fail for your code. This is a part of
+the standard iterative process of integrating changes into the main code,
+so if that happens, just see the error messages, go back to your code
+and try again. If you are not sure what to do, let others know in a pull
+request comment.
+
+Note that there are some steps you can do locally to improve your code.
+For Python, run `black .` to apply standardized formatting. You can
+also run linter tools such as Pylint which will suggest different improvements
+to your code.
+=======
+in the local copy of the code. When making changes, please follow
+Submitting Guidelines at
+<http://trac.osgeo.org/grass/wiki/Submitting>.
+>>>>>>> 6cf60c76a4 (wxpyimgview: explicit conversion to int (#2704))
+
 ### Testing changes
 
 Testing helps to ensure that the changes work well with the rest