On Mon, Dec 9, 2013 at 9:37 PM, Ido Rosen <ido@kernel.org> wrote:
I think I found a bug: If the repository URL/source array entry has changed but the directory name has not, the user would have to manually delete the cloned repository, otherwise the git fetch/checkout would be from the incorrect upstream repo.
In theory this is a problem, but in practice it would fail in the current code in download_git before reaching this, because it has the same problem. Another question is how likely is that someone would try to pull an unrelated repository. I guess it must be quite unlikely, as noone have reported this as a bug.
This checkout checks out whatever has been cloned, but the git remote (origin by default) may be pointing to the wrong URL/source array entry, since you simply reuse the same .git/config (since you didn't rm -rf and git clone again). Therefore, this will break any update that changes repository URLs, and require the user or AUR wrapper to manually go in and delete the checked out repository...
There's no need to change remote, because for the clone in $srcdir the default remote is our clone in $SRCDEST. The same goes for the mercurial.
If saving yourself the step of having to "git clone" again is your only goal, here are two possible ways to solve that problem:
The main point is to allow incremental builds as in FS#35050