Andy Parkins <andyparkins@xxxxxxxxx> writes:
>> > Tell them if they
>> > made a branch as well, which branch they are now on.
>>
>> I think you are talking about "checkout -b" not commit here;
>> this might be a borderline (branch creation is less often done
>> and it might warrant assuring feedback), but I think it still
>> falls into the "doing exactly what it was told to do" category.
>
> You're right, I was. The reason I think feedback is useful is
> because of the two ways of making a new branch:
>
> - git-branch XYZ
> This makes a new branch but DOESN'T leave me on XYZ
> - git-commit -b XYZ
> This makes a new branch and switches to XYZ
>
> I can't tell you the number of times I get this wrong. It's not because I
> don't know if I stop to think, it's because I'm thinking about the project,
> not the VCS.
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".
Maybe the users often need this sequence (I personally don't,
but others might):
$ git checkout ;# or the previous day ended with a clean state
$ edit edit hack
$ git checkout -b XYZ ;# the changes are about different stuff
$ git commit ;# commit the changes there
$ git checkout master ;# or whatever branch you usually are on
and "git commit -b <newbranch>" might be a handy shortcut for
the last three commands. I dunno.
And if we had such a variant of commit, then it is doing
something unusual, so I would not oppose (actually I would
probably favor) if the transcript went something like this:
$ git commit -b XYZ -m "implement 'foo' subcommand" -a
committed changes to newly created branch XYZ, back on 'master'.
$ git show-branch master XYZ
* [master] finishing touches to 'hello world'
! [XYZ] implement foo subcommand
--
+ [XYZ] implement foo subcommand
-- [master] finishing touches to 'hello world'
$ exit
Earlier I said that the command should be silent if it did
exactly what it was told to do with some 'unless'es.
* If the command fails, we should report (no question).
* If the command succeeds the usual way, staying silent is
preferable, at least to me.
* If the command can have more than one mode of successful
outcome, stating success in which way is not a useless
verbosity. E.g. 'git merge' should probably tell you if it
did a usual three-way or a fast-forward (if the difference
matters). Especially reporting an unusual case a bit more
verbosely than usual is a good thing.
-
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