Andy Parkins <andyparkins@xxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html