1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On Sat, Apr 18, 2009 at 02:47:21AM +0200, Maciej Mrozowski wrote: |
5 |
> On Friday 17 of April 2009 19:46:13 Donnie Berkholz wrote: |
6 |
> |
7 |
> > Fact is, most people using an SCM aren't deeply familiar with it. They |
8 |
> > learn enough to work and stop there, unless they've got a lot of time on |
9 |
> > their hands.. |
10 |
> |
11 |
> Actually --rebase is certainly going to cause some issues even for those |
12 |
> familiar with git, especially while resolving conflicts - as while doing |
13 |
> rebase, locally commited changes are now marked as "remote" - which certainly |
14 |
> is going to be misleading in non-trivial conflicts. |
15 |
> As you know it's as well pretty dangerous operation as it *rewrites* git |
16 |
> history. On the other hand it makes new commits not disappear somewhere in the |
17 |
> middle but added to the tip of rebased branch - that being said I guess it |
18 |
> will be desired practice to always: |
19 |
> git pull --rebase |
20 |
|
21 |
Actually, the way I understand it, is you would do a git pull --rebase |
22 |
if you try to push then get an error because other commits have been |
23 |
pushed before yours. Otherwise, you can just do a git pull without the |
24 |
--rebase option. I'm not sure what you mean by locally committed |
25 |
changes being marked as "remote". |
26 |
|
27 |
Here is my understanding of what rebase does. Say that I'm working on |
28 |
the master branch, and I do a commit, but someone else is also working |
29 |
on the master branch at the same time. They do a commit and push |
30 |
before I do my push. |
31 |
|
32 |
Now I try to push. Git will complain because my master branch is not up |
33 |
to date. If I do a git pull without --rebase at this point, I will |
34 |
create a merge in the history. But, if I do a git pull --rebase, my |
35 |
local change, which has not been pushed yet, will be moved forward so |
36 |
that it happens after all of the changes I pull. If there are |
37 |
conflicts, I resolve them on my end. then continue the rebase process |
38 |
until it is done. Then I do a git push to push my change to the central |
39 |
repository. |
40 |
|
41 |
My only question about this would be, what would happen if I do not |
42 |
resolve the conflicts correctly locally. |
43 |
|
44 |
> Anyway, in my opinion, either forbidding rebase or forcing rebase should be |
45 |
> made commit policy. |
46 |
|
47 |
I'm definitely not an expert on git, but I don't think you can forbid |
48 |
or force this option. The idea of doing a git pull --rebase is to make |
49 |
your local commits that you are about to push appear in the history |
50 |
after the ones that have been pushed before yours. Someone who knows |
51 |
more feel free to correct me. |
52 |
|
53 |
- -- |
54 |
William Hubbs |
55 |
gentoo accessibility team lead |
56 |
williamh@g.o |
57 |
-----BEGIN PGP SIGNATURE----- |
58 |
Version: GnuPG v2.0.10 (GNU/Linux) |
59 |
|
60 |
iEYEARECAAYFAknpTvAACgkQblQW9DDEZTjxawCfRpglteOtt5OqR9e0yAvqeor/ |
61 |
OLEAn3Ex3c501/QEulBboZ8XwdbImnOh |
62 |
=wqdQ |
63 |
-----END PGP SIGNATURE----- |