1

I have a script that is running some automated tasks, and it looks like git fetch is not updating the reference for origin/master. It is a bit difficult to debug, because this script is run in a server I don't have administrator permissions for (and the administrator is away for a week), and on another user's account (I have read-only access). There's this other question that looks the same, but the .git/config file already looks like this:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = ################
[branch "my-branch"]
        remote = origin
        merge = refs/heads/my-branch

The same script is working fine in other machines. I can see a difference in the git version, which is 1.7.1 in the "faulty" machine and 1.8.3 or later in others. Could this be a reason?

EDIT: So, the user that runs the script is sitting on my-branch, runs git fetch and then git rev-parse origin/master gives a very old hash, while I can see from other machines that the repository has been updated. New hashes are accessible, it's just that origin/master does not point to the right one.

Community
  • 1
  • 1
Jellby
  • 2,360
  • 3
  • 27
  • 56
  • So, `my-branch` is your Default branch here? – Sajib Khan Feb 28 '17 at 13:06
  • @sajibkhan Yes, I've added some info in the question – Jellby Feb 28 '17 at 14:44
  • If you pull `origin/master` into your current branch then, do you see latest changes? `git pull origin master` – Sajib Khan Feb 28 '17 at 14:54
  • I can't try. This happens in an account I have only read access to. If I copy the repository to my user's account, everything seems to work normally (``git fetch`` updates ``origin/master``), but there could be some configuration differences between the other account and mine... – Jellby Feb 28 '17 at 15:05
  • If you've only read access then `fetch/pull` should work also. `Push` needs write access. Would you clone the repo again and try again? – Sajib Khan Feb 28 '17 at 15:12
  • @sajibkhan I don't mean read access to the remote repository, I mean read-only access to the local directory where the repository is cloned. If I clone the repository again, I'll need to wait until ``origin/master`` is updated to see if the automatic script works differently, and I'd still have the possible differences between my user account and the one used by the script. I know there is very little information and missing tests, but I'm just asking for ideas about what could be the reason for this problem. – Jellby Feb 28 '17 at 15:24
  • *"read-only access to the local directory where the repository is cloned"* so, problem is clear. When fetching, **.git** folder files needs to update but you have no write permission in that directory. You can clone the repo other location where you have write permission or give the current location **write permission** – Sajib Khan Feb 28 '17 at 15:37
  • @sajibkhan No, **I** have read-only access. The script runs ``git fetch`` as the right user, so it has write access. Also, I can see permissions are not a problem, because ``git fetch`` did get the most recent hashes, it just didn't move ``origin/master`` to a newer one. I'm trying to find what could have failed in the script. – Jellby Feb 28 '17 at 15:43
  • I don't know of any such bugs in 1.7.1, but the only reason I know of that anyone runs such an ancient version of Git is because of CentOS, which often implies that someone is using SELinux, which adds its own weirdness, forbidding processes from succeeding at all kinds of things that normally just work. (I had the same kind of problem about a decade and several jobs ago: I could never get Git to work properly under SELinux and ended up turning SELinux off, as the system was already behind a firewall anyway.) – torek Feb 28 '17 at 21:20
  • @torek That may be a lead. The system is indeed running CentOS 6.7, with SELINUX=enforcing. Another machine that seems to work correctly runs CentOS 7.2.1511, with SELINUX=disabled. – Jellby Mar 01 '17 at 14:47

0 Answers0