By mistake I forgot to add *.pyc to ignore-glob, and now they litter my repository. Is there a way to remove them from my repo?
After you've added *.pyc to your ignore-glob, do a fossil rm *.pyc, then commit the change.
Related
Yepp, I'm quite new to Fossil…
During my experiments I've faced a problem: fossil all info command lists all and every repos ever touched here including those removed/deleted/dropped/erased/got-rid-of quite obviously failing like that
************* /home/jno/src/dropped-repo.fossil *****************************************
SQLITE_CANTOPEN: cannot open file at line 36667 of [0c55d17973]
SQLITE_CANTOPEN: os_unix.c:36667: (21) open(/home/jno/src/dropped-repo.fossil) -
fossil: [/home/jno/src/dropped-repo.fossil]: unable to open database file
Yes, the --dontstop flag makes the life a bit easier, but does not fix the things.
So, the question is: how to properly remove a repository?
The only way I found so far is:
fossil close it
remove the repo file itself
run sqlite3 ~/.fossil and delete from global_config where name='…' on all mentions of that repo.
This looks ugly.
I see a new/init command to create a repo, but I see no way to remove it.
PS. The recipie from Fossil: "not a valid repository" - deleted repository (just rm ~/.fossil) looks an overkill.
For the fossil all command to ignore a certain (past or present) repository, you should use fossil all ignore.
In short:
fossil close closes a working directory (by deleting the .fslckout file)
rm /home/jno/src/dropped-repo.fossil actually deletes the repository (only do this if you really want to throw away the entire repository, including all versions)
fossil all ignore /home/jno/src/dropped-repo.fossil removes the repository from the list of repositories that's used by the fossil all command.
Is there a way to move a large number of files in a Fossil repo?
Ideally, I'd be able to move them to a new directory, and Fossil would detect that and keep tracking them. fossil mv requires specifying the filenames individually. fossil add can be used to start tracking the files once they've been moved, but then I have to use fossil rm to delete the existing files one at a time. Neither of these is practical for more than a handful of files.
Fossil mv can take a directory as argument and it will move every files inside recursively. But the semantic is not exactly like the unix "mv" command and it doesn't works with the "--hard" option (probably a bug).
Example, if you have a directory "dir" and want to move it inside a new
directory "subdir", this will works.
$ mkdir subdir
$ mv dir subdir/
$ fossil mv dir subdir/dir
note: You have to use "subdir/dir" for the destination argument. Otherwise it will not do what you what, it will move all files that is inside dir directly in subdir. (so it doesn't use the same semantic as the unix "mv" command).
fossil addremove does this. It's the equivalent of fossil add . to add all new files, followed by fossil rm for each missing file.
Moving files is only one use for this command. You can also use it if you've deleted multiple files.
The downside is that moved files will be treated as new files, so you will have to keep that in mind when viewing the repo history.
I was in a C++ program with google unit test, gtest. I ran and built the projects.
At the end, when I ran git status, it gave some weird untracked files. I do not know where they are from, and how I should remove them please. Using bash.
> git status
On branch A
Untracked files:
(use "git add <file>..." to include in what will be committed)
"../path_of_file1\r"
"../path_of_file2\r"
"../path_of_file3\r"
nothing added to commit but untracked files present (use "git add" to track)
This did not work:
rm -f "path_to_file\r"
Thank you.
I believe git clean should work in most scenarios. I tried the rm without the "", it worked! Thank you all.
rm path_to_file\r (complete by tabs)
You can always remove all untracked (and unignored) files with git clean -f. To be safe, run git clean -n first to see which files will be deleted.
David's answer is a good one, assuming you want to do a full git clean.
Here is another option that lets you delete the files individually: Let your shell complete the file names for you, escaping them as necessary.
For example, if you type
rm path_to_file1
and press Tab, most shells will complete the filename with a proper escape sequence. The precise sequence will be shell-specific, and I'm not clear whether \r is the two characters \ and r or whether it's a single special character, but your shell will know for sure.
I am developing a Django app and it's my first time with Mercurial(using bitbucket).
I have done some commits without adding ".idea" folder from PyCharm to hgignore. Now I have added it to hgignore and want to remove .idea from the central repository but obviously do not want to delete the actual folder locally.
What's the proper way to handle this? I know this is a common thing, but I'm in the learning stage.
Thanks for the help in advance.
What it sounds like you want is for Mercurial to stop tracking everything under .idea. This should work (command issued in the repository root):
hg forget .idea\*
Use hg forget .idea. It's like hg remove, only it doesn't delete the file from your working directory.
hg forget .idea\* should be your solution!
you could read up more on forget / remove here
http://www.selenic.com/mercurial/hg.1.html
just for reference you can delete the .idea folder. pycharm will generate it the next time you open up your project files using it.
I use git to interface with an SVN repository. I have several git branches for the different projects I work on.
Now, whenever I switch from one branch to another using 'git checkout ', all the compiled executables and object files from the previous branch are still there. What I would like to see is that switching from branch A to B results in a tree with all object files and binaries from the last time I worked on branch B.
Is there a way to handle this without creating multiple git repositories?
Update: I understand that executables and binaries should not end up in the repository. I'm a bit disappointed in the fact that all the branching stuff in git is useless to me, as it turns out I'll have to clone my proxy git repository for every branch I want to start. Something I already did for SVN and hoped to avoid with git. Of course, I don't have to do it, but it would result in me doing a new make most of the time after switching between branches (not fun).
What you want is a full context, not just the branch... which is generally out of scope for a version control tool. The best way to do that is to use multiple repositories.
Don't worry about the inefficiency of that though... Make your second repository a clone of the first. Git will automatically use links to avoid having multiple copies on disk.
Here's a hack to give you want you want
Since you have separate obj directories, you could modify your Makefiles to make the base location dynamic using something like this:
OBJBASE = `git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1\//'`
OBJDIR = "$(OBJBASE).obj"
# branch master: OBJBASE == "master/", OBJDIR == "master/.obj"
# non-git checkout: OBJBASE == "", OBJDIR == ".obj"
That will but your branch name into OBJBASE, which you can use to build your actual objdir location from. I'll leave it to you to modify it to fit your environment and make it friendly to non-git users of your Makefiles.
This is not git or svn specific - you should have your compiler and other tools direct the output of intermediate files like .o files to directories that are not under version control.
To keep multiple checkouts of the same repo, you can use git --work-tree.
For example,
mkdir $BRANCH.d
GIT_INDEX_FILE=$BRANCH.index git --work-tree $BRANCH.d checkout $BRANCH
You could set your IDE compiler to generate all private temporary files (.class and so on) in <output>\branchName\....
By configuration your compilation setting branch by branch, you can register the name of the branch in the output directory path.
That way, even if though private files remain when you git checkout, your project on the new branch is ready to go.
In the contrib/ directory of the git distribution, there is a script called git-new-workdir that allows you to checkout multiples branches in different directories without cloning your repository.
Those files aren't tracked by Git or Subversion, so they're left alone on the assumption that they are of some use to you.
I just do my checkouts in different directories. Saves me the trouble of doing cleanup.
A make clean should not be necessary because files that are different between different branches get checked out with the actual date!!!
This means that if your Makefile is correct, only those object-files, libs and executables are compiled again that really changed because of the checkout. Which is exactly the reason a makefile is there in the first place.
The exception is if you need to switch compiler options or even compilers in different branches. In that case probably git-new-workdir is the best solution.
If the compiled executables are files that have been checked in
then git stash solves the problem.
[compile]
git stash save "first branch"
git checkout other_branch
[Fiddle with your code]
[compile]
git stash save "second branch"
git checkout first_branch
git stash apply [whatever index your "first branch" stash has]
# alternatively git stash pop [whatever index...]
If the compiled executables are files that have not and will not be checked in
then simply add them to .gitignore