Sounds good to me. Mike
On Tue, May 15, 2018 at 3:50 PM Aaron Coburn <[email protected]> wrote: > Andy, > > You make an excellent point here. It does seem that using a .gitignore > file would be best. > > -Aaron > > > On May 15, 2018, at 12:18 PM, Andy Kurth <[email protected]> wrote: > > > > I respectfully disagree and think this solution is cleaner: > > > >> http://stackoverflow.com/a/932982 > > > > > > To paraphrase the solution linked above so that it is saved in the > mailing > > list archives: > > > > Commit a *.gitignore* file in each empty directory containing: > > > >> * > >> !.gitignore > > > > > > The .gitignore file is special in that it instructs git to ignore any > other > > files which will reside in the directory. The first line tells git to > > ignore all files in the directory, including files that may be located in > > subdirectories. The second line tells git *not *to ignore the > .gitignore file > > itself. Comments could be added to explain things about the directory. > > > > .gitignore serves the same purpose as setting Subversion's *svn:ignore* > > property. This property was set on all the missing directories prior to > > migrating to git. > > > > Regardless of whether a .gitkeep or some other file exists, a .gitignore > > file will still be needed because the purpose of all of the missing/empty > > directories is for adding custom files that should be ignored by git. > > Sure, a top-level .gitignore could be configured with lines/patterns to > > match the missing/empty lower level directories, but I think it's easier > to > > maintain a simple and consistent .gitignore into each empty directory to > be > > retained. Committing the file and configuring it appropriately kills 2 > > birds with 1 text file. > > > > On a related note... > > In addition to adding the empty directories, the backend code needs some > > minor tweaks. *OS.pm::run_stage_scripts_on_computer* will currently > > attempt to copy and then execute any file it finds under a directory such > > as: > > /usr/local/vcl/tools/Linux/Scripts/post_load/.gitwhatever > > > > Trying to execute something like .gitwhatever won't fail the reservation > > but causes delays and unnecessary warnings in vcld.log. > > > > There is already an exception in > > *ManagementNode.pm::run_stage_scripts_on_management_node *to ignore > > anything that contains ".svn" or ".git": > > > >> if ($script_file_path =~ /\/(\.svn|\.git)\//i) { > >> ... > >> next; > >> } > > > > > > *run_stage_scripts_on_computer *and > > *run_stage_scripts_on_management_node* should > > be aligned so they ignore the same things. Perhaps they should ignore > > anything beginning with a period? *OS.pm::get_tools_file_paths* and > > anything else that attempts to search for things under the tools > directory > > should also be examined, although I'd be careful to not filter out too > much > > from upstream subroutines. > > > > -Andy > > > > > > On Tue, May 15, 2018 at 9:56 AM, Josh Thompson <[email protected]> > > wrote: > > > >> I agree on the .gitkeep name and the text Henry suggested. > >> > >> Josh > >> > >> On Tuesday, May 15, 2018 9:17:38 AM EDT Mike Jennings wrote: > >>> I like the idea of the .gitkeep that seems to be short and straight > >>> forward. I am also going to put the text provided by Henry into the > file > >>> so that there will be some context associated with it. > >>> > >>> Thanks for the feedback. > >>> > >>> Mike Jennings > >>> > >>> On Tue, May 15, 2018 at 9:08 AM Aaron Coburn <[email protected]> > >> wrote: > >>>> The pattern that I've seen elsewhere is to place a .gitkeep file in > the > >>>> otherwise empty directory. > >>>> > >>>> In principle, this file could have any name, and while I've also > >>>> repositories use .gitignore for this purpose, I agree with Mike that > >> this > >>>> isn't really to the point. > >>>> > >>>> By using the .gitkeep name, it signals to developers that the file is > >>>> related to git metadata rather than application code. > >>>> > >>>> Regards, > >>>> Aaron > >>>> > >>>>> On May 14, 2018, at 6:03 PM, Henry Schaffer <[email protected]> wrote: > >>>>> > >>>>> IMHO the name should inform a person who sees it (a developer or > >> user - > >>>>> whoever) that it's not for them. So a name like .empty or .ignore is > >>>>> helpful. But it would be nice to give more info - it could be done > >> via a > >>>>> longer name, or perhaps there could be a brief explanation in the > >> file > >>>>> along the lines ot > >>>>> > >>>>> The purpose of this file is to keep this directory from being empty > >> so > >>>> > >>>> the > >>>> > >>>>> directory will be retained in the git repository. The directory is > >> used > >>>> > >>>> by > >>>> > >>>>> the backend code for some scripts used during provisioning, and so > >> needs > >>>> > >>>> to > >>>> > >>>>> be retained. > >>>>> > >>>>> --henry > >>>>> > >>>>> On Mon, May 14, 2018 at 4:39 PM, Mike Jennings <[email protected]> > >>>> > >>>> wrote: > >>>>>> There are a number of empty directories under the backend code that > >> are > >>>>>> used for placing scripts that automatically get executed during > >> certain > >>>>>> provisioning stages > >>>>>> > >>>>>> We plan on putting a empty file in each of these directories so that > >>>>>> the > >>>>>> directory structure will be persisted to the git repository. > >>>>>> > >>>>>> The current thought is to use something like ".empty" as the file > >> name > >>>> > >>>> to > >>>> > >>>>>> commit to the repository, then have this file ignored in the > >> management > >>>>>> node code. > >>>>>> > >>>>>> We could also use the ".gitignore" file, but this is really not > >> what we > >>>> > >>>> are > >>>> > >>>>>> trying to accomplish here. > >>>>>> > >>>>>> Does anyone have thoughts on what a preferred way to do this would > >> be. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Mike Jennings > >> > >> > >> -- > >> ------------------------------- > >> Josh Thompson > >> Systems Programmer > >> Virtual Computing Lab (VCL) > >> North Carolina State University > >> > >> [email protected] > >> 919-515-5323 > >> > >> my GPG/PGP key can be found at www.keyserver.net > >> > >> All electronic mail messages in connection with State business which > >> are sent to or received by this account are subject to the NC Public > >> Records Law and may be disclosed to third parties. > > > > > > > > > > -- > > *Andy Kurth* > > Research Storage Specialist > > NC State University > > Office of Information Technology > > > > P: 919-513-4090 > > 311A Hillsborough Building > > Campus Box 7109 > > Raleigh, NC 27695 > >
