On Mon, Jun 12, 2017 at 9:20 PM, David Cerutti <dscerutti.gmail.com> wrote:
> I've updated the pmwiki with some tips from my experience. Should we steer
> people who have older branches from before the submodules to create new
> branches from master that are submodule oriented, then merge in their
> progress from the older branches? Seems logical to me, to avoid the risks
> that seem to go along with deinit --all.
deinit --all is not risky -- it doesn't let you delete submodules with
untracked content or uncommitted changes. If you haven't pushed those
changes upstream (but *have* committed them), there's a risk in deinit, but
there are analogous risks in the non-submodule model as well. There's not
much functional or semantic difference between what you propose and what's
described in the Wiki (and there's a video at the end that describes how to
merge).
You encounter the same conflicts either way and their resolution is done
the same way. So it's really 6 of one, half-dozen of another.
(Wouldn't things that have since
> been made into submodules have issues updating in non-submodule branches?)
>
Not sure I follow here. If you make changes in a submodule, you need to
push those changes up to the upstream repo (typically on GitHub for
AmberTools projects in submodules). In that case, those changes are there
whenever you switch back to the branch that has the submodule. All you
lose is the ability to merge those changes into any changes you made in the
branch where that code is *not* in a submodule. But if you made changes to
code that was moved to a submodule (ParmEd, cpptraj, or pytraj), you need
to port those changes to a checkout of the upstream repo (either in the
submodule or a standalone clone) no matter how you slice it.
All the best,
Jason
--
Jason M. Swails
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Jun 12 2017 - 19:00:02 PDT
