New issue

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

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

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@jarl-dk

jarl-dk commented Oct 11, 2012

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

@jarl-dk

This comment has been minimized.

Show comment
Hide comment
@jarl-dk

jarl-dk Oct 11, 2012

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

jarl-dk commented Oct 11, 2012

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

@ktheory

This comment has been minimized.

Show comment
Hide comment
@ktheory

ktheory Oct 11, 2012

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

ktheory commented on lib/vlad/git.rb in 12df22c Oct 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jarl-dk

jarl-dk Oct 11, 2012

Member

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.

Member

jarl-dk replied Oct 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ktheory

ktheory Oct 11, 2012

This seems error-prone.

ktheory commented on lib/vlad/git.rb in 12df22c Oct 11, 2012

This seems error-prone.

This comment has been minimized.

Show comment
Hide comment
@jarl-dk

jarl-dk Oct 11, 2012

Member

In what way does it seem error-prone?

Member

jarl-dk replied Oct 11, 2012

In what way does it seem error-prone?

This comment has been minimized.

Show comment
Hide comment
@ktheory

ktheory Oct 11, 2012

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?

ktheory replied Oct 11, 2012

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?

This comment has been minimized.

Show comment
Hide comment
@jarl-dk

jarl-dk Oct 11, 2012

Member

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.

Member

jarl-dk replied Oct 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ktheory

ktheory Oct 11, 2012

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.

Collaborator

ktheory commented Oct 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jarl-dk

jarl-dk Oct 11, 2012

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%

jarl-dk commented Oct 11, 2012

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