| Commit->Push->Push Upstream-> Argh!!! [message #997460] |
Mon, 07 January 2013 10:54  |
Eclipse User |
|
|
|
|
I guess I am still not understanding all the pieces involved. I have a remote repository (bare) on a Linux server. I cloned that to create a local repository on Windows and Eclipse recognized it as a project. In the Java perspective I was able to make changes and commit them. I thought I was golden. I also pushed them upstream and while there were no error popups it seemed to happen suspiciously fast and there was no window showing the session (I thought there would be one). In any case, I then did a pull from the Linux repository into my build directory on Linux and the git output seemed to indicate that the files pulled where the same ones I changed. However, when I look at the files that were pulled, they are the old version. It would appear that the changes never really made it to the remote repository. If I try to amend the previous commit, Egit tells me it has already been published to a remote branch. All indications seem to be that the upstream push worked but yet I cannot find the modified files (where does a bare repository hide the files anyway?). What am I missing? TIA.
|
|
|
|
| Re: Commit->Push->Push Upstream-> Argh!!! [message #997476 is a reply to message #997471] |
Mon, 07 January 2013 12:23  |
| Eclipse User |
|
|
|
Sounds like your clone isn't configured correctly for push, at least on whatever branch you were working on at the time. You need to tell Git how local and remote branches are related to another for push and fetch. Or else you need to tell it dynamically, on each call, by providing ref-spec (Git term for pattern that describes a local -> remote branch mapping) or the EGit equivalent of a ref-spec.
Some of the configuration happens automatically, some doesn't. You can modify the relevant configuration settings via Team -> Remote -> Configure Push to Upstream.
My guess is that the push was a no-op due to misconfiguration, but that EGit still noted the the commits as pushed and therefore no longer amendable [possible EGit bug here]
To figure out more definitely what went wrong we would to know what local branch you were working on and what your local configuration looks like. The latter it stored in .git/config in your clone. You can get a structured list via 'git config --local -l'. In Egit you can also see the logical structure in the "Properties" view of the Git repository.
Most of this is generic Git -- you can find out more about ref-specs and branch mapping in the usual Git reference resources.
Quote:where does a bare repository hide the files anyway?
The bare remote does not store user files anywhere, it stores commits, organized as directed graph to model branching and merging. That's what makes it 'bare' -- there is no working tree and no index. The commit graph is what you're cloning when you do a 'git clone', and the push and fetch operations are moving commits back and forth, not working files.
|
|
|
|
|
|
| Re: Commit->Push->Push Upstream-> Argh!!! [message #998375 is a reply to message #997498] |
Wed, 09 January 2013 17:02 |
| Eclipse User |
|
|
|
A bare git repository stores the commits and there relationships in git's object database stored in
a folder usually called e.g.
When you clone a bare repository to a non-bare repository this object database gets copied over to
your machine into a folder e.g.
Subsequently a local branch with the same name as the default branch on the remote repository
(defined by HEAD on the remote bare repository, most often this is "master") is created pointing at
the commit the default branch references and then this branch is checked out to your local file system
into the folder above the .git folder, for our example this is the folder
In git jargon this is often called the working tree.
|
|
|
Powered by
FUDForum. Page generated in 0.06657 seconds
Home