explain that photos are useful [ready for review]

[matkoniecz]

During testing it turned out that people were strongly underestimating usefulness of photos in notes for other mappers. This attempts to counteract this.

Note that text field is poor - I want it at once to use as much as horizontal space as possible and prefer to use vertical spa and make it work independent of a text length (translations). I am unsure how to solve this and created PR to check whatever solution is obvious.

[westnordost]

Does the wording "report" appear at some other place? I'd expect "note".

[matkoniecz]

I now used @rugk tip also here, text is now a placeholder of recycler view what removes most problems. It allows to mention a bit more (address plaques part is based on my experience with remote editing based on SC notes), but maybe just short hint that notes are useful should be added...

[matkoniecz]

BTW, is there some reason why you merge rather than squashing commits? (I am a bit curious why because I usually merge & squash with intention of making more readable history - and I wonder is there some reason to do it other way)

[matkoniecz]

And thanks for reviewing pull request so well and quickly! I was prepared to wait a long time for review and I think that once again no pull request is ready for a review!

[westnordost]

BTW, is there some reason why you merge rather than squashing commits?

I do not like squash because it rewrites the history. Merge keeps it as it happened. As your commits are pretty good quality (also compared to mine... ;-) ) in that they are quite atomic and descriptive, I find it makes the history actually more readable.

[westnordost]

In that regard, I like the approach of Fossil SCM better than Git:

Git puts a lot of emphasis on maintaining a "clean" check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. And branches are often rebased before being pushed, to make it appear as if development had been linear. Git strives to record what the development of a project should have looked like had there been no mistakes.

Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. One might argue that this makes the history of a Fossil project "messy". But another point of view is that this makes the history "accurate". In actual practice, the superior reporting tools available in Fossil mean that the added "mess" is not a factor.

One commentator has mused that Git records history according to the victors, whereas Fossil records history as it actually happened.

https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

[matkoniecz]

As your commits are pretty good quality

Nice to hear it :)

One commentator has mused that Git records history according to the victors, whereas Fossil records history as it actually happened.

That is a good summary. Now I think that I often treat squashing as "now I am victorious, and I overcome all that mistakes, dead ends and typos" ritual.