On Fri, Dec 23, 2011 at 01:18:36PM -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@xxxxxxxx> writes:
>
> > Sometimes it's useful to clone only a subset of branches from a remote
> > we're cloning. Teach clone the --fetch option to select which branches
> > should get fetched.
>
> This is just a knee-jerk reaction without reading the patch text (which I
> won't be doing over the holiday weekend anyway), but is the workflow of
> the primarly intended audience to clone "a subset of branches" or "a
> single branch"?
>
> I have a slight suspicion that this started out as "I often want to create
> a clone to _track_ a single branch, but because I am mucking with the code
> related to cloning anyway, I might as well allow more than one to be
> fetched, even though I do not have any need for that, somebody might find
> it useful". And that is why it is important to answer the first question.
The main usefulness is indeed to track single branches. Limiting it to
one looked to me to be an arbitrary limitation and I don't like
those. Tracking between two and all branches is probably quite a niche
however, so I'll go with allowing one -t/--track option and if enough
people want to extend it, we'll see what we do then.
>
> If the primary motivation is for a single branch, I suspect supporting
> only a single branch and advertising the feature as "tracking only one
> branch" might make it much easier to understand to the end users.
>
> Upon "git clone --track cn/single-clone $there x.git", you would do
> something like:
>
> it=cn/single-clone &&
> git init x.git &&
> cd x.git &&
>
> # configure "git fetch origin" to only get branch $it
> git config remote.origin.url "$there" &&
> git config remote.origin.fetch refs/heads/$it:refs/remotes/origin/$it
>
> # declare that the primary branch at origin is $it as far as we are concerned
> git symbolic-ref -m clone refs/remotes/origin/HEAD refs/remotes/origin/$it &&
As Jakub pointed out, remote already has this option, so you can
replace these calls with
git remote add origin $there -t $it -m $it
>
> # Git aware prompt reminds us that this repository is to track branch $it
> git symbolic-ref -m clone HEAD refs/heads/$it &&
>
> # And Go!
> git fetch origin &&
> git reset --hard remotes/origin/$it &&
> git config branch.$it.remote origin &&
> git config branch.$it.merge $it
A lazier man (or one who doesn't work with internals every day) might do
git checkout -t origin/$it
which the documentation claims would do the same thing. So it boils
down to doing three commands and it feels like it'd be much easier to
just write a small script than to modify the clone code. Putting it in
C will hopefully make the code a bit cleaner, if I use the code that
already exists in remote.
>
> Of course you _could_ support more than one pretty easily, but the point
> is that it is unclear how you explain to the end user what the feature
> does and what it is for in easily understoodd terms, once you start doing
> so. It will no longer be "this new clone is to track that branch", but
> something else, and I do not know what that something else is.
Looking at the explanation for the -t (--track) option in git-remote,
it's certainly not very friendly unless you already know exactly what
a -t option would do if you were to implement it.
cmn
Attachment:
signature.asc
Description: Digital signature