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...
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 am working with a tool which auto-generates a large amount of C code. The tool generates code for a batch of .c and .h files at each run. For some reason, the tool isn't smart enough to recognize when the files have no substantial changes, so in many cases it simply updates a timestamp in the comments at the top of each file. Otherwise, the file remains unaltered.
When I run git status in that scenario, I sometimes see dozens or hundreds of files changed. But as I review the changes to the individual files, most of them have no real changes - just an update to the timestamp. I have to go through each file one-by-one to determine if there are any actual changes to be committed.
Is there a way to configure Git so that it can ignore inconsequential changes such as the timestamp in the header comments? Or how might I otherwise deal with this situation?
Thanks for your help.
Is there a way to configure Git so that it can ignore inconsequential changes such as the timestamp in the header comments? Or how might I otherwise deal with this situation?
Yes; this is the purpose of a filter.
You might be familiar with git's notion of "clean" and "smudge" filters already, that's how it handles line ending conversion. When you are on a Windows computer and have Windows-style line endings in your working directory, you might set a .gitattribute like * text=auto indicating that you want files checked into the repository with "normalized" Unix-style line endings. In this case, the files will have the "clean" filter applied to convert \r\n line endings to \n style line endings. Similarly, the files will be "smudged" on checkout to convert from \n to \r\n on-disk.
You can create your own clean and smudge filters to remove (or add) data when translating between the working directory and the repository. For these files you can add an attribute:
*.c filter=autogen
And then you can configure your autogen filter, with commands to run in the "clean" (into the repository) and "smudge" (into the working directory) directions.
git config --global filter.autogen.clean remove_metadata
git config --global filter.autogen.smudge cat
(Using cat is a "noop" as far as filters are concerned).
The Pro Git book has more detailed examples of creating your own filters.
I discovered a way to address the problem of trivial changes using Beyond Compare. I will describe the process as it pertains to ignoring timestamp updates in auto-generated C files, but it can be easily adapted to other situations and languages:
Configure Beyond Compare as the Git difftool. See here for specific details about how to do this.
(Optional but helpful) Add a Git alias for the git difftool --dir-diff --no-symlinks command (for example, dtd).
Make some changes (e.g. auto-generate your files), and run git dtd to do a directory diff. Beyond Compare will open and show you a before/after Folder Comparison of your changes.
Open a Text Compare session window for one of your changed files. Open the Tools menu and select File Formats.
Open the Grammar tab, delete the "Comments" grammar element.
Add a new grammar element and give it a meaningful name such as "Generation Time Comment".
For Category, select the "Delimited" grammar element. In the "Text from" box, enter the text you would like to ignore. For example, if the timestamp in your auto-generated code starts with the string * Generation Time:, enter it into the "Text from" box. Check the "Stop at end of line" checkbox.
Click the "Save" button and go back to your Text Compare session window.
Open the Session menu and select Session Settings. Open the Importance tab.
Look for your new grammar element (e.g. "Generation Time Comment") and uncheck it. This will tell Beyond Compare to treat it as an unimportant change.
Open the Comparison tab, select Rule-Based Comparison.
Change the dropdown at the bottom of the dialog to Update session defaults.
Close Beyond Compare, and then reopen it again by running the git dtd command.
All of the files in the Folder Compare session which contain nothing but an update to the timestamp will be shown with unimportant differences. If you want to completely hide files with unimportant differences, toggle off Ignore Unimportant Differences in the View menu.
Reference: https://www.scootersoftware.com/support.php?zz=kb_unimportantv3
I want to get list of files and directories affected by specific commit. I have no problem getting the commit itself but I rather don't know how to get affected files and directories.
Just to make it clear I need something like this:
file x - deleted
file y - added
file z - modified
Git is snapshot-based; each commit includes a full list of files and their state. Any notion of "affected" files needs another commit to compare it to. This is commonly done against its parents, which seems to be what you're asking about. You can figure out which files are different between two commits (or more exactly, their trees) by using the git_diff family of functions.
You can find an example of doing so in the examples listing for libgit2. There is also a more general annotated diff example. The second link also shows how to list individual files as well as their contents, if you need that. Check the reference for a a full listing of available function to work with diffs.
Note that this won't give you affected directorires by itself, as Git does not track directories, but only files.
You're looking for git diff.
The same function exists in libgit2, and the documentation for it is here.
If you're analyzing older commits, "git diff [commit1] [commitAfterCommit1]" will give you a list of changes that the second commit made from the first. You could prune this output to get yourself just the changed file names.
I'm looking for something that's a bit robust in how it finds files in Emacs. I have a project made up a number of different files, and a lot of them. So, I think maybe Emacs would need to cache a lookup or something like that to make a quick find/open facility to work. It would need to also be configured per project to consider only some directories and exclude others inside of this project, since a number of files and directories are generated and hold a massive amount of text and sometimes a concatenated representation of the rest of the code.
Is there a quick file open/find like IntelliJ's find file, or Sublime's? Something with fuzzy search. But in Emacs? That could help with this problem?
Projectile can probably do what you're after. It describes itself as a "project interaction library" with facilities for finding project files quickly.
Try projectile: https://github.com/bbatsov/projectile (see its fancy UI, helm-projectile). You'll have the command projectile-find-file. It is based on projects (they are defined by a .git/.gh/… or a .projectile).
permanent caching ? Yes
filter out directories ? Yes (with a command or a config into the .projectile)
fuzzy search ? Yes, a few: emacs'default, ido, ido-fuzzy, grizzl or helm.
you install it simply with M-x package-install RET projectile RET.
See this EmacsWiki page, which is is a jumping-off place for multiple answers to your question.
Emacs has a built-in file-name cache -- see (emacs) File Name Cache and this page.
See also Emacs bookmarks, and in particular, Bookmark+. You can bookmark any file or set of files. You can bookmark a Dired buffer, including its omit set, markings, and included subdirs. You can bookmark a set of such Dired buffers. You can aggregate bookmarks and use them to perform actions that set up environments etc. They can be triggered in various ways. You can bookmark Emacs desktops. You can tag bookmarks and files & dirs with free-form tags, which lets you organize them flexibly into overlapping sets.
See also this page about project support with Icicles.
I have a big named branch with a lot of changes. Some of these changes are non-destructive so I want to pick these specific files out first, and merge them with default as soon as possible. (Then later, the destructive changes are merged as well.)
In Git I would create another branch and squash all changesets outside of the index, then I would add the specific files to the index and commit. After that, I could merge this temporary branch with master so master has a clean commit with only the non-destructive change. I don't know how to do this with Mercurial.
You can use hg cat to grab the contents of a file as it exists on any particular branch, and replace the working copy version with that.
This isn't technically a merge, but since you're replacing whole files you shouldn't have too much of a bad time merging things later:
for example, to grab myfile.c form branch somefeature, and replace the working copy version, do:
hg cat path/to/myfile.c -r somefeature > path/to/myfile.c
note that this completely replaces the working copy file so make sure you have no outstanding changes first
I think mercurialqueues is what you want. With mq you can turn any changeset into a patch and any patch into a changeset. So taking a changeset converting it to a patch deleting the chunks out of the patch that you don't want and then applying it to whatever branch you want. This is a fairly complex operation though and requires a certain amount of discipline on your part. So I would try to nail down your workflow on a test repo before trying it on code you care about.
As far as I know, Mercurial doesnt any have tools to split changesets. If youre lucky, all the changes you want are in separate changesets and then you can use the TransplantExtension. I think it can be compared to Git's cherry-pick but I havent used git much.
You can also use hg diff to manually commit the changes to a certain file to a new branch. Use the rev range to mark your entire source branch:
hg diff myfile -r startrevision:endrevision
The output can be treated as a patch. Do this for each file you want and commit them and then merge. Skipping the destructive changes. You can also, of course, do this multiple times of a destructive change is in the middle of a revision range.
Having said that what youre trying to do isnt something mercurial was built for. That hardcore history editing is more Git's area (note that its just my opinion). Keep your stable changes and destructive changes in separate changesets (and maybe even in separate branches). I use transplant, rebase and strip to move changes around. When its all done, they are merged and properly pushed.
Oh, and check MercurialQueues. I havent used it myself but Ive seen it do some crazy stuff. Maybe its capable of doing something along the lines of what you want.