On Monday, August 31, 2015 12:50:04 AM Thomas Mueller wrote: > > > * Fernando Rodriguez <frodriguez.develo...@outlook.com> [150829 12:59]: > > On Friday, August 28, 2015 2:24:37 PM Rich Freeman wrote: > > > Those who wish to use git can do so, and I'd encourage people to try. > > > It really does have a lot of advantages. Oh, and it makes it really > > > easy to contribute patches/etc (just edit whatever you want in > > > /usr/portage and type git diff). > > > > I wouldn't advise that on the portage tree because if you edit any files under > > version control git will refuse to pull new changes until you either commit > > the changes or undo them by checking out the file. > > It will still pull but you'll potentially have conflicts to resolve. > > A bad idea in any case. > > Todd > > Now many repositories use git, and I need to know how to make changes to some files, hopefully a small number, but still be able to update with git.
The best way is to create a branch for your changes, just run: # git checkout -b new-feature And now you're on a branch named new-feature, do your changes, commit them, then checkout the master branch, do git pull and then merge your branch. > I keep the modifications somewhere for safekeeping, as well as the originals, but would want to see the updated files straight before remaking my modifications. > > I looked through man pages, git pull --rebase didn't work; I got error messages. Should I do "git reset" or should I "git checkout" each modified file one-by-one before "git pull"? If you commit your changes before doing the pull it will work in most cases. Without commiting them it will never work (unless the files have not been updated on the remote repo). You can also stash them away with git stash, then pull, and then finally apply your changes with git stash apply. See git-stash(1). If you do git checkout you will loose your changes, that's why it requires to do it individually for each file. With a branch you can also use git checkout --patch <branch> <file> to apply the changes individually for each file so it comes in handy when there's merge conflicts. > There is a lot in git, learning git all the way through looks like a tall order. That's an understatement I think. > Tom > > -- Fernando Rodriguez
