Re: git and rebasing

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-04-10 at 17:59 +0200, Hans Breuer wrote:
> At 10.04.2009 15:05, Owen Taylor wrote:
> [...]
> > Since git pull --rebase fixes any previous git pull without the
> > --rebase, if we can catch problem commits (by looking for bad commit
> > messages, perhaps), then maybe it's better to just say:
> > 
> >  Merge commit with repository detected. This means you had local changes
> >  and typed 'git pull' instead of 'git pull --rebase'. You can type 'git
> >  pull --rebase' now to fix the problem. Then please try 'git push'
> >  again.
> > 
> Unfortunately 'git pull --rebase' does not fix "any previous git pull
> without the --rebase" (or maybe I'm just scheduled for SCM darwinism;))
> 
> [hb HB-T1XP glib (master)]$ git pull --rebase
> .gitignore: needs update
> build/win32/make.msc: needs update
> gio/makefile.msc: needs update
> glib/makefile.msc.in: needs update
> glib/pcre/makefile.msc: needs update
> tests/makefile.msc.in: needs update
> refusing to pull with rebase: your working tree is not up-to-date
> 
> Even following the hint from
> http://wiki.openembedded.net/index.php/GitPhraseBook
> does not help:

Sorry for the slow response on this. The problem is that the files above
have mixed LF/CRLF, which confuses auto-newline handling in git. See:

http://github.com/guides/dealing-with-newlines-in-git

And the section on autocrlf in:

http://www.kernel.org/pub/software/scm/git/docs/git-config.html

The github page recommends:

 A) Using autocrlf=true
 B) Clean up all mixed line-endings in your repository

But alternatively, it might be simpler and less magic to:

A) Use autocrlf=false
B) Count on your editor not to introduce CRLF

- Owen