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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
