1 | ## Setting up your local git-repo
|
---|
2 |
|
---|
3 | ```shell
|
---|
4 | git clone https://github.com/floscher/josm-mapillary-plugin
|
---|
5 | cd josm-mapillary-plugin
|
---|
6 | git svn init --prefix=svn/ http://svn.openstreetmap.org/applications/editors/josm/plugins/mapillary #You have to use http://, _not_ https://
|
---|
7 | git config --local svn.authorsfile authors.txt
|
---|
8 | git svn fetch #this might take a while
|
---|
9 | ```
|
---|
10 |
|
---|
11 | ## Fetching from the SVN-repo into your local git-repo
|
---|
12 |
|
---|
13 | ```shell
|
---|
14 | git svn fetch
|
---|
15 | ```
|
---|
16 |
|
---|
17 | ## Building the plugin with Gradle
|
---|
18 |
|
---|
19 | This project uses the so-called Gradle wrapper. That means you have to install nothing on your machine in order
|
---|
20 | to build the project. The wrapper consists of the two scripts `gradlew` (for UNIX-based systems like Mac and Linux)
|
---|
21 | and `gradlew.bat` (for systems running Windows). The following examples shows the commands for Linux/Mac users,
|
---|
22 | Windows users can simply replace `./gradlew` with `./gradlew.bat`.
|
---|
23 |
|
---|
24 | For just building the jar-file for the plugin, run
|
---|
25 | ```shell
|
---|
26 | ./gradlew jar
|
---|
27 | ```
|
---|
28 |
|
---|
29 | If you also want to run the unit tests, create a FindBugs report and a code coverage report, then the following command is for you:
|
---|
30 | ```shell
|
---|
31 | ./gradlew build
|
---|
32 | ```
|
---|
33 | (look for the results in the directory `build/reports`)
|
---|
34 |
|
---|
35 | And finally if you have JOSM installed on your machine, you can execute the following to build the plugin from source,
|
---|
36 | installs it for you in JOSM and then even starts JOSM with the plugin loaded:
|
---|
37 | ```shell
|
---|
38 | ./gradlew runJosm
|
---|
39 | ```
|
---|
40 |
|
---|
41 | For info about other available tasks you can run
|
---|
42 | ```shell
|
---|
43 | ./gradlew tasks
|
---|
44 | ```
|
---|
45 |
|
---|
46 | ## Making changes to the repo and committing them back to SVN
|
---|
47 | The following steps are for those with commit-privileges for the SVN repository containing the plugins for JOSM.
|
---|
48 | All others can simply file pull requests against the master-branch on github.
|
---|
49 |
|
---|
50 | We recommend, that you start your development at the head of the master-branch in a separate branch (in this example
|
---|
51 | it's called _‹foo›_, you can name it what you like, but best call it after the feature you are working on):
|
---|
52 | ```shell
|
---|
53 | git checkout origin/master
|
---|
54 | git branch ‹foo›
|
---|
55 | ```
|
---|
56 |
|
---|
57 | ---
|
---|
58 |
|
---|
59 | Then commit your changes to this branch _‹foo›_ until you feel it's time for committing them back to SVN:
|
---|
60 | ```shell
|
---|
61 | git commit
|
---|
62 | ```
|
---|
63 |
|
---|
64 | ---
|
---|
65 |
|
---|
66 | If you want to commit all of the commits that you made on the _‹foo›_-branch back to SVN, then you can skip this step.
|
---|
67 |
|
---|
68 | Otherwise execute the following line to preserve the other commits:
|
---|
69 | ```shell
|
---|
70 | git branch tmp
|
---|
71 | ```
|
---|
72 | This creates a new branch called _tmp_ which saves those commits for later, which are not rebased.
|
---|
73 |
|
---|
74 | ---
|
---|
75 |
|
---|
76 | Then fetch the current state of the SVN-repository to avoid merge conflicts:
|
---|
77 | ```shell
|
---|
78 | git svn fetch
|
---|
79 | ```
|
---|
80 |
|
---|
81 | ---
|
---|
82 |
|
---|
83 | Now you should rebase onto the current state of the SVN-repository:
|
---|
84 | ```shell
|
---|
85 | git rebase --interactive svn/git-svn
|
---|
86 | ```
|
---|
87 | A text editor should open with all commits on the _‹foo›_-branch that are currently not in SVN. Delete all lines except
|
---|
88 | the ones containing those commits you want to commit to SVN.
|
---|
89 |
|
---|
90 | Watch the command line. If it says, that merge conflicts have occured you'll first have to resolve these conflicts.
|
---|
91 | For example with the following command:
|
---|
92 | ```shell
|
---|
93 | git mergetool --tool=‹name_of_your_mergetool›
|
---|
94 | ```
|
---|
95 | Possible mergetools include emerge, gvimdiff, kdiff3, meld, vimdiff and tortoisemerge.
|
---|
96 |
|
---|
97 | After merging you'll have to tell git that it should complete the rebasing:
|
---|
98 | ```shell
|
---|
99 | git rebase --continue
|
---|
100 | ```
|
---|
101 |
|
---|
102 | If it still says that there are merge conflicts, go back to the `git mergetool`-command and repeat the steps from there on.
|
---|
103 |
|
---|
104 | ---
|
---|
105 |
|
---|
106 | You have reached the final step, the following command will now interact with the SVN-server to commit your changes
|
---|
107 | to the SVN-repository:
|
---|
108 | ```shell
|
---|
109 | git svn dcommit --interactive --username=‹your_svn_username›
|
---|
110 | ```
|
---|
111 | This command will ask for your password and shows you the commit message of every git-commit before it
|
---|
112 | applies it to the SVN-repo.
|
---|
113 |
|
---|
114 | ---
|
---|
115 |
|
---|
116 | __Pro-tip:__
|
---|
117 |
|
---|
118 | If you want to use a different text-editor than git currently uses, execute the following command:
|
---|
119 | `git config --global core.editor ‹insert_your_favourite_text_editor›` and git will in the future always fire the new
|
---|
120 | editor up instead.
|
---|
121 |
|
---|
122 | The same applies for the merge-tool: After executing `git config --global merge.tool ‹insert_your_favourite_merge_tool›`
|
---|
123 | you can omit the --tool option when executing `git mergetool` in the future.
|
---|