I want to have two separate versions of a file: One on github and one on my local machine.
More specifically, how do I ignore a commit coming from the remote server. In this particular case, I modified the file on github, committed it, but I want it to not change on my local machine.
I put the readme file on .gitignore.
Changed the file on github.
Made a commit
Fetched the commit on my local machine using VS2017.
How do I "ignore" the commit. And keep the two versions separate.
You can at least try:
git update-index --skip-worktree -- README.md
As I mentioned here, that would resist a git pull.
And you would keep a local version of README.md, different from the tracked one from GitHub.
I don't presume to know if it is a good idea or not, in your particular situation.
Related
I created a github repo for some scripts I use in order to keep from having to remote into the server every time I want to make a change.
This code needs to exist simultaneously on two different servers, and one of the servers doesn't need all of the files that the other one does.
Is it possible for me to sync a repo over two different servers each having their own gitignore files?
It's possible to have different exclude information on both servers [1]. However with that said, this won't stop a pushed file from being downloaded on the server that has that file excluded. There is no way to stop git from pulling all files when you pull.
You would need to have two repositories if you have different files, or use some sort of submodule approach for shared files (repoA and repoB go to serverA and serverB, and both include a shared submodule repoShared) - but this is now really pushing what is already a non-ideal use case for git.
[1]:
Git stores exclude information in $GIT_DIR/info/exclude (where $GIT_DIR is your .git folder within you repository), so you could hardcode relevant files in there.
Note, if you already have unstaged changes you must run the following after editing your ignore-patterns:
git update-index --assume-unchanged [<file>...]
See the relevant documentation, or previous posts on similar matter.
I've got a repository. When downloading this repo, instead of cloning it, it seems that I accidentally simply downloaded the source instead. Now I've come to commit my changes and noticed that the folder I'm working in is, in fact, not a repository at all but just some random folder.
I've found various ways of initializing a new repo from existing contents. But how can I initialize an existing repo from my existing contents? I added the remote repo as a remote in the GitHub for Windows client, but it doesn't seem to have had the desired effect.
Just to be clear, the intended outcome is as if I had cloned it properly in the first place- history, diffs of the changes I've made from the latest in the repo, the works.
I've tried some solutions involving git clone, like "Clone into a new folder and then just copy and paste the .git folder". However, this seems to have the effect that Git thinks that I deleted and re-added every line of every file in the repository instead of the changes I really made.
From what we talked about in the comments, you should copy over the actual data to the properly cloned repository as opposed to the .git folder. This way, Git has a chance to pick up the changes without introducing any aberrant or unusual state issues.
Sometimes I have problems with my Laravel project after running composer update. I believe this is caused by changes in the Laravel application skeleton (https://github.com/laravel/laravel). How do I update my local project to reflect those changes?
From the awesome forum post on the Laravel forums by Kindari (http://forums.laravel.io/viewtopic.php?id=5367):
If you originally cloned this repository and still share a git history
with it, you can usually merge in changes easily. Assuming your remote
is 'upstream' pointed at this repository, you can do the following:
git fetch upstream
git merge upstream/develop
Alternatively you could cherry pick in individual commits
from the develop branch, but I won't cover that here.
If you downloaded the zip distribution originally or
removed the upstream history, you can still resolve your problem
manually. Look at the commits on this branch and make any changes not
present in your application. Usually the breaking changes are simple
configuration changes.
Since most of the changes are likely to be simple configuration changes,
another option is to do a diff on the root folder and the /app folder. You'll mostly see your own configuration, but you'll also see any new configuration items that you should add.
I usually use git pull request. A git pull request does a git fetch followed by a git merge. It works for me nicely. In other words, A git pull is what you would do to bring your repository up to date with a remote repository.
my Hg repo now needs to include a Git submodule (Restkit) as per the advised method in the site wiki.
However, I am not updating the git contents and should only be potentially reading/pulling in changes from the host.
It appears that when I came to make my first push of my main Hg repo it baulked at the Git one asking for a password. I think this may be because its attempting to authenticate against the Git site as well.
My questions are can I arrange this so that the Git repo is read-only(pull) or even static and/or get round the log in issue. Obviously the two different repos have different credentials.
Thanks.
P.S. using Atlassian SourceTree 1.5.3 on OS X 10.8.2, Xcode 4.5.1
I've just re-read this;
2.6. Synchronizing in subrepositories
Subrepos don't automatically track the latest changeset of their sources. Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update.
Thus, updating subrepos is a manual process. Simply run 'hg pull' and 'hg up' in the target subrepo, test in the top-level repo, then commit in the top-level repo to record the new combination. The onsub extension can be used to automate that.
Assume this means its not pulling the sub? but I still have the above issue of the password request.
You moved in the right direction, but not finished all required steps.
You have to have subrepository, create it by hand... and don't mix real subrepository with a) independent b) nested repository
When you'll convert nested to subrepo push into master repo will not perform push to subrepo (except it requested)
Switching to GitHub and can't seem to find information on how to do something I used to do with SVN:
First of al I'm a tester so I never commit changes, but I do need to keep a number of local copies of the project each with a small difference to trunk - staging, production, decreased timer values etc
I used to use CornerStone on Mac (just fwiw/don't have it any more), and a single update from SVN would update all my various local 'dependent projects' (all of them the same, apart from one or two lines, usually in a config file). I'd review the inevitable conflicts and almost always reject them, provided the only difference in the conflicting file was my customisation for test purposes, or if there was something new I'd merge it in and leave my staging environment URLs or whatever as they were.
Can I do this sort of thing efficiently with GitHub? (preferably using GitHub's/Xcode's or some other Mac GUI client?)
I did look at the documentation, but can't seem to find anything on this so any help much appreciated/maybe it's kind of unusual to be pulling changes to lots of almost-identical local projects and always be rejecting certain conflicts.. :)
Of course, the ideal solution is to not have configuration data tracked in the repository, or at least make it possible to override via some untracked file.
However, there's no problem with what you want to do in git. You just locally make multiple clones of your GitHub repository. In each, you can make your changes specific to that local copy, and then commit them. Then, when you want to update from the latest version of GitHub, make sure that you pull with:
git pull --rebase
... which will fetch the latest version from the server, and then try to reapply your commits with local changes on top of them. Unless the same parts of the files that you've committed changes to have also been modified in the new commits on GitHub, you shouldn't even have conflicts to resolve.
If you always pull like this, then the commit graph (history) of your project will always be the same as the remote, but with any of your local changes as the most recent commits on top of the remote history.
(I would hope that the GUI clients that you are using have an option to rebase on pulling new changes. Otherwise you can set this to happen automatically with the config option branch.<name>.rebase, where <name> is the name of your local branch.)