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-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 _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
