tags:

views:

216

answers:

2

Hi, I'm new to git an basically following the directions from here http://genaud.net/2008/08/clearcase-globally-git-locally/ to try and mirror a clearcase snapshot.

I create the git repository on the snapshot directory.

Then I create a clone of that repository to create my working repository.

UPDATE: here's what I did

cd d:/views/contribsnap #(this is the snapshot from clearcase)
git init
git add .
git commit
#at this point I have a repository stuffed with my clearcase snapshot
#then
git clone -o contribsnap . /d/views/csclone
# now I have my working repo
cd /d/views/csclone
edit testfile.txt
git add testfile.txt
git commit -m "made some changes"
#from git gui hit 'push' button which puts my changes into the contribsnap repo
#BUT it also stages a new file in contribsnap which if I commit it, it undoes the changes I pushed.

END UPDATE

Now, the problem is I don't understand what happens on a 'push' from my working repository back to the origin.

When I hit the 'push' button in git gui from my working repository, it seems to put the right thing into the origin repository, but then it stages a file which when committed undoes the push. It got really confusing the first time I tried it, because I did the push from the working repo, then a commit on the origin and HEAD^1 seems to have the changes, but the latest doesn't.

I'm guessing you're not supposed to commit that, and it's put there so that the maintainer of the origin can easily undo the push?

What is the workflow if I'm the maintainer of both. Should I rather 'pull' the working repo into the origin? Or do I unstage the undo file and then...??? I don't know what to do with that 'undo' file.

Thanks. Jim

+1  A: 

I'm a little bit confused as to exactly what you're doing, but this advice might help: in general, it's a good idea to separate working repositories from your master repository. So create a separate (say) gitrepos directory, and then each local copy should push and pull from there. Don't edit files directly in that master copy. This can help keep things simple and clean, and means you won't accidentally damage your master copy.

You can also use git init --bare in your gitrepos directory, and all the files will live right there, rather than in a .git directory.

Peter
A: 

I think this http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F basically explains what's going on, although it doesn't exactly explain the mechanism.

I found that pulling does what I expect.

Also this thread stackoverflow.com/questions/883878/update-website-with-a-single-command-git-push-instead-of-ftp-drag-and-dropping explains you have to do a 'git checkout -f' on the remote when you use push... Thanks

Jim