Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:
> ...
>> One can always get more branches later, is my approach.
>
> Yes. But in the same vein, one can add _one_ branch to an empty repo
> either. So, with your reasoning, your patch wouldn't be needed to begin
> with.
Indeed.
> But I find it useful. Even the version where you are not limited to one
> branch.
I am not against the general idea of tracking a subset of
branches, but issues include:
[1] tracking multiple (but not all) branches, as you pointed out,
[2] how this should interact with later fetches from the same
remote.
[3] allowing similar "track these branches from a new remote
from now on" in an already initialized repository.
Perhaps by specifying the --branch parameter in an wildcard
fashion, remote.*.fetch can be initialized to that wildcard and
later new branches that match the wildcard pattern ca be fetched
(which is a strawman solution for [1] and [2]). I suspect [3]
belongs to what "git remote" should allow you to do, but in that
case maybe "git init-db ; git remote *that-new-command*" would
be a single uniform way to solve all of the above?
I personally feel this is post 1.5.0 material.
-
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