On Thu, 12 Apr 2007 22:08:59 +1200, Martin Langhoff wrote:
> Not sure if Junio wants this, but if I am going to migrate
> away from cogito, I'd like these common operations to be
> dead simple.
Hi Martin,
Whether we're talking about cogito migration or not, I also want these
operations to be dead simple. So I really appreciate seeing your
efforts on this front.
> This is something cogito supports using the <repo>#branchname
> syntax. I am pretty sure git supports it when fetching
> but alas, no longer for cloning.
I seem to recall Linus complaining about the <repo>#branchname syntax
because it allows for only one branch name. So one thing to think
about is how to allow for multiple branches to be tracked while
cloning, ("--track branch1 --track branch2" ?).
Separately, something I've always wanted is a succint way to advertise
a complete specification of a branch that users could conveniently
take, (read, "cut-and-paste, preferably with double-click"), and use
whether they wanted to do any one of the following operations:
1. Make a new clone, and checkout that branch
2. Fetch that branch into an existing clone
3. Add that branch to an existing clone as something to start tracking
So, if you wanted to try to tackle that problem as well, that would be
great. (It's basically an extension of your "git clone --track"
idea---allowing it to be performed after a clone as well, but without
any more complication in the user interface.)
For this, I think the <repo>#branch syntax is actually worthing
thinking about. With it, the above three operations could be provided
with operations something like:
git clone <repo>#branch
git fetch <repo>#branch
git track <repo>#branch
Where this new git-track command would encompass a lot of the work
that git-clone is doing currently. That is, the git-clone rewrite
that Junio is envisioning could be implemented something like:
mkdir <branch>
cd <branch>
git init-db
git track <repo>#branch
In other words, most of the interesting stuff that git-clone does
would still be available in an existing clone by using this new
git-track command.
By the way, the <repo>#branch syntax isn't essential for what I'm
describing here. This syntax does provide something that could be
usefully provided to either git-clone or git-fetch as a single
command. This is opposed to the current state where I have to say
things like:
If you've got a clone already, do: [*]
git fetch <repo> branch:branch
git checkout branch
If you don't have a clone yet, do:
git clone <repo>
git checkout -b branch origin/branch
But whether or not <repo>#branch syntax is adopted, providing the
post-init-db guts of git-track would still be useful, and it could
still accept the same means of specifying multiple branches that git
fetch accepts:
git track <repo> branch1 branch2 ...
Anyway, there's some food for thought for anyone that's working on
adding these kind of conveniences to git, (which I would find
extremely valuable).
-Carl
Attachment:
pgp6nLMbboOdo.pgp
Description: PGP signature