libdivecomputer submodule hoot

[Dirk Hohndel]

On Thu, Apr 05, 2018 at 04:57:23PM +0200, Robert Helling wrote:
> 
> please excuse my ignorance but I did not really follow the discussion around making libdivecomputer a submodule.
> 
> Could somebody please summarise for my what I am supposed to do assuming I don’t touch libdivecomputer code?

The build scripts should take care of this, but of course most developers
don't use those :-)

Fundamentally what you should do is pull Subsurface. And then do 

git submodule update

which makes sure that you get a matching libdivecomputer

> Because what happened is that more than once I managed (by doing commit -as) to include chunk from libdivecomputer with some reference to a commit in my own commit (possibly by rebasing what I had onto recent master). I assume I am not supposed to commit that. Do I have to make sure manually not to include it (using git add -p rather than commit -a)? What is the supposed work flow?
> 
> Even worse, in my PR https://github.com/Subsurface-divelog/subsurface/pull/1154 <https://github.com/Subsurface-divelog/subsurface/pull/1154> it seems I also have updates to libdivecomputer (unintentionally, didn’t touch). I guess the travis build failures are related to that but also me confusion here prevented me to finally merge this into master so I missed the cut for 4.7.8 (and yes, it introduces a string).

My guess is that this is because of the way you rebase. What's your
workflow for that? Technically the "git submodule update" after a rebase
should take care of that, but it's possible that you run into a weird
cornercase that I haven't thought through, depending on how you do that.
Can you post your workflow?

/D