1

I am running etckeeper on two different machines, boxA and boxB. The OS, etckeeper repository and all, on boxB was copied from boxA back in January. In order to apply some setup changes made on boxA to boxB, I added the repository on boxA as a remote repository on boxB with the intention of doing some cherry picking, eg:

git remote add boxA ssh://boxA/etc
git fetch boxA
git cherry-pick xxxx  # never got this far

The problem is that the most recent commits are not available on boxA, only commits up until late February. So far I have tried:

  • doing git show with one of the missing commit numbers - this is definitely not a problem with git log just not showing all the commits.

  • copying the full /etc on boxA to boxB and adding/fetching it via its path - this is definitely not an issue somehow introduced by ssh (to complicate things I was using a script via the GIT_SSH environment variable to avoid creating a root login).

  • git fsck on both repositories (no problems found).

  • running the following command on copied version of both repositories (after doing a git remote remove boxA on boxB and before readding):

    git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 \
  -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc \
  --aggressive

How can I get git fetch to retrieve all of the commits?

Graeme
  • 2,971
  • 21
  • 26
  • What do you mean by most "recent commits are not available on boxA"? Not available in the remote branch remotes/boxA/master on boxB? What does git remote show boxA say? What does git fetch -v boxA say? (executed on boxB) – Uwe Geuder Jun 19 '14 at 15:00
  • @UweGeuder, I managed to get to the bottom of this on my own. By commits not available, I mean that I wasn't able to view them via `git log boxA/master` or otherwise and not able to apply them with `git cherry-pick`. – Graeme Jun 19 '14 at 18:26

1 Answers1

1

So the problem here turned out to be that there was a detached head in the repository on boxA after an incomplete fix of a botched rebase. When this happens the output of git branch is as follows:

# git branch
* (no branch)
  master

The fix was simply to create a branch on boxA and then merge it:

git branch temp
git checkout master
git merge temp
git branch -d temp

After that all the commits on branch master (or at least what I thought was branch master) were available after doing another git fetch.

Community
  • 1
  • 1
Graeme
  • 2,971
  • 21
  • 26
  • 1
    Makes sense when you mention it. Detached HEAD can be moved forward by committing, but no reference will be updated. Fetching works based on references. – Uwe Geuder Jun 19 '14 at 19:11