correct workflow with bare repo and pull?

correct workflow with bare repo and pull?

[Tim]

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?   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?  


      

Re: correct workflow with bare repo and pull?

[Andreas Ericsson]

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?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: correct workflow with bare repo and pull?

[Robin Rosenberg]

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