fetch fails when a package has been updated?

[cboettig]

I often see fetch fail if a package has been updated since I last ran drat, and I still have a packages_src directory sitting around.

I haven't completely diagnosed this one yet, might be something in how you are doing the original clone command (e.g. perhaps you're doing shallow clones that don't pull the whole history? Of course that's nice for this context, but would create this issue I think).

e.g.:

Error in call_system(Sys_which("git"), c("-C", path, "fetch", "origin",  : 
  Running command:
  '/usr/bin/git' -C packages_src/knitr fetch origin *:*
had status 1
Program output:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
From https://github.com/yihui/knitr
 ! [rejected]        refs/pull/1073/merge -> refs/pull/1073/merge  (non-fast-forward)
 ! [rejected]        refs/pull/1080/merge -> refs/pull/1080/merge  (non-fast-forward)

I think the shallow clones are ideal (particularly since the nightly builds on circle are always doing fresh pulls anyway, so it's nice that's as fast as possible), and the ideal behaviour might be to catch this and delete the stored copy so we can shallow clone again. But otherwise full clones might be the quick fix. (Or maybe I'm way off and the issue is completely different).

[richfitz]

Yeah, I'm wondering if doing this more simply is the right move, or to use --mirror. I avoided --mirror because git2r didn't support it but it turns out it doesn't support lots of things I need so I'm going to use the command line anyway.

But the arguments for simplification are probably more compelling: depending on global state in the file system makes it hard to reason about, hard to test, and I'm leaving australia so may soon have proper internet again.

[richfitz]

I think that this should work now. Could you check?