vcl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Coburn <acob...@amherst.edu>
Subject Re: [VCL-1097] add hidden files to empty directories to force them to be included in Git repo
Date Tue, 15 May 2018 19:50:24 GMT
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 <andy_kurth@ncsu.edu> 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 <josh_thompson@ncsu.edu>
> 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 <acoburn@amherst.edu>
>> 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 <hes@ncsu.edu> 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 <gmjennin@ncsu.edu>
>>>> 
>>>> 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
>> 
>> Josh_Thompson@ncsu.edu
>> 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


Mime
View raw message