Gentoo Archives: gentoo-scm

From: William Hubbs <williamh@g.o>
To: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Converting a recent CVS copy - Item 3: pushing, availability
Date: Sat, 18 Apr 2009 03:54:26
Message-Id: 20090418035424.GA25004@linux1
In Reply to: Re: [gentoo-scm] Converting a recent CVS copy - Item 3: pushing, availability by Maciej Mrozowski
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-----

Replies