Is there any way to ignore gitignore rules but still check in the .gitignore file? Or maybe we should use a different implementation?
This is not a question about how to apply gitignore rules or "why my rule doesn't work correctly".
We are trying to create templates for our users, which will include 1) a folder that initially exists but will be automatically updated 2) a .gitignore file that has some rules. There is also some logic that copies the whole template folder to the users machine, including both the files mentioned above.
We want to check in the .gitignore file, but we don't want the rules to be applied to our own repo.
The template folder would look like this:
-template
-generated
-a.file
-.gitignore
The .gitignore looks something like:
...
**/generated
...
We want the user to ignore their changes to 'a.file' but we don't want to ignore it for ourselves.
Is there a good way to just ignore the rules, or the better practice is to use a different implementation?
(Apologize if the description is terriblly hard to understand.)
Perhaps you could comment out the rules in your repo. Then, on the user's machine, your script could uncomment these lines.
Otherwise, it is possible to check in files that are in your git-ignore file, you just have to be specific about it.
A simpler solution would be to:
ignore a.file (adding that rule in .gitignore)
but force adding changes when you are in your repository (git add -f a.file would still add changes, even if the file is ignored)
From GIT, they provide a solution to overcome such issues
You can also define personal ignore patterns for a particular repository in a special file at .git/info/exclude. These are not versioned, and not distributed with your repository, so it's an appropriate place to include patterns that will likely only benefit you.
I have never come across any feature where you can ignore the rules or exclude after adding them .gitignore, just you can have changes limited to your repository by maintaining .git/info/exclude file
Maybe this link would be helpful https://gist.github.com/hieblmedia/9318457
and you can maintain rules specific to your repo in .git/info/exclude.
Related
I have a library of code on Github but I don't want someone to accidentally edit them so I installed .gitignore to prevent others from editing them. But it doesn't prevent editing, it just prevents others from adding files.
A .gitignore file doesn't prevent changes to files, and it has no effect on files that are already tracked by Git. The Git FAQ is very clear that there's no way to ignore changes to tracked files. The FAQ explains alternatives for common situations, and why suggestions to use git update-index for that purpose don't work.
Even if you could do that, a user could just copy the files elsewhere and edit them and then add them back using one of the plumbing commands. Once someone has the code, they're able to edit it in whatever way they want; if you don't want them to modify the files, then either don't distribute them, or distribute them only under a license that prevents them from making modifications.
I am currently creating a lot of small experimental game projects in Lua that include a framework written in C, which dominates the code percentages and declares my project as being in C when it is not.
I do however want to keep this framework, as it allows me to add on the playable version of the game.
I am partially familiar with the concept of removing language statistics on a file, but is there a way to omit a directory?
I have also seen most answers link to this answer but as I am new to github I don't quite know how to decipher it.
To ignore all files from a particular directory when computing statistics, you can use the following .gitattributes:
your/framework/directory/* linguist-vendored
If you think your framework is common enough through github.com, you can make a pull request to Linguist to add it to the list of ignored directories. That way, you won't need to ignore it on a per-repository basis.
This will ignore all the files in the given folder and subfolders from the stats.
linguist-vendored: This attribute helps us exclude files from stats.
In the .gitattributes file:
folder_to_ignore_files_from/** linguist-vendored
For e.g. I had a static_root folder in my root directory from which I wanted to ignore files from. So,
static_root/** linguist-vendored
I had created the .gitattributes in root directory.
Ref: link
Does the wiki that installs with a GitHub repo support directories? Our wiki is cluttered with pages, and we are looking for a way to organize them better.
We tried pulling the repo, creating local directories, and moving things around, but when committed back, the wiki didn't pick up the changes.
I was having the exact same issue and tried variants of what you tried. Nothing stuck. Asked GitHub support about it and received a reply that essentially said "No, but we'll let the developers know that people are interested in this feature."
So the short answer is "No", and the long answer is "No, but maybe in the future."
Actually, it looks like github added support for directories recently.
I was able to do the following:
Move an existing markdown file to a new directory.
Create a new markdown file in an existing directory (created in the former step).
Create a new markdown file in a new directory.
In all cases, the existing pages were still there and new pages were added.
The one constraint that remains is that your file names must be unique. If you have more than one file with the same name, only one of them will show up in the wiki (I'm not sure which.. ).
The GitHub wiki (aka Gollum) does use directories but not in the way you may expect.
The documentation on the Gollum wiki could use some work but this is what I have figured out mostly via testing.
All files appear in the root of the wiki no matter where they are placed in the repo.
_Header, _Footer and _Sidebar files are per-directory, but inherited if there is
none present in a child folder.
File links can be relative to the source file (keep your files with your content).
So, if you want directories for namespacing you are out of luck. Consider using the {namespace}-{page} scheme for namespacing.
It's not the an ideal solution but the workaround would be to create a custom sidebar where you create a table of contents with links to your pages. I find this to be better than folders anyway because it allows you to have a link to a single page under multiple hierarchies.
Actually, there is still a limitation. Yes, you can add 1 level (so, 1 subfolder). But that's it! I refactored my whole documentation layout, creating multiple levels of subfolders for organisation, but that was a no-go.
sigh
I must say: I'm appalled by this Gollum thing. I'm surprised Github even picked it up.
Well, that's a disappointing missing feature!
What I try to do is to actually have directories under a docs directory and in each one, a README.md file.
Not great...but works for documentation and organizes stuff.
If you want to go further, you can have a different branch only with these files.
Still no intention of adding this 9/2022.
https://github.com/orgs/community/discussions/23914
This is something I've never really understood about source control, specifically Subversion (the only source control I've ever used, which isn't saying much). I'm considering moving to git or Mercurial, so if that affects the answer to my question, please indicate as such.
Ok. As I understand it, every time I create a new file, I have to tell SVN about it, so that it knows to add it to the repository and place it under control. Something like:
svn add newfile
That's fine if I'm the one creating the file: I know I created it, I know its name, I know where it lives, so it's easy to tell SVN about it.
But now suppose I'm using a framework of some kind, like Rails, Django, Symfony, etc., and suppose I've already done the initial commit. All of these frameworks create new files programmatically, often many at once, in different directories, etc. etc. How do I tell the source control about these new files? Do I have to hunt each one of them down individually and add them? Is there an easier way? (Or am I possibly misunderstanding something fundamental about source control?)
Generally speaking, you shouldn't add files to source control if they can be generated from other files in your project. It's true that in some cases, a file is initially generated, but must be modified manually. In that case you will have to add it to source control. However, you should almost never automatically add files.
I agree with Matthew in general, if it can be generated it shouldn't be added but remain dynamically created.
For the practical question of adding multiple files, I don't remember in svn (though I think it should be possible), but to do this in git:
Using git bash (command line) you can add all "loose" files under the directory or subdirectory by not specifying a file after the add command. You can also set git to ignore certain files, so they wont be added in that case.
Another way is using git gui, it displays all un-tracked files and you can select them all (or groups of it) and add them in one click.
I've been all over google and SO looking for someone who has asked this question, but am coming up completely empty. I'll apologize in advance for the lengthy round-about way of asking the question. (If I was able to figure out how to encapsulate the problem, maybe I would have been successful in finding an answer.)
How are large projects managed in Mercurial, when the act of building / compiling generates hundreds of temporary files in order to create the end result?? Is .hgignore the only answer?
Example Scenario:
You have a project that wants to use some open source package for some feature, and needs to compile from source. So you go get the package. un-.tgz it and then slap it into its own Mercurial repository so you can then start tracking changes. Then you make all your changes, and run a build.
You test your end result, are happy with the results and are ready to commit back to your local clone of the repository. So you do an hg status to check your changes prior to committing The hg status results cause you to immediately start using all those words that would make your mother ashamed — because you now have screens and screens of "build cruft".
For the sake of argument say this package is MySQL or Apache: something that
you don't control and will be changing regularly,
leaves a whole lot of cruft behind in a whole lot of places, and
there is no guarantee the cruft won't change each time you get a new version from the external source.
Wow what? The particular project causing this angst is going to be worked on by multiple developers in multiple physical locations, and so needs to be as straightforward as possible. If there is too much involved they're not going to do it, and we'll have a bigger problem on our hands. (Sadly, some old dogs are not keen on learning new tricks...)
One proposed solution was that they would just have to commit everything locally before doing a make, so they have a "clean slate" they would then have to clone from to actually do the build in. That got shot down as (a) too many steps, and (b) not wanting to cruft up the history with a bunch of "time to build now" changesets.
Someone else has proposed that all the cruft just be committed into the Mercurial repository. I am strongly against that because then the next time around those files will turn up as "modified" and therefore be included in the changeset's file list.
We can't possibly be the only people who have run into this problem. So what is the "right" solution? Is our only recourse to try create a massively intelligent .hginore file? This makes me uneasy, because if I tell Mercurial to "ignore everything in this directory I haven't already told you about", then what happens if the next applied patch adds files into that ignored directory? (Mercurial will never see that new file, right?)
Hopefully this is not a completely stupid question with an obvious answer. I've compiled things from source many times before, but have never needed to apply version control on top of that. Plus we're new to Mercurial.
Two options:
The best option is to do an out of tree build, if you can. This is a build where you place the object files outside of the source tree. Some build systems, such as CMake, support this directly. For other systems, you need to be lucky since the upstream project must have added support for this in their Makefile or similar.
A more general option is to tell Mercurial to ignore specific types of files, not entire directories. This works well in my experience.
To test the second option, I wanted to compile Apache. However, it requires APR, so I tested with that instead. After checking in a clean apr-1.3.8.tar.bz2 I did ./configure; make and looked at the output of hg status. The first few pattens were easy:
syntax: glob
*~
*.o
*.lo
*.la
*.so
.libs/*
The remaining new files look like they are specific files generated by the build process. It's easy to add them too:
% hg status --unknown --no-status >> .hgignore
That also added .hgignore since I hadn't yet scheduled it for addition. Removing that I ended up with this .hgignore file:
syntax: glob
*~
*.o
*.lo
*.la
*.so
.libs/*
.make.dirs
Makefile
apr-1-config
apr-config.out
apr.exp
apr.pc
build/apr_rules.mk
build/apr_rules.out
build/pkg/pkginfo
config.log
config.nice
config.status
export_vars.c
exports.c
include/apr.h
include/arch/unix/apr_private.h
libtool
test/Makefile
test/internal/Makefile
I consider this a quite robust way to go about this in Mercurial or any other revision control system for that matter.
The best solution would be to fix the build process so that it behaves in a 'nice' manner.. namely allowing you to specify some separate directory to store intermediate files in (that could then be completely ignored via a very simple .hgignore entry... or not even within the version-controlled directory structure at all.
For what it's worth, I've found that in this situation a smart .hgignore is the only solution that has worked for me so far. With the inclusion of regular expression support, it's very powerful, but tricky, too, since a pattern that is cruft in one directory may well be source in another.
At least you can check in the .hgignore and share it with your developers. That way the work is only done once.
[Edit] At least, however, it's possible -- as noted above by Martin Geisler -- to have full path specifications in your .hgignore file; you can, therefore, have test/Makefile in the .hgignore and still have Mercurial notice a new test2/Makefile
His process for creating the file should give you almost what you want, and you can tune it from there.
One option you have is to clean your working directory after verifying a build.
make clean
hg status
Of course you may not want to clean your project if it takes more than a few minutes to build.
If the files you want to track are already known to hg, you can hgignore everything. Then you need to use hg import to add patch, and not just use the patch command (since hg needs to be aware if some new files should be tracked).
How about a shell (or whatever) script that walks your build directory recursively, finds every file created after your build process started running, and moves all these files (of course, you can specify the exceptions) into a cruft_dir subdirectory. Then you can just put cruft_dir/* in .hgignore.
EDIT: I forgot to add, but this is fairly obvious, that this shell script runs automatically as soon as your build finishes. Maybe it's even called as the last command in your Makefile/ant/whatever file.