BFG Repo-Cleaner - How to delete folders except some folders - git-rewrite-history

How to delete folders except some folders?
My command is
java -jar ../BFG_Repo-Cleaner/bfg-1.13.0.jar --delete-folders "!(folder1|folder2|folder3)"
I want all folders except folder1, folder2 and folder3.

There is no workaround for this with BFG, you'll have to explicitly mention all the folders you want to delete from history.
Example - java -jar ../BFG_Repo-Cleaner/bfg-1.13.0.jar --delete-folders "{Folder1,Folder2,Folder3}" YourApp.git
NOTE: Make sure you have different names for different folder, as BFG doesn't care about the path it will delete the folders with the associated name.
--delete-folders delete folders with the specified names (eg
'.svn', '*-tmp' - matches on folder name, not path within repo)

Related

I want to find some files that includes some keyword and copy it to other folder

I want to find files that includes some keyword and copy it to other folder.
So I need two features.
Find files by keyword and list it at "file" type value.
copy the file to different directory.
But Google drive supports same folder name so I don't know how to targeting folder by name. And I want copy the file only if there is not file has same name. Because I'll run this script every 5 minutes and if I don't set about that, there are many same name files to target directory.
How can I do this?
AFAIK, the only supported methods that you can use to get files in Class DriveApp are:
getFileById(id)
getFiles()
getFilesByName(name)
getFilesByType(mimeType)
Then, to make a copy to other folder, you can use the following methods that are given in Class File
makeCopy(destination)
makeCopy(name, destination)
Lastly, the suggested solutions given in this SO post might also help.

SSIS - Delete Unknown-Name Folder Within A Known Directory

I am writing a SSIS package, and at one point I am working with a certain folder that I know the path for, and need to delete a folder inside that, but I don't know the name (path) of the inner folder.
So for example, I know this path: C:\Known, but there will be a folder inside 'Known' that I would like to delete. Like C:\Known\ Unknown
I can't use a File System Task and delete the unwanted folder, because I don't know the name of the folder, and I can't use a File System Task to delete all the directory contents of 'C:\Known', because it also contains .jpeg files that I need to keep.
Any thoughts? A solution to get the name of the Unknown folder, or delete any folders inside 'C:\Known' is acceptable.
You can add this code to a Script Task to delete all subdirectories in a path while not deleting any other file types:
foreach (string subdirectoryPath in Directory.GetDirectories(knownPath, "*", SearchOption.AllDirectories))
{
Directory.Delete(subdirectoryPath);
}

What's the correct wildcard syntax to copy TeamCity artifacts to the root of a destination path?

I'm having a small drama with the wildcard syntax in my TeamCity artifact configuration. I want to grab every file matching the pattern myproject.*.dll from any folder and place each DLL in the root of the artifacts path.
Here's what I've got at present:
**/obj/Debug/myproject.*.dll => /
This is grabbing all the DLLs but it's putting them inside the same folder structure as the source so rather than ending up with "myproject.web.dll" in the artifacts I get "Web/obj/debug/myproject.web.dll".
What am I missing here?
I'm afraid you cannot do this in an easy way.
You should collect your *.dll locally to a single place, and than use TeamCity's artifacts rule to copy all of them to root directory.
Or, you can enter all paths manually (without ** part)
This is how it works in TC.
I am not sure you can use the artifact root without it copying the structure. The docs specify
If target directory is omitted the
files are published in the root of the
build artifacts.
Can you not just use a designated folder name say dist, would this cause issues? If so what are they!
e.g
**/obj/Debug/myproject.*.dll => dist
Update - found some more info in the docs
The files will be published preserving
the structure of the directories
matched by the wildcard (directories
matched by "static" text will not be
created). That is, TeamCity will
create directories starting from the
first occurrence of the wildcard in
the pattern.
So if you can be more explicit it may lead to a flatter structure.

How do i recursively remove folders from mercurial tracking system

I have a working directory structure like the below one :
mercurial_working_dir:
project1
project2
project3
Under each project folder there are common folders that i want to untrack from mercurial.e.g:
i dont want any file to be tracked under /metadata folder which is common at the 3 projects.
As far as i know i should use hg remove -Af command with the specifing files.Is there any way to define regular exps at the command in order to recursively "remove" the current version of any file under the metadata folder which is placed at all my projects?
Take a look at the chapter about file names and pattern matching in the mercurial book. You can use a pattern like this:
hg rm "glob:**/metadata/**"
If you prefer regular expressions, you can also use the re: prefix instead of glob:.

Folders not being added in Mercurial

I looked at this question: ignoring folders in mercurial that mentions how to ignore a folder, but that's not what I need.
I'm using TortoiseHG and after I "add" all my folders, they show still as "?" instead of "+". The files within them show "+", but the folders themselves just show "?". Is this a problem with Mercurial on Windows XP? Or, is it a problem between my keyboard and my chair?
Mercurial adds only files in, and infers the folders from the actual file names. If you drop down to a command line and do hg status, you will see that folders are not listed at all. The files within the folder you added will be listed with the A tag, but the actual folders don't list in a hg status command.
You don't need to add the folders separately (in fact, Mercurial doesn't handle plain folders/directories at all). As long as your files are there, you're fine.