Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Pass --depth 1 to git #4345

Closed
domenkozar opened this issue Oct 7, 2018 · 12 comments
Closed

Pass --depth 1 to git #4345

domenkozar opened this issue Oct 7, 2018 · 12 comments

Comments

@domenkozar
Copy link
Contributor

Some git repositories can be really big (i.e. amazonka), does stack need anything else from the git history besides the latest revision? This would save bandwidth and time fetching git dependencies.

@mihaimaruseac
Copy link
Contributor

It seems that we are already doing this?

let args = [ "clone", repo , "stack", "--depth", "1", "--recursive", "--branch", branch]

@mgsloan
Copy link
Contributor

mgsloan commented Oct 13, 2018

@mihaimaruseac That is the invocation for stack upgrading from its own source repo. I believe that @domenkozar is referring to the invocations for fetching dependencies from git.

IIRC the reason depth wasn't set to 1 was in order to have sharing of git objects when updating the git dependencies - I believe at some point it would try to reuse the existing repo instead of recloning. Looks like now it simply reclones each time, though, so indeed --depth 1 could be used here -

RepoGit -> cloneAndExtract "git" ["--recursive"] ["--git-dir=.git", "reset", "--hard"]

@mihaimaruseac
Copy link
Contributor

Makes sense then. i'll do a PR asap in that case.

@mihaimaruseac
Copy link
Contributor

Oh, but that file has been dropped from master

@mihaimaruseac
Copy link
Contributor

If I understand

github = withObjectWarnings "PLArchive:github" $ \o -> do
GitHubRepo ghRepo <- o ..: "github"
commit <- o ..: "commit"
let archiveLocation = ALUrl $ T.concat
[ "https://github.com/"
, ghRepo
, "/archive/"
, commit
, ".tar.gz"
]
archiveHash <- o ..:? "sha256"
archiveSize <- o ..:? "size"
os <- optionalSubdirs o
pure $ pure $ NE.map (\(archiveSubdir, pm) -> PLIArchive Archive {..} pm) (osToPms os)
correctly then it's now cloning at a specified commit.

Guess I'll just have to trace it when I get some more free time and see how it behaves.

@domenkozar
Copy link
Contributor Author

That is using the tarball without git, which is a good alternative. But using git could have a similar performance, if --depth 1 was added a few lines above.

@dbaynard
Copy link
Contributor

I believe there was a discussion with @snoyberg and @sol about a new way to proceed here (I think it involved caching somewhere).

@snoyberg
Copy link
Contributor

With the new way we do things with Pantry (checking out the repo and caching it in the SQLite store), skipping the history clone would be great. The relevant code for doing the cloning is here:

let (commandName, resetArgs, submoduleArgs, archiveArgs) =
case repoType' of
RepoGit ->
( "git"
, ["reset", "--hard", T.unpack commit]
, Just ["submodule", "update", "--init", "--recursive"]
, ["archive", "-o", tarball, "HEAD"]
)
RepoHg ->
( "hg"
, ["update", "-C", T.unpack commit]
, Nothing
, ["archive", tarball, "-X", ".hg_archival.txt"]
)
let runCommand args = void $ proc commandName args readProcess_
logInfo $ "Cloning " <> display commit <> " from " <> display url
runCommand ("clone" : [T.unpack url, suffix])
-- On Windows 10, an upstream issue with the `git clone` command means that
-- command clears, but does not then restore, the
-- ENABLE_VIRTUAL_TERMINAL_PROCESSING flag for native terminals. The
-- folowing hack re-enables the lost ANSI-capability.
when osIsWindows $ void $ liftIO $ hSupportsANSIWithoutEmulation stdout
created <- doesDirectoryExist dir
unless created $ throwIO $ FailedToCloneRepo repo

The problem is that, to my recollection, some older versions of Git do not support cloning at a specific commit. Therefore, cloning at depth 1 would prevent us from then resetting to the commit we want.

@domenkozar
Copy link
Contributor Author

I see, it cloning revision even requires special feature on the server: https://stackoverflow.com/questions/31278902/how-to-shallow-clone-a-specific-commit-with-depth-1

I guess the only thing that can be done then is to make depth an option, so user can hand-pick it.

@dbaynard
Copy link
Contributor

dbaynard commented Oct 22, 2018

Yes, a server feature, though we can pick sensible defaults?

@snoyberg
Copy link
Contributor

How about a setting in the extra-deps itself saying whether to turn on --depth 1 or not? Then we can bikeshed on whether on or off is the correct default.

@snoyberg
Copy link
Contributor

snoyberg commented Apr 2, 2019

@snoyberg snoyberg closed this as completed Apr 2, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

5 participants