> Right now I am checking out each and every repo one at a time. Yes, we > could stash OS-specific scripts some place. > > I was hoping to start at the Apache Commons Proper level. If I need a > script to update each submodule to the latest HEAD, then this is less > elegant but understandable from a git POV. > > Maybe there is a git shorthand for this...
Sounds like a maven-plugin is better for doing this... Gary Gregory <garydgreg...@gmail.com> 于2020年8月31日周一 下午10:03写道： > On Mon, Aug 31, 2020 at 9:59 AM Xeno Amess <xenoam...@gmail.com> wrote: > > > BTW. > > From my own view, we might need a testing maven project (or a github > repo), > > for ensuring all commons repos can be used together, free of dependency > > hell, or other internal errors about using different versions of a same > > dependency. > > > > This is not my goal at all here. If that's a goal for you, please see > https://gump.apache.org/ > > Gary > > > > But I admit that will really be a time-costing work, and be really hard. > > I don't know if we can achieve it by adding the "proper" repo and add a > > module pom at base folder, and adding some tests... > > Just, I think it useful. > > > > > > John Patrick <nhoj.patr...@gmail.com> 于2020年8月31日周一 下午9:51写道： > > > > > On Mon, 31 Aug 2020 at 14:16, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > > > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker <boa...@gmail.com> > wrote: > > > > > > > > > Git submodules are pointers to other git commits. Therefore, any > > > component > > > > > changes made don’t affect the mono repo until you update said mono > > > repo to > > > > > point to the new commit. If you do this to point at the latest > > release > > > > > tags, this makes for less updates. Otherwise, you’ll want to figure > > > out a > > > > > CI system for automatically updating submodules to the latest > master > > > > > commits as they pass CI. > > > > > > > > > > > > > Can that commit be HEAD? > > > > > > Used git submodules loads 2010-2015, and not much since. But from > > > memory it can't be HEAD it has to be a specific commit hash. > > > > > > We had loads of issues when people worked on the sub modules > > > independently, it was easier when every worked with the parent git > > > module. But that was early 2010's so it might now allow HEAD or a > > > named branch say develop or master/main. > > > > > > We also had loads of maven warnings because we had a wrapper project > > > so from the git parent module it saw the submodules as maven modules. > > > But the git parent module maven pom wasn't the parent pom of the git > > > submodules maven pom. As parent automatically is > > > <relativePath>../pom.xml</relativePath> > > > > > > Our setup was; > > > > > > git-module > > > -> pom.xml (GAV project:maven-wrapper:1) > > > -> git-submodule-parent > > > --> pom.xml (GAV project:parent:1) > > > -> git-submodule-core > > > --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So > > > correct relative path is ../git-submodule-parent/poml.xml > > > > > > They had ~35 git submodules, not sure if they are still using > submodules. > > > > > > So it can be useful if you want to have component based git repo's but > > > it does add an extra overhead layer of maintenance and everyone needs > > > to be onboard from experience. > > > > > > John > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > On Mon, Aug 31, 2020 at 05:17 sebb <seb...@gmail.com> wrote: > > > > > > > > > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory < > garydgreg...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins < > chtom...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 30, 2020, at 9:44 AM, sebb <seb...@gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some questions: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - does it affect any existing usage? > > > > > > > > > > > > > > > i.e. can people continue to use the individual repos > exactly > > > as > > > > > > before > > > > > > > > > > > > > > > > > > > > > > > > > > > > no they can’t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes they can... this would be a new repo, and changes nothing > for > > > > > current > > > > > > > > > > > > > usage. This does not affect existing repos. > > > > > > > > > > > > > > > > > > > > > > > > What about my other queries? > > > > > > > > > > > > > > > > > > > > > > > > - changes to commit messages: > > > > > > > > > > > > can people commit to components directly from the new repo? > > > > > > > > > > > > If so, does that change the commit messages? > > > > > > > > > > > > > > > > > > > > > > > > - maintenance of the new repo: > > > > > > > > > > > > what is involved, and how will the project know when updates are > > > needed? > > > > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - does it affect Git emails in any way? > > > > > > > > > > > > > > > e.g. do they have different text? > > > > > > > > > > > > > > > > > > > > > > > > > > > > same emails > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - will it need much maintenance? > > > > > > > > > > > > > > > If so, how do we know when it needs updating? > > > > > > > > > > > > > > > > > > > > > > > > > > > > more maintainance, have to maintain a git hash at a symlink > > > pointing > > > > > > to an > > > > > > > > > > > > > > external repository > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory < > > > garydgreg...@gmail.com > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> Yes yes "girl" -> "git" > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory < > > > garydgreg...@gmail.com> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >>> I'm talking about girl's own submodules: > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> https://git-scm.com/docs/git-submodule > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> Gary > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins < > > chtom...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>>> By git submodules, are you talking about a symlink to > > > another > > > > > git > > > > > > > > > > > > > > >>>> repository inside one of our repositories? > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> -Rob > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>>> On Aug 29, 2020, at 6:52 PM, Gary Gregory < > > > > > > garydgreg...@gmail.com> > > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Hi All, > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Any thoughts for or against creating a new git > repository > > > which > > > > > > would > > > > > > > > > > > > > > >>>>> contain all 'proper' Commons components as git > > submodules? > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> The idea is to be able to checkout all of Commons > > 'proper' > > > in > > > > > > one go > > > > > > > > > > > > > > in > > > > > > > > > > > > > > >>>> one > > > > > > > > > > > > > > >>>>> place. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Gary > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > >>>> To unsubscribe, e-mail: > > dev-unsubscr...@commons.apache.org > > > > > > > > > > > > > > >>>> For additional commands, e-mail: > > > dev-h...@commons.apache.org > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > > > > > For additional commands, e-mail: > dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
