Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsCommit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/997460/#msg_997460
Dennis Putnam2013-01-07T15:54:26-00:00Re: Commit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/997471/#msg_997471
Dennis Putnam2013-01-07T16:39:25-00:00Re: Commit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/997476/#msg_997476
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.
]]>R Shapiro2013-01-07T17:23:26-00:00Re: Commit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/997484/#msg_997484
Dennis Putnam2013-01-07T18:09:04-00:00Re: Commit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/997497/#msg_997497
In a non-bare repository the working tree of files and directories are created, deleted or updated on 'checkout', based on the state of the branch being checked out. The usual mantra is that a Git commit saves the state of the working files in a kind of virtual file-system, as opposed to version-control systems like SVN in which a commit saves diffs. I don't know how this works internally, and so far my impression is that you don't need to know the internal details at this level to use Git effectively. But I imagine it's all documented somewhere if you're curious. If nothing else you can get the C++ Git sources from here:
The primary job of the clone operation is to copy all the current commits to the newly created clone. It has nothing to do with working files directly. But it typically also has the side-effect of checking out a branch (eg "master"). That checkout is how you get the initial working tree after a clone.
]]>R Shapiro2013-01-07T19:44:45-00:00Re: Commit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/997498/#msg_997498
Dennis Putnam2013-01-07T19:53:06-00:00Re: Commit->Push->Push Upstream-> Argh!!!
https://www.eclipse.org/forums/index.php/mv/msg/446560/998375/#msg_998375
a folder usually called
<repository name>.git
e.g.
foo.git
When you clone a bare repository to a non-bare repository this object database gets copied over to
your machine into a folder
<repository name>/.git
e.g.
foo/.git
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
foo/
In git jargon this is often called the working tree.
]]>Matthias Sohn2013-01-09T22:02:39-00:00