Re: [PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexandre Julliard <julliard@xxxxxxxxxx> writes:

> A better fix may be to only fetch tags that point to commits that we
> are downloading, but git-clone doesn't have support for following
> tags. This will happen automatically on the next git-fetch though.
>
> Signed-off-by: Alexandre Julliard <julliard@xxxxxxxxxx>

All five patches look sane.  Thanks.

The last one made me go "Huh?" at first, but it indeed is an
improvement.  It wouldn't make much sense to "shallow clone" by
two commits near the tip of the 'master' branch from Linus's
kernel, and then having to "shallow clone" all of his tags down
to v2.6.12-rc2, each with two commit depths limit.

I however think a better "fix" is not to use shallow "clone" but
shallowly fetch branches you are interested in into an empty
repository for such a use scenario.  Just like making two-depth
shallow copy of all the old tags do not help when the user is
interested in the recent history of the tip of the 'master'
branch, it does not help much to get near the tip of all other
branches with a uniform depth when one particular branch from a
remote repository is of interest.  I can imagine that somebody
who fully follows the 'master' branch from git.git repository
from time to time wants to take a peek at near the tip of 'pu'
(perhaps because the 'shallow clone' topic is interesting) or
wants to fetch near the tip of Jakub's gitweb work to see what
area is still being improved, and shallowly fetching them into a
repository that has full history of my 'master' would be a
useful way to do so, provided if 'pu' and/or Jakub's tree have
deep enough histories since 'master' that the benefit of saved
bandwidth and disk usage outweighs the complexity of "shallow".

I haven't tried these usage scenarios myself.  I wonder if a
shallow "clone" with non-uniform depths from possible more than
one repository work sensibly?

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]