I am trying to use subgit to create a link between an existing SVN repo and a new git repo.
The directory names in the SVN repo have spaces in them which I think is creating a problem when I try to create a configuration.
Is there a way around it?
Cheers
I'm one of SubGit developers and as I know there's no problem when directories names contain spaces.
If you have spaces in branch names, use spaces in the config file:
branches = branches/branch with space:refs/heads/branch with space
excludeBranches = branches/branch to exclude
Well, if the space is the last character, you have to put the value in quotes because Git config format requires that:
branches = "branches/space at the end :refs/heads/spaces at the end "
I would also note that Git does not allow spaces in the branches name and physically in the Git repository it will be encoded to '+':
refs/heads/spaces+at+the+end+
but in the config you specify its version with spaces.
Also you can use just spaces in excludePath/includePath options:
includePath = /directory with space
excludePath = /directory with space/subdirectory with space
If you have other problems or questions, leave a command, I'll update the answer then.
Related
I would like to ignore everything in a certain folder and its subfolders, except for .c and .h files.
Yet locally, i need other files too. Do i have to have these files, which should not be tracked, in the git-repo before or after i add the .gitignore?
And how do i do this?:
#ignore all
*
#but:
!source/**/*.c
!source/**/*.h
This is my current solution, but it does not work. But i think this also relates to the point in time, where i have to add the files, that should be ignored, but need to be there locally?
EDIT:
The problem is, i got a copy of a project, that does all kinds of makefile magic and other things, i do not even know what kind of file-types and subfolders there are (i will only work in one folder of the massive project, so i don't think, that the gitignore needs to be so exclusive) ... and i can't just commit everything, because the "lib" has to be installed i think, so everybody needs to do this on his own ...
Ignoring * means ignore everything including top-level directories. After that git doesn't even look into subdirectories. To fix that unignore directories. Your entire .gitignore should look like this:
# Ignore all
*
# Unignore directories
!*/
# Unignore source code files
!source/**/*.c
!source/**/*.h
Another approach is to ignore everything but force-add necessary files with git add -f.
The problem is that the pattern
*
excludes all directories, too. According to the gitignore documentation,
It is not possible to re-include a file if a parent directory of that file is excluded.
To make this work, then, you'll need to use make sure that directories are not ignored. The gitignore pattern format does not provide a way to distinguish between directories and regular files, so you'll need to do that manually. One possibility would be to put a .gitignore file in each that directory that reincludes all its subdirectories, but it would be easier to just reinclude all directories. These can be matched (exclusively) with a pattern that ends with a '/':
!source/**/
Also, you are right when you say
But i think this also relates to the point in time, where i have to add the files, that should be ignored
in the sense that gitignore does not apply to files that are already tracked.
I often see "./..." in makefile. I think it means it is all subfolders in the current directory. Could someone confirm and provide me the source where this syntax is explained?
Example:
go generate ./...
The import path pattern ./... matches all packages in directories below the current directory, except those in vendor directories.
The pattern is implemented by the go tool. The pattern is not interpreted by make, bash and any other tool that might invoke the go tool.
The documentation for the go command says:
An import path is a pattern if it includes one or more "..." wildcards, each of which can match any string, including the empty string and strings containing slashes. Such a pattern expands to all package directories found in the GOPATH trees with names matching the patterns.
To make common patterns more convenient, there are two special cases. First, /... at the end of the pattern can match an empty string, so that net/... matches both net and packages in its subdirectories, like net/http. Second, any slash-separated pattern element containing a wildcard never participates in a match of the "vendor" element in the path of a vendored package, so that ./... does not match packages in subdirectories of ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do. Note, however, that a directory named vendor that itself contains code is not a vendored package: cmd/vendor would be a command named vendor, and the pattern cmd/... matches it. See golang.org/s/go15vendor for more about vendoring.
and it also says:
An import path beginning with ./ or ../ is called a relative path. The toolchain supports relative import paths as a shortcut in two ways.
First, a relative path can be used as a shorthand on the command line. If you are working in the directory containing the code imported as "unicode" and want to run the tests for "unicode/utf8", you can type "go test ./utf8" instead of needing to specify the full path. Similarly, in the reverse situation, "go test .." will test "unicode" from the "unicode/utf8" directory. Relative patterns are also allowed, like "go test ./..." to test all subdirectories. See 'go help packages' for details on the pattern syntax.
Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces, but such programs cannot be installed with "go install" (there is no work space in which to install them), so they are rebuilt from scratch each time they are built. To avoid ambiguity, Go programs cannot use relative import paths within a work space.
I'm trying to create a fairly simple batch file to download a file from our ftp site and store it in a specific directory. I would like to be able to put the batch file in the path so I can call it from anywhere. Currently I have a line like the following:
curl -v -u %FTP_USER%:%FTP_PASS% -Q "TYPE I" -o %OUTPUT_PATH% "ftp://%FTP_HOST%/%JAR_FILE_NAME%"
What I've discovered is that no matter the value of the output path, the file is always written in the current directory, and any path seperators are converted to underscores in the file name. This happens no matter if I use a '\' or '/' and if I try to escape it with double slashes I just end up with two underscores. Quotes around things don't seem to help either.
My question is does the -o option allow for outputting to a folder other than current working dir? I guess I can have the next step in the script to be "move the file to its destination", but that seems really kludgey.
This sounds exactly like a regression (reported here) we unfortunately brought in curl 7.47.0. We hope to release an updated, fixed, version soon and in the mean time you can probably consider downgrading to an earlier version to work-around this annoying issue.
There are some files we want ignored, not tracked, by git, and we are having trouble figuring out how to do that.
We have some third-party C library which is unpacked and we have it in Git. But when you configure && make it, it produces many new files. How to write .gitignore to track source files and not the new stuff. (it's not like forbidding *.o)
Edit: There are at least 12 file-types. So we would like NOT to enumerate, which type we want and which not.
Use ! to include all the types of files you need. Something like in the following example"
*
!*.c
!*.h
Explicitly specifying which files should be tracked and ignoring all others might be a solution. * says ignore everything and subsequent lines specify files and directories which should not be ignored. Wildcards are allowed.
*
!filename
!*.extension
!directory/
!/file_in_root_directory
!/directory_in_root_directory
Remember that the order matters. Putting * at the end makes all previous lines ineffective.
Take a look at man gitignore(5) and search for !. It says
Patterns have the following format:
(...)
An optional prefix ! which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources.
I'm not sure why you say "it's not like forbidding *.o", but I think you mean that there aren't any good patterns you can identify that apply to the generated files but not to the source files? If it's just a few things that appear (like individual built executables that often don't have any extension on Linux), you can name them explicitly in .gitignore, so they aren't a problem.
If there really are lots and lots of files that get generated by the build process that share extensions and other patterns with the source files, then just use patterns that do include your source files. You can even put * in .gitignore if it's really that bad. This will mean that no new files show up when you type git status, or get added when you use git add ., but it doesn't harm any files that are already added to the repository; git will still tell you about changes to them fine, and pick them up when you use git add .. It just puts a bit more burden on you to explicitly start tracking files that you do care about.
I would make sure the repo is clean (no changes, no untracked files), run configure && make and then put the newly untracked filed into the ignore file. Something like git status --porcelain | fgrep '??' | cut -c4- will pull them out automatically, but it would be worth some eyeball time to make sure that is correct...
I'm trying to ignore a file in my project with .hgignore, and just can't figure it out. The file is located in app/views/patterns/_changes.erb (relative to the root of the project, where .hgignore is), and nothing I try seem to work:
#.hgignore
syntax: glob
app/views/patterns/_changes.erb
*changes.erb
public/files/* # this works
I read the .hgignore doesn't distinguish between folders and files, but can't really make it happen. Any clue? thanks.
If you just put:
_changes.erb
as an entry, that should work. It will ignore that file name, regardless of location. Note that if the file is already in the repository, it won't REMOVE it... it just won't prompt you to add it next time it sees a file with that name.
As a side note, if you want to remove a file from version control, use the command:
hg forget _changes.erb
(Note that this will remove the file from the current revision onwards. The file will always remain in past changesets -- i.e. it's not a total purge of the file.)