Be smarter about dive renumbering when merging dives

We really have two different cases for merging dives:

 (a) downloading a new dive from a dive computer, and merging it with an
     existing dive that we had already created using a different dive
     computer.  This is the "try_to_merge()" case, called from
     "process_dives()

 (b) merging two different dives into one longer dive.  This is the
     "merge_two_dives()" case when you explicitly merge dives using the
     divelist.

While a lot of the issues are the same, many details differ, and one of
the details is how dive numbering should be handled.

In particular, when you download from a dive computer and merge with an
existing dive, you want too take the *maximum* dive number, because the
dive computer notion of which dive it is may well not match what the
user dive number is.

On the other hand, when you explicitly merge in the dive list, you end
up renumbering not just the dive you are merging, but also all
subsequent dives, since you now have one fewer dives overall.  So that
case already has to be handled by the caller.

Now, the simpler "download from dive computer" case was broken by commit
ce3a78efcac2 ("Assign lower number to a merged dive instead of higher
one").  It fixed the numbering for the divelist case, but broke the
download case.

So this commit reverts commit ce3a78efcac2, and instead extends and
clarifies the dive renumbering that "merge_two_dives()" already did.  It
now explicitly renumbers not just the following dives, but also
renumbers the merged dive itself, so now we can go back to the old "take
the bigger dive number" for the core merging, which fixes the download
case.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>

0 files changed, 0 insertions, 0 deletions