On Thursday 2006 December 14 23:46, Junio C Hamano wrote:

quoted text
> > There truly is something wrong with me.
>
> I did not mean it that way.  I only took it as a sign that maybe

Don't worry; I've got thicker skin than that.  I was simply amazed at my lack 
of comprehension ability. :-)

quoted text
> > I'm not sure about your "commit -b"; is it wise to have /another/ way of
> > making a branch?  I mean - I'm clearly confused enough, have a heart :-)
>
> I said "commit -b <newbranch>" and deliberately avoided saying
> "commit -b <anybranch>", because I did not want to open another
> can of worms while we are discussing so many good things
> already, and my head can hold only a handful topics at once.

Absolutely.  I'd agree that only <newbranch> is worth even considering.

quoted text
>  * While working on it, I find an obvious bug that I would not
>    want to fix on the branch (the topic branch I am currently on
>    is not about fixing that bug).

I find myself swayed by this.  This is indeed something that happens to me a 
lot.  In certain circumstances I've been defeated by git because I couldn't 
switch to the other branch to make that quick commit because my local changes 
conflicted with that other branch.  The solution I use is to commit the bug 
fix in the wrong branch, finish my current on-topic commit then 
rebase/reset/etc to put everything where it should be.

quoted text
> I do agree that it adds one more way to do the same thing and
> would make the documentation noisier, potentially adding more to
> the confusion.  So let's not go there.

Yep.  Although you've persuaded me with the above example, I think this is the 
correct path.  It's not wise to add every bell and whistle just because we 
can.  As long as there is /a/ way to achieve every task, that's good enough, 
we don't need every way to achieve every task.  We might even argue that 
git's flexibility is what makes it harder to learn.  It's similar to UNIX in 
that respect - hard to learn, easy to use.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
-
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