On Thu, Nov 06, 2008 at 06:04:20PM +0100, Steve Walker wrote:
> The overall issue is that with files that have been pushed into our repo
> on our server, when we then check out into local working copy the new
> files appear, but the updated files dont update even though the output
> suggests it has. The flow I'm doing:
The short answer is: don't push into the current branch of a non-bare
repo.
> 2. On my local box I change file, add it, commit, then push it from my
> local box to our server repo:
OK, so this updates the HEAD of the receiving repository. But the index
and working tree are untouched.
> 3. It all looks good, on my server if i do a 'git log' I can see in the
> latest update:
Right, because the HEAD has been updated.
> 4. So I check out:
>
> oneworld:/home/beta_idibu/public_html# git checkout master
> M .gitignore
> M steve-git-test.txt
> M steve-git-test2.txt
> M steve-git-test3.txt
> Already on branch "master"
> oneworld:/home/beta_idibu/public_html#
But you were already _on_ master, so git shouldn't need to touch the
index and working tree. But the contents of master have changed out from
under you, so it looks like you have modifications.
So generally you don't want to push to the current branch, but there is
no safety valve disallowing it (and I will post a patch series in a
minute which introduces one). In the past, people have suggested doing a
merge with the working tree, but that is not desirable for two reasons:
1. you are changing the working tree out from under whoever's repo you
push into
2. the merge might not be clean, in which case the user needs to
resolve conflicts. But the user isn't even doing stuff in the
now-conflicted repository. So the suggested workflow is instead to
go to that repo and do a 'pull'
So depending on what you want to accomplish, there are a number of
alternative workflows:
- if you just want to publish refs, you can use a bare repo without a
working tree at all (git --bare init, or git clone --bare).
- if you just want to throw away working tree changes on a push (e.g.,
you are pushing to a production server whose working tree is kept up
to date), you can do that automatically with a post-receive hook. But
it will never be the default, because we don't want to throw anything
away unless the user has explicitly told us to do so.
- if you are working in repos A and B, and you want to get changes from
B to A, then you would generally go to A and "git pull B". But
sometimes that is not possible (e.g., you can only make network
connections one way). In that case, you can push to a "remote" branch
on A, and then merge from there when you're at A. E.g.,:
/repo/B$ git push /repo/A master:refs/remotes/B/master
/repo/B$ cd /repo/A
/repo/A$ git merge B/master
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
