On Mon, Dec 9, 2013 at 9:37 PM, Ido Rosen <[email protected]> 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
