From: Martin Langhoff <hidden> Date: 2016-06-15 22:43:04
Add support for a simplified workflow where users
want to clone and start working on a head that is
different from the HEAD of the repository.
Calling
git-clone --track maint <repo>
Is equivalent to
git-clone <repo> mydir
cd mydir
git-checkout --track -b maint origin/maint
--
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.
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.
And if we want it, there are 2 things I'd ask review for
- The --track parameter handling - I merely copied the
handling for other parameters. Clearly shell doesn't
do this very elegantly, or at least we don't.
- The block that defines head_points_at (@360-370) looks
very brittle so I didn't want to mess with it.
---
git-clone.sh | 39 +++++++++++++++++++++++++++------------
1 files changed, 27 insertions(+), 12 deletions(-)
@@ -344,17 +350,22 @@ if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"then# a non-bare repository is always in separate-remote layoutremote_top="refs/remotes/$origin"-head_sha1=`cat"$GIT_DIR/REMOTE_HEAD"`-case"$head_sha1"in-'ref: refs/'*)-# Uh-oh, the remote told us (http transport done against-# new style repository with a symref HEAD).-# Ideally we should skip the guesswork but for now-# opt for minimum change.-head_sha1=`expr"z$head_sha1":'zref: refs/heads/\(.*\)'`-head_sha1=`cat"$GIT_DIR/$remote_top/$head_sha1"`-;;-esac+iftest!-z"$track"&&test-f"refs/remotes/$origin/$track"+then+head_sha1=`cat"refs/remotes/$origin/$track"`+else+head_sha1=`cat"$GIT_DIR/REMOTE_HEAD"`+case"$head_sha1"in+'ref: refs/'*)+# Uh-oh, the remote told us (http transport done against+# new style repository with a symref HEAD).+# Ideally we should skip the guesswork but for now+# opt for minimum change.+head_sha1=`expr"z$head_sha1":'zref: refs/heads/\(.*\)'`+head_sha1=`cat"$GIT_DIR/$remote_top/$head_sha1"`+;;+esac+fi# The name under $remote_top the remote HEAD seems to point at.head_points_at=$(
@@ -376,6 +387,10 @@ thendone))+iftest-n"$track"&&test-f"$GIT_DIR/$remote_top/$track"+then+head_points_at="$track"+fi# Write out remote.$origin config, and update our "$head_points_at".case"$head_points_at"in
From: Carl Worth <hidden> Date: 2016-06-15 22:43:04
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
From: Martin Langhoff <hidden> Date: 2016-06-15 22:43:04
Carl Worth wrote:
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.
Hi Carl! Yes - this stuff should be simple, and _really hard to fsck up_.
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" ?).
That wouldn't be hard to implement. Actually, we could support both.
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:
(...)
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
So you are proposing (or maybe I am re-interpreting things so) that
git track <repo>#branch
should Do The Right Thing:
- perform a clone if we aren't in a repo
- set things up for tracking the branch if we are in a repo
I like the idea. :-)
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
Oops - looks like we are talking about different things. What you write
above can be done with "git-branch --track" on 1.5.1 so it's already in
existence.
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
With my proposed git-track as a wrapper around git-clone _and_
git-branch --track, you only need to say
To start working on foo, do
git track <repo>#branch
And if the user has an existing checkout they can do if from inside the
checkout, or perhaps better, saying
git track --reference <myoldcheckout> <repo>#branch
to avoid the biiig download.
cheers,
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
From: Carl Worth <hidden> Date: 2016-06-15 22:43:04
On Fri, 13 Apr 2007 09:46:45 +1200, Martin Langhoff wrote:
Hi Carl! Yes - this stuff should be simple, and _really hard to fsck up_.
I definitely agree. I think the use case of "tracking some branch
other than the default" is a really important one to make
easy. Precisely because there are a lot of users who will initially
use git for nothing other than this tracking, (not initially making
commits, or pushing, etc.).
So we would do well if this initial exposure were really easy. And
right now it's a bit too hard in my opinion, (in terms of commands,
concepts, and syntax the user has to use).
Is this correct sequence for the operation in 1.5.1 ?
git clone <repo>
cd <project>
git branch --track <branch> origin/<branch>
git checkout branch
git pull # as needed
I'd love to get that down to:
git clone <something with <repo> and <branch>>
cd <project>
git pull # as needed
and then adding a subsequent branch to track would be:
git track <something with <repo> and <branch>>
git checkout <branch>
git pull # as needed
Oops - looks like we are talking about different things. What you write
above can be done with "git-branch --track" on 1.5.1 so it's already in
existence.
The mechanics are there, yes. All that's missing is the common
<something> syntax which, as shown above, can be shared for both
cloning originally and later adding a branch to track.
And <repo>#<branch> seems as good a <something> as anything else I
could imagine.
With my proposed git-track as a wrapper around git-clone _and_
git-branch --track, you only need to say
To start working on foo, do
git track <repo>#branch
Yeah, that's the idea. I had just planned on publishing the
<repo>#branch part and the user would learn whether to pass that to
"git clone" or "git track" as appropriate.
Making one command do either one seems a little too DWIM and
error-prone to me. But whatever works, (and more importantly, whatever
you can implement and get accepted).
-Carl
From: Martin Langhoff <hidden> Date: 2016-06-15 22:43:04
Carl Worth wrote:
Is this correct sequence for the operation in 1.5.1 ?
git clone <repo>
cd <project>
git branch --track <branch> origin/<branch>
git checkout branch
git pull # as needed
Actually you don't need the git-checkout line
git clone <repo>
cd <project>
git branch --track <branch> origin/<branch>
git pull # as needed
I'd love to get that down to:
git clone <something with <repo> and <branch>>
cd <project>
git pull # as needed
That's what this patch does.
and then adding a subsequent branch to track would be:
git track <something with <repo> and <branch>>
git checkout <branch>
git pull # as needed
If your tree is reasonably clean (so that the implied git-checkout won't
fail), then on 1.5.1 this Just Works
git branch --track <branch> origin/<branch>
git pull # as needed
cheers,
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------