I'm using Bazaar (bzr) to keep source code for a website updated, but we've ran into a problem when we remove files from version control. The files we are removing are ones we never intended to version to begin with.
When this happens we use bzr rm --keep to remove the file from version control, but keep the file in the file system. Doing a bzr push or bzr pull results in the removed file(s) being removed on the other branches (other sites that use our code)
We need a way to make sure that a bzr push or bzr pull doesn't actually remove those from the working copy. Anyone have any ideas?
You need to run bzr rm --keep in all locations manually before updating them with pull/push. There is no other way unfortunately.
Related
I've inherited a PHP Weather Template Website that's updated and distributed through GitHub. The previous owner did not make a sufficient .gitignore file in the beginning, so there are a number of files that are tracked by git that shouldn't. These files include .csv databases that are updated with users' data, json data files, and a settings.php file. After adding a list of files to the .gitignore, my issue now is the best way to get these files to not be tracked by git on all of the remote clones that users are using. My first thought was to just do a git rm --cached <files>, however that removes the files from everyone, deleting everyone's data.
Next I thought to warn people to backup the files and in a week I'd issue the git rm --cached command, however with an unknown but fairly large number of users, I have no guarantee that everyone will see the message in the forums before its too late, plus surely some users will do a git pull without even looking at the forums.
For the same reasons as above, having each user issue git rm --cached probably won't work either.
Ultimately, is there any way that I can get git to stop tracking these files on every remote copy of the template, without relying on any user interaction. A simple delete-from-GitHub-but-not-from-outstanding-copies command would be great.
There is no way to do what you want. Github is not a file hosting, it's git repository hosting, it shows the content of your repositories. To remove files from Github you have to remove the files from repository (not necessary in that order: you can remove files directly from Github using web interface but then you'll have to pull changes and the files will be removed in your local repo). No way around that, sorry.
If I'm understanding your problem correctly, you want to remove the .csv files from the repository, but when someone else does a git pull their own .csv's are unaffected.
Quick Note: Do this in a separate branch or a dry run to be safe.
1) untrack all files git rm -r --cached .
2) update the .gitignore file to include all of these files.
3) add all the files back git add . (this will not include .gitignored files)
4) commit/push
I am working on a Laravel application, and I ran the command composer update in order to install new packages I had added.
I had changed/added some files in the vendor directory before that, and those files that were added have been removed. I have not committed to my vendor directory (another mistake!), hence I can't get them back through git.
Now my questions are:
What happens when composer update is ran?
Why the files removed are not in the Recycle Bin, what has
happened to them? Permanently deleted?
As well, I am well aware that I can roll back my composer update, but that will not give me back my modified files, it would rather install the original files of the previous version.
Please do let me know if there is any other way (even file recovery) would help me to get these changes back.
composer update looks for new versions of installed dependencies and, if found, installs new versions instead of the old ones. It doesn't care whether any changes were made to installed dependencies, because it's looking just at their descriptions stored in the composer.lock file.
The files most likely cannot be recovered with composer for reasons mentioned above. You can try looking for lost files inside the cache directory .composer/cache, but I see no reason whatsoever for the lost files to be there. Yes, they are probably permanently deleted and, if those are critical, you should look for a file recovery program.
You definitely shouldn't store any modifications made to dependencies for the mentioned reasons.
Also, you probably shouldn't add vendor/ to your repository, for all dependencies are tracked with composer.lock anyway, and changing dependencies inside vendor (making them hardcoded) is against composer workflow.
EDIT:
As suggested by Kévin Dunglas, you can also try to look for the lost changes in the local history of your IDE (e.g. in PHPStorm).
I'm working with a large PHP project in git and having trouble with my working copy because of a couple files, including the .htaccess, .gitignore and database configuration files getting overwritten or wanting to be staged/committed.
The problem I'm running into is that every time I try to switch branches, I'm bothered to either stash my changes or told that I can't merge because files are not uptodate. I've tried updating my exclude to the following:
.htaccess
.gitignore
./application/config/vagrant/config.php
./application/config/vagrant/database.php
Along with this, I've also tried to set these files to assume-unchanged - which is where i get the issues trying to switch branches and it telling me the files are not uptodate.
What I'd like to happen is for those files to be completely ignored forever. Whenever I switch branches, I don't want them to be merged, I just want them to essentially be removed from the repo without affecting any of the other users that work on the project.
From your description of the problem, it seems that the offending files
.htaccess
.gitignore
./application/config/vagrant/config.php
./application/config/vagrant/database.php
are already being tracked; perhaps you or one of your collaborators started tracking them by mistake a long time ago...
If you want Git to be able to ignore those files, you first need to tell Git to stop tracking them by running
git rm --cached <paths>
Then, and after adding appropriate entries in your .gitignore file, you'll be able to ignore those files, as desired.
I have a project I'm working on which I've set up in a git repo.
Since I put my latest version live, the website owner has made some changes to the working/content by overwriting it directly.
Obviously these changes were made outside of version control. I suppose I could overwrite the entire contents of my repo, then commit. That should work... but I don't really like the idea of doing that, especially if there's been any replacement of correct code/html-structure with stuff that's incorrect or bad practice.
What I'd like to do is dump the website from live into another directory and do a recursive diff so I can only overwrite those files which have changed (any correct any issues if there are any)
As in if I just overwrite what's in my git repo, then run git status?
No, you don't have to overwrite anything.
You can do a diff between:
the index representing your site in its latest versioned state (in the git repo)
a dump of the current live site (a copy done in a different folder, not under version control)
You can then do (using git options) a:
git diff --git-dir=/path/to/repo/.git --work-tree=/path/to/dump .
You actually can execute that command from any folder: it will look for the git index and for the right working tree.
The OP Tom Busby adds in the comments:
In the end I solved it by simply overwriting the .git folder in my dump directory with the one from my git repo and running git diff.
VonC's answer is excellent, but I believe you could also just use the diff command (a built-in command on most operating systems). This would also ensure that "gitignored" files were diffed (though VonC's might already do that).
Assuming the website in /www/mysite and a fresh clone in /git/mysite you could just do:
diff /www/mysite /git/mysite
Yes We can compare two directories very easily
simply using this command on Shell/Terminal
git diffdir any-branch-name any-other-branch-name
I'm working with symfony2 for some time and I don't really get the correct way to work with the vendors.
So here is what I'm doing:
I have the deps and deps.lock files in my git while I ignore the whole vendors folder. Now when I install the application to a new server, I do a php bin/vendors install to pull the vendors onto the server. I get the message that I have to use install --reinstall and do that.
From my understanding, the versions should now be the exact same as on my development machine, as both deps and deps.lock are the same. But it seems that the deps.lock gets (partly) ignored?
There is also a vendors update command, which I read should not be used. BUt I didn't get the idea what it really does.
So I'm a bit confused now as of what command should be used when and what it is supposed to do. Maybe someone can shed some light on this topic! I'm especially interested in the correct way to use the vendors command both local and on the server so the vendors are in the correct version on both systems!
install and update both fetch new code from the git repositories specified in your deps file
install checks for hashes in you deps.lock files for each library. If it finds something, it checkouts the commit corresponding to the hash. If it does not, it checkouts the tag or branch in your deps.lock if one is specified and creates an entry in the deps.lock file
update is useful when you want to update to a new version of symfony (or any library in the deps file). If you one day, you feel like updating, you can read this post I wrote about the update process.
To sum up, I always use update on all machines, and I try to always specify a version for each library, so that the production environment does not get updated to an unstable version unexpectedly.
install --reinstall is the same as install but it also deletes vendor folder content before doing installation.
vendors update updates all your vendors to the latest version or version specified in your deps file and updates your deps.lock file. But you rarely need it, don't know where you read "should not be used".
If you look inside vendors file, you can see this line:
if (is_dir($vendorDir.'/symfony') && !is_dir($vendorDir.'/symfony/.git') && !in_array('--reinstall', $argv))
...Try to run ./bin/vendors install --reinstall...
So you have vendor/symfony folder without .git in it.
have you download the standard edition which already contains the vendors, that's why it displays this message to use "install - reinstall"
I personally made php bin / install-reinstall vendors in the deployement project