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
Hash: SHA1

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