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

Andy Parkins [off-list ref] writes:

On Thursday 2006, December 14 21:22, Junio C Hamano wrote:

quoted

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.