1 |
On Monday, August 31, 2015 12:50:04 AM Thomas Mueller wrote: |
2 |
> |
3 |
> > * Fernando Rodriguez <frodriguez.developer@×××××××.com> [150829 12:59]: |
4 |
> > On Friday, August 28, 2015 2:24:37 PM Rich Freeman wrote: |
5 |
> > > Those who wish to use git can do so, and I'd encourage people to try. |
6 |
> > > It really does have a lot of advantages. Oh, and it makes it really |
7 |
> > > easy to contribute patches/etc (just edit whatever you want in |
8 |
> > > /usr/portage and type git diff). |
9 |
> > |
10 |
> > I wouldn't advise that on the portage tree because if you edit any files |
11 |
under |
12 |
> > version control git will refuse to pull new changes until you either |
13 |
commit |
14 |
> > the changes or undo them by checking out the file. |
15 |
> |
16 |
> It will still pull but you'll potentially have conflicts to resolve. |
17 |
> |
18 |
> A bad idea in any case. |
19 |
> |
20 |
> Todd |
21 |
> |
22 |
> Now many repositories use git, and I need to know how to make changes to |
23 |
some files, hopefully a small number, but still be able to update with git. |
24 |
|
25 |
The best way is to create a branch for your changes, just run: |
26 |
|
27 |
# git checkout -b new-feature |
28 |
|
29 |
And now you're on a branch named new-feature, do your changes, commit them, |
30 |
then checkout the master branch, do git pull and then merge your branch. |
31 |
|
32 |
|
33 |
> I keep the modifications somewhere for safekeeping, as well as the originals, |
34 |
but would want to see the updated files straight before remaking my |
35 |
modifications. |
36 |
> |
37 |
> I looked through man pages, git pull --rebase didn't work; I got error |
38 |
messages. Should I do "git reset" or should I "git checkout" each modified file |
39 |
one-by-one before "git pull"? |
40 |
|
41 |
If you commit your changes before doing the pull it will work in most cases. |
42 |
Without commiting them it will never work (unless the files have not been |
43 |
updated on the remote repo). |
44 |
|
45 |
You can also stash them away with git stash, then pull, and then finally apply |
46 |
your changes with git stash apply. See git-stash(1). If you do git checkout |
47 |
you will loose your changes, that's why it requires to do it individually for |
48 |
each file. With a branch you can also use git checkout --patch <branch> <file> |
49 |
to apply the changes individually for each file so it comes in handy when |
50 |
there's merge conflicts. |
51 |
|
52 |
> There is a lot in git, learning git all the way through looks like a tall |
53 |
order. |
54 |
|
55 |
That's an understatement I think. |
56 |
|
57 |
> Tom |
58 |
> |
59 |
> |
60 |
|
61 |
-- |
62 |
Fernando Rodriguez |