J. Bruce Fields wrote:
quoted text
> 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@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html