I've got a project using GitBook: https://github.com/akauppi/plantuml-book
It generates images from PlantUML source. For some reason, those images don't get copied to the GitBook's _book folder, and therefore don't make it into the book.
Expected:
GitBook would notice the image references, e.g.
..and copy such image files to the right location (in this case `_book/chapter1/hello.svg).
Actual:
$ tree _book/chapter1/
_book/chapter1/
└── DIAGRAMS.html
No images there. :(
Note: I did not make this a GitBook issue, since that project seems pretty dead (link).
The problem was that my .gitignore included the generated *.svg and *.png files, and GitBook automatically ignores everything in .gitignore.
The solution: these lines in .bookignore:
# Bring in the generated files (having them in .gitignore would otherwise leave them out)
!*.svg
!*.png
Related
Currently, I am using GitKraken to upload my files to Gitlab. However, there was a submodule that contained all my files for the project - in an attempt to combine the submodule into the main respiratory, I tried deleting it; however, my entire submodule is gone now. When I go into the trash folder of my Mac, I can see the folder except it is named with extra letters and contains files such as Build and Test Index. Is there anyway to get this submodule back?
UPDATE: I tried reverting the files from the trash folder, but it only put the files back into the derived data folder. Not sure how to get the submodule back, it is asking to initialize it by specifying a URL.
TortoiseSVN 1.93
Thought something was odd when I went to commit some changes, as one of the files I had added earlier was not showing up. One in particular is a .cs file in a class library project. I thought this was odd, so I added a dummy test.txt file and then started a commit again, and even that text file was not in the list of unversioned files.
Usually, if there are unversioned files, I will see them and can add them right from the commit dialog. There doesnt seem to be anything in my ignore list that would prevent these files from showing up. However, if I check for modifications, and choose the "Ignored" checkbox, sure enough, both of those files are in the list, among others.
Whats going on here?
Here is my ignore list:
bin obj debug *.o *.suo *.lo *.la *.al .libs *.so .so.[0-9] *.a
*.pyc *.pyo pycache *.rej ~ ## .#* .*.swp .DS_Store [Tt]humbs.db
Checked the SVN properties on the folder where these files were located, and there was an svn:global-ignores property set to reference the entire folder. Removed that, and opened a commit dialog again and those files were listed. So somehow, I must have got a little too ambitious with setting things to be ignored.
I am new to geb testing. We have two project folders. One of them is a subset of others. During last few days, whenever I check the status of the subset project folder using git shell, lot of closure.class files are showing as changed. But I am changing only the groovy files. I am not sure why this is happening? previously I haven't seen anything like this.
Also lot of class files are showing as untracked files.
The file name look like this.
xxx$_$spock_feature_7_29_closure6.class
We are using IntelliJ IDE.
There are lots of files, I mean class files generated when you try to build using gradlew. As Peter had suggested already, create a .gitignore file and add anything you want to ignore, for instance:
*.log
build
.gradle
.DS_Store
*.ipr
*.iml
*.iws
out
*.pem
gradle.properties
and run the gradlew clean command. You will not see those anymore. Cheers!
is it possible to set a 'rule' that tells TortoiseSVN to automatically resolve conflicts on a specific folder?
ie. we have a shared resources folder - "/shared" that we use to store our latest bin files in. when we do a local build, the local bin files in that folder gets overwritten.
next time we do an svn update on that folder the update should pull the latest bin files from SVN and overwrite the previously locally-built bin files but this will throw a conflict because the files are binary and cannot be merged (and, should not be merged anyway)
we would like to setup a rule that tells tortoise to always "resolve using theirs" on that /shared folder ("svn update -R --accept theirs-full")
There's a SVN misuse here. If the files should not be merged as you said, the directory should be set to ignore all .bin files (svn:ignore). It doesn't make sense keep in version control binary files that are changed frequently causing so much collisions.
In your place, I would delete all .bin files from this folder. If it's really necessary to keep the files versioned, I would create a directory and place these .bin files in there, avoiding frequent changing.
But if you really want to keep the files as they are, I recommend you to write client-side hooks for post-update events. See TortoiseSVN Docs for more information.
I am attempting to create a git repository to store all of my dotfiles and config files. My idea was to simply create hard links to all of the files I cared about and store those links in their own directory that I could turn into a repository.
I've hit a bit of a snag though with my ~/.gitconfig file. It seems that whenever I run the 'git config' command the link that I created no longer points to the right location e.g. the file in the repository no longer updates properly.
Here is an example using the shell and interactive ruby to determine the files linked state.
# Create the link
$ ln .gitconfig .conf_files/gitconfig # Create the link
# The files are in fact linked
[1] pry(main)> File.identical?('.gitconfig', '.conf_files/gitconfig')
=> true
# Update the gitconfig file by running a 'git config' command
$ git config --global alias.last 'log -1 HEAD'
# The files are no longer linked.
[2] pry(main)> File.identical?('.gitconfig', '.conf_files/gitconfig')
=> false
I assume this has something to do with the way that git is writing the .gitconfig file. Does anyone know why this would happen, or have any creative ideas for a workaround?
Try Eli Barzilay's solution in his comment at http://www.xxeo.com/archives/2010/02/16/dotfiles-in-git-finally-did-it.html:
So I’ve finally found a solution that takes the best of both: put the repo
in a subdirectory, and instead of symlinks, add a configuration option for
“core.worktree” to be your home directory. Now when you’re in your home
directory you’re not in a git repo (so the first problem is gone), and you
don’t need to deal with fragile symlinks as in the second case. You still
have the minor hassle of excluding paths that you don’t want versioned (eg,
the “*” in “.git/info/exclude” trick), but that’s not new.
This is completely normal, and is in fact the recommended way to overwrite config files. Git creates a temporary file, writes out the config, and then moves the new file over the old one. This way, you don't get an incomplete config file (data loss) if Git gets interrupted.
You can always write a script to copy or link your config files into your central repository.
Checkout this answer, perhaps it may be of help:
https://stackoverflow.com/a/3731139/1431696
In the meantime, have you considered doing the links in reverse? Create your repository full of config files, etc, and then in the place that you actually use your files, create a hard link to the 'real' file, which sits in the repository.
Thanks to Dietrich Epp's answer and advice I have decided to approach this problem from a different angle by creating the repository at the root of my filesystem, and using .gitignore to track only the files I am interested in.
My .gitignore file now looks like this:
/*
!/etc/
/etc/*
# etc files
!/etc/rc.conf
!/etc/asound.conf
!/etc/mercurial/
!/home/
!/home/matt/
/home/matt/*
# Home files
!/home/matt/.xinitrc
!/home/matt/.gitconfig
!/home/matt/.bashrc
# Vim files
!/home/matt/.vimrc
!/home/matt/.vim/
.netrwhist
In addition to not having to copy the files separately and keep them in two separate locations this has the benefit that should I need I can easily revert the changes without having to manually copy the files as well.
Thanks for the help guys!