Re: correct workflow with bare repo and pull?

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

tisdag 30 juni 2009 08:28:22 skrev Andreas Ericsson <ae@op5.se>:
> Tim wrote:
> > Myself and the other developer on the team have private repos, and we
> > push to a bare repo (which we use for Hudson builds).  For now we only
> > use the master branch.  No other remote repos.  When another developer
> > pushes changes to the bare repo, and I pull them, all of the files they
> > pushed show up as modified on my box when I do "git status" (even
> > though I had not modified them).  How to avoid this?
> 
> Make sure neither of you modify the executable bit on the files, and make
> sure your editors work the same in both ends wrt the last line and white-
> space at the ends of lines.
> 
> Also make sure you have compatible crlf settings in your git configs.
> 
> If your editors are what's causing the problem, you should only see the
> files you've actually opened in your editor as being different. If it's
> your git configuration, "git pull && git status" should show differences
> immediately. "git help config" and searching for core.autocrlf should
> point you in the right direction to what might be causing the error.
> If it's modechanges that's the problem. core.filemode may also be a
> possible source of errors (it has to be "false" on windows but can be
> "true" on systems with posix permissions).
> 
> >   Also, one
> > developer saw really strange results when they did a "git pull origin
> > master" and "git status" -- the paths shown below do not exist in the
> > local work area.  These files have always lived under a-core/.... so it
> > is really odd that they show up under a-web
> > # On branch master
> > # Changes to be committed:
> > #   (use "git reset HEAD <file>..." to unstage)
> > #
> > #    new file:   a-web/src/main/java/com/blah/account/Account.java
> > #    new file:   a-web/src/main/java/com/blah/account/AccountType.java
> > #
> > # Changed but not updated:
> > #   (use "git add/rm <file>..." to update what will be committed)
> > #   (use "git checkout -- <file>..." to discard changes in working directory)
> > #
> > #    deleted:    a-web/src/main/java/com/blah/account/Account.java
> > #    deleted:    a-web/src/main/java/com/blah/account/AccountType.java
> > 
> > What are we doing wrong?  
> > 
> 
> Hard to tell without knowing what the repository looks like. Is this
> a repo you can share with us?

"Changes to be committed" is the index
"Changed but not updated" is the workdir.

So modify the files, update the index (git add -u) and then rm (not git rm) the files
and you get this. But from a pull/merge only you should not get this state.

A possible way,is if you had non-ascii filenames and one of the trees was produced using the Eclipse plugin. 
For non-ascii names you could get corrupt (wrong order) trees and that would fool git when merging into
producing "interesting" results.  See http://egit.googlecode.com for instructions for upgrading to the latest
pre-built plugin.

-- robin