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

From: Junio C Hamano <junkio@cox.net>
Date: Dec 14, 2006, 21:22 UTC
Message-ID: <7vmz5q18cn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612140959.19209.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 19 quoted lines

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