Jump to content

Help define canonical LabVIEW.gitignore template for GitHub


Recommended Posts

While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one!

 

After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.

 

So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore

 

Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.

 

Here's the contents of the file right now:

 

How can this be improved?
Link to comment
*/build/* << This is perhaps too specific to your strategy for build artifact output folders; for instance, my personal hgignore contains builds/* and similarly deployments/*

.DS_Store << I like this

Thumbs.db << I like this

.dll << No; I currently have third-party libraries checked into SCC

.so << Not sure; but could have same argument as .dll

.out << Not sure; but could have same argument as .dll

 

Annotated within the quote

Link to comment

I don't use Git either, but I expect the only LabVIEW specific files that should be ignored are those listed in the original post. I also like Shaun's idea to ignore the various OS-specific database caches.

 

I agree with Jack about not excluding binaries. Some of my LabVIEW source code directly calls binaries that I've created in C++/C#. The C source is not part of these packages rather they just include the binaries that are produced from another package.

Link to comment
I don't use Git either, but I expect the only LabVIEW specific files that should be ignored are those listed in the original post. I also like Shaun's idea to ignore the various OS-specific database caches.

 

I agree with Jack about not excluding binaries. Some of my LabVIEW source code directly calls binaries that I've created in C++/C#. The C source is not part of these packages rather they just include the binaries that are produced from another package.

Perhaps it is because I also maintain the binaries (generally). These are usually under a separate repository and pulled in when needed (not as easy in Git as SVN) so that up issuing them doesn't require up issuing of the labview source (separate tree).

Probably more my workflow so perhaps not a good idea as a generic.

Link to comment
I don't use Git, but I assume .gitignore is similar to .hgignore.  How is the canonical .gitignore file used in practice?  Doesn't Git have a system-wide ignore file?

 

Yes; and this question prompted further digging and inspection of other gitignores in the repo, and the README.md has this information: "Global gitignores (OS-specific, editor-specific) should go into the Global/ directory." OS-specific includes .DS_Store and Thumbs.db, and something like */build/* would be considered editor-specific.

 

So; for now, we're back to the original with just .aliases and .lvlps.

 

For those using Hg: what do your .hgignore's look like?

Link to comment

I have the following global HG workbench file (Mercurial itself doesn't support a global hgignore):

 

.ogp$
/built*$
/build*$
.lvlps$
.aliases$
.viobj
.vip$
.zip$
 
Based on this Which files to ignore using SCC, and the LabVIEW Wiki and my strong belief that build products do not belong in an SCC.
 
Ton

 

Thanks for linking conversations to substantiate! Here's commentary:

 

For the same reason I would not include DLL and other library exclusions from gitignore, I would not add an exclusion for ZIP, VIP, and OGP (since they can be dependencies as part of a distributable application -- e.g., they can be but are not necessarily 'end products'). And as for /built*$ and /build*$, the same conversation applies from Shaun's suggestions -- these are better placed in individual developer's Global ignore.

 

But you're onto something with the .viobj -- are there instances where this can end up in the source directory?? Or is this a throwback to the early days when there was discussion if viobj would be stored locally with the source or in a global cache (spoiler: the global cache idea won out -- *i think* -- yet if there remain some cases where viobj is stored in the source dir, that's a great reason to include viobj in the default gitignore)

Link to comment
.hgignore

 

Can you explain this one? And for clarity; this is for the .hgignore checked into your repo root or the global? Ignoring the ignore file.... I can see where this is desirable, but not necessarily the norm.

 

 

 

.lvbitx

 

I'm not well-versed enough in the FPGA domain to make a decision -- but would you say for the same reason as DLLs etc, it may be desirable to check this into SCC if it's part of an RT distro, and therefore not a good candidate for the baseline .gitignore?

Link to comment
Can you explain this one? And for clarity; this is for the .hgignore checked into your repo root or the global? Ignoring the ignore file.... I can see where this is desirable, but not necessarily the norm.

 

First, the listing is just an example of what my .hgignore looks like.  I wasn't suggesting it should be part of a baseline template.

 

That particular listing is from a repro root.  My global ignore just has the .aliases and .lvlps files listed.

 

 

I'm not well-versed enough in the FPGA domain to make a decision -- but would you say for the same reason as DLLs etc, it may be desirable to check this into SCC if it's part of an RT distro, and therefore not a good candidate for the baseline .gitignore?

 

I think the .lvbitx files are more like .viobj files.  They get generated every time the fpga code compiles, sometimes with different names.  I don't know how LV decides if the name needs to be changed, but in my recent struggles it wasn't uncommon for me to end up with multiple bit files generated from the same vi.

 

What kind of baseline are you looking for, files that everyone wants to ignore all the time or files that most people want to ignore most of the time?  In Hg the ignore file lists those files that will not be added automatically.  You can still select and add them manually if desired.  I'd put bit files in the same category as executables--if it does get added to the repository, it's probably only checked in at very stable points.

 

Also, here's a link to instructions on how to set a global ignore file, and another link to the hgignore file help docs.

Link to comment
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.