Hi, Andrea,
On Sep 3, 2010, at 2:07 , Andrea Mattana wrote:
yes, I have often done the 'git pull' that's why I was sure to be
up to
date, but I never tried to use the '--ff-only' argument.
The --ff-only option is not necessary; it is only for a "sanity
check" to make sure that nothing has changed locally.
I agree with you that both git and http protocol have to point
likely to
the same archive, but yesterday I did again the git clone using the
http,
and I have seen a slightly different behaviour looking at the
simulink.
Thank you very much for your detailed report! There was indeed a
problem with the web server configuration that resulted in accesses
via the http protocol to point to an older, abandoned, should-have-
been-deleted copy of the repository that was left over from before we
switched from gitosis to gitolite for administering the repositories
hosted on casper.berkeley.edu.
The CASPER Git repository referenced via http was indeed "broken" in
the sense that it was the wrong repository! =8-O
I have fixed the web server configuration so that it now points to
the same repository as the git daemon. This can now be seen by the
identical output of these commands...
$ git ls-remote http://casper.berkeley.edu/git/mlib_devel.git
eab23d2fcb8e1f89db697edad8d3ec9fba7c8c50 HEAD
eab23d2fcb8e1f89db697edad8d3ec9fba7c8c50 refs/heads/master
$ git ls-remote git://casper.berkeley.edu/mlib_devel.git
eab23d2fcb8e1f89db697edad8d3ec9fba7c8c50 HEAD
eab23d2fcb8e1f89db697edad8d3ec9fba7c8c50 refs/heads/master
Before fixing the web server configuration, the http access method
referred to an older repository that was never updated past commit
bb2e907bfa7e0d8f34e7b8fb67fc0ef73b992480 (June 23, 2010)!
Thanks again for the information and sorry that you encountered the
problem in the first place. At least now there is a clear
explanation for it.
Dave
