Reduced amount of checkout, simplifying things a bit. #14

Open
wants to merge 2 commits into
from

Projects

None yet

2 participants

@jarl-dk

This is also to unify that revision is in context of the repository (not the local working repository)

@jarl-dk

You should also be aware of seattlerb/rake-remote_task#19

@ktheory
Collaborator

Why do you remove fast checkout? It provides a great speed boost on subsequent deploys.

It is errorprone. The temporary repository in #{destination} can be different from the repository set with set :repository. Some may actually have changed the the :repository in such a degree that a given tag or branch (say master) is changed. Further it may be that "#{git_cmd} remote -v | grep -q #{repository}" returns true, but the repository is no more origin, but maybe old_origin. In that case the code "#{git_cmd} checkout -q origin" (line 20) will fail. origin may not even be a remote anymore in #{destination}. So I considered the code fragile compared to what it gave. Even in some case the code would perform slower than doing a shallow clone.

@ktheory
Collaborator

This seems error-prone.

In what way does it seem error-prone?

Collaborator

There may be an branch or tag name using the letters a-f.

'effaced' was a word that came to mind, though seems implausible as a branch name.

Is there much of a tradeoff in always doing a clone depth of 1?

Yes, but the consequence is not fatal (not even erroneous) , it just means that it will make a deep clone instead of shallow clone. There is a trade-of from useability to chance of making a deep clone, the tradeof can be adjusted by changing the first number in the count match: From /^[0-9a-f]{6,40}$/ (high usability, "high" chance of deep clone) to /^[0-9a-f]{40,40}$/ (low usability, "low" chance of deep clone). You are welcome to change it to the later... Personally I would always either use a named commit or full SHA1.

@ktheory
Collaborator

What's the motivation here?

I'm not sure that shallow clones are faster for most use cases. Some example here show shallow clones are ~89% the size of a full clone.

This patch would do the shallow clone every deploy; whereas fast checkout only downloads the changes since the last commit.

@jarl-dk

I don't mind skipping the --depth= argument completely for stability/clarity reasons... It will also eliminate any concerns regarding is_commit_id?(revision) My personal experience though is that the size is ~50% size, only really large projects (linux kernel) goes down to ~15%

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment