"Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone."
What is it that you feel is lacking? Because I have done similar things, depending on how you frame the issue. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> 2017-09-07 19:26 GMT+02:00 David Quintana (gigaherz) <gigah...@gmail.com>: > Suggestion for modules: cmake properties (and default value): > DISABLE_ROSTESTS:bool=false ENABLE_ROSAPPS:bool=false > > Since we can call cmake with -DENABLE_ROSAPPS:bool=true in the > commandline, to override the default, it's easy to toggle. > > As for other modules: > > - Documentation deserves its own repository, at github.com/reactos/ > documentation, where people can more easily contribute documentation > separately from code. > - Rossubsys: I'd extract them into some git repository at like > git.reactos.org/rossubsys.git, for anyone who wants to access them > historically, but I wouldn't bother making a github repository for them. > - Wallpapers: Would be nice to have a community website where people > can submit wallpapers, themes, cursors, icons, ... and the "staff picks" > can get copied into modules/wallpapers and included in releases. > > > > > > On 7 September 2017 at 19:17, Colin Finck <co...@reactos.org> wrote: > >> Hi all! >> >> As you know, we have to give up our "modules" directory concept when >> switching to Git, because Git doesn't support checking out an arbitrary >> directory into a subdirectory of a Git clone. >> Therefore, the first commit to the migrated repository will make the >> "reactos" directory the new root and move "rosapps" and "rostests" >> permanently into "modules". We can then introduce an environment >> variable/CMake variable/something else to enable or disable building of >> them on demand (suggestions are welcome!) >> >> But what will happen to the remaining directories in /trunk, namely >> "documentation", "rossubsys", and "wallpapers"? >> >> * Commits to "documentation" never had a relation to "reactos" commits, >> so nothing is lost if we put that directory into a separate repo >> "documentation.git" and remove all traces to it from the history of >> "reactos.git". I'd go this way if there are no objections. >> >> * I don't get the idea of that "rossubsys" directory created in 2014.. >> These subsystems are all stubs, never built with modern ReactOS, and no >> work has happened since "reviving" them. I would just go and remove them >> again. You can always find them in our repository history. >> >> * The "wallpapers" directory is a harder candidate. >> On the one hand, we don't want to bloat our ReactOS builds by including >> wallpapers in every build. Also the number of wallpapers may increase in >> the future, which could bloat the "reactos.git" repo even more. >> On the other hand, the wallpapers have always accompanied our release >> branches, so there is a value of having them tracked next to our code. >> >> I could put them in a separate repository "wallpapers.git" now and remove >> all traces to them in the "reactos.git" repo. But then again, how are they >> picked up by the build process in the future if we can't check them out >> into a subdirectory of "modules"? >> Another alternative is moving them to "modules/wallpapers_disabled". Then >> they are not picked up by the build process until they are renamed to >> "modules/wallpapers" for releases. >> >> What are your opinions on this? >> >> >> Cheers, >> >> Colin >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
