[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: correct workflow with bare repo and pull?
From:       Robin Rosenberg <robin.rosenberg.lists () dewire ! com>
Date:       2009-06-30 8:14:46
Message-ID: 200906301014.46540.robin.rosenberg.lists () dewire ! com
[Download RAW message or body]

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]