-----BEGIN PGP SIGNED MESSAGE-----
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-----