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

Andy Parkins <andyparkins@gmail.com> writes:

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