J. Bruce Fields wrote:
On Sun, Oct 14, 2007 at 11:12:07AM -0700, Steven Grimm wrote:
It's possible git's introductory documentation should delay talking
about "git branch" until later, and start off talking about how to work
with one (checked out) branch per repo.
One frequent use case is the case of a tester that wants to try out a
bugfix in some topic branch. You want to tell them: "please test the
fix-that-bug branch in git://myproject.org/~me/repo.git". They need to
get that checked out somehow. And they should be able to do it without
re-cloning every time.
That's one motivation, among others, for including git-branch (and
git-remote) very early.
Though actually the quickest way to checkout an arbitrary revision is
with detached heads, and that doesn't require learning git-branch right
away.
But the *easiest* way, where "easiest" means "involves the fewest commands
with smallest risk of fscking up your own repo", is to do
git clone <other-devs-repo> other-devs-repo
cd other-devs-repo
git checkout -b thebug <the-bug-hash>
The proper command-sequence for any other way of doing it will inevitably
be different depending on whether or not the user has changes in his
worktree or not, whether or not those changes conflict with the bug-spot,
whether or not he's got the other developer's repo added as a remote, etc,
etc.
Too many ifs, really, whereas the first way is guaranteed to work exactly
the same way everytime, at the cost of almost always being ridiculously
suboptimal.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
