Re: What's in git.git (stable)

[Junio C Hamano <junkio@cox.net>]

Andy Parkins <andyparkins@gmail.com> writes:

> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
>
>> This is interesting.  You said "commit -b", were pointed out
>> that you were talking about "checkout -b", and just after saying
>> "yup, that is right, I was", you again say "commit -b".
>
> There truly is something wrong with me.

I did not mean it that way.  I only took it as a sign that maybe
"first create and switch to a branch and then work and commit
there, in separate steps", which is how git encourages things to
be done, does not match people's mental model so well.

> 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.

But people on the list (and #git channel) sometimes wished an
easy way to help the following workflow.

 * I am in the middle of working on a new feature.  As a good
   git user, I am on a topic branch dedicated for that purpose.

 * 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).

 * But I fix it in the working tree anyway, because otherwise I
   would forget.  It happens to be in an isolated file that my
   current topic does not need to modify (say, I was looking at
   a function in that file that my new feature needs to call and
   I wanted to study its calling convention. And I found a typo in
   the comment near the function).

 * The fix does not belong to the current topic, but can go to
   the 'master' branch straight.  It's a fix in the comment that
   cannot possibly break things, and I can/will test it later
   anyway.

 * So with the existing set of tools, I would go there, commit
   and then come back:

	$ git checkout [-m] master
        $ git commit -m 'fix typo in that-file' that-file
        $ git checkout [-m] topic

   But it might be faster to say:

   	$ git commit -b master -m 'fix typo in that-file' that-file

   to make a commit on the other branch and come back
   immediately afterwards.

 * In the same situation, when the 'master' is closed for some
   administrative reason (e.g. "deep freeze before a release and
   strict bugfixes and nothing else are allowed"), I would create
   a new 'typofix' branch and do the same.  I can rebase it
   later on 'master' when it reopens.

	$ git commit -b typofix -m 'fix typo in that-file' that-file

	... much later when master reopens ...
        $ git rebase --onto master topic typofix

It's just a possible typesaver, but I am likely not using it
myself (my fingers are already trained to do the three command
sequence dance).

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.