patch, 2 partsRe: [PATCH 1/2] Allow users to require source branch on git-checkout -b.

I have recently observed a rather large number of users who forget to specify the base revision when they start a new branch with git-checkout -b. Many of these users are shocked many hours and commits later when their prior branch is now also part of the new branch. Nasty words about Git usually follow the discovery.

This introduces a new config option: checkout.requireSourceBranch, which the user can set to make git-checkout -b require them to supply not only the new branch name but also the initial version for that branch. This prevents the command from assuming the user meant HEAD when they omitted an argument by accident.

To keep behavior backwards compatible with any existing scripts this option is currently disabled by default, but it would be more friendly to new users if the option was enabled by default.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/config.txt |    6 ++++++
 git-checkout.sh          |   12 +++++++++++-
 t/t3200-branch.sh        |   14 ++++++++++++++
 3 files changed, 31 insertions(+), 1 deletions(-)

"Shawn O. Pearce" <spearce@spearce.org> writes:

I'm not sure about this.

Often after you started to code something while on 'master' you realize that work is not trivial and needs its own branch and then "checkout -b" without having to say 'master' (or HEAD) is very handy.

I think requring an explicit fork-point when you are _not_ on 'master' might be a better behaviour.

In other words, you allow "checkout -b" (and "branch") to default to HEAD only while on the branches marked in your configuration file:

Then:

	[branch]
        	allowbranchbydefault = main
        	allowbranchbydefault = test

can be used to say "while on 'main' and 'test' branch, 'git checkout -b' and 'git branch' without branch point defaults to the current branch".

You could turn it around and make it a per-branch configuration, like:

	[branch "main"]
        	allowbranchbydefault = true

Junio C Hamano <junkio@cox.net> wrote:

Are you suggesting that we change "git-checkout -b" to by default require the source branch, but the user can restore the original behavior by setting the above per-branch configuration option?

I'm OK with that version too. Most of these users want to be required to enter the source branch, and their topic branches (which are always their current branches btw) are so transient they won't bother with a per-branch setting. So they get what they want: the tool reminding them to select their source revision.

Shawn Pearce <spearce@spearce.org> writes:

Under my suggestion, the new git-checkout -b (and git-branch) would:

 (0) proceed if there is an explicit branch point specified on
     the command like, just like now;

 (1) allow omission of branch-point if the current branch has
     allowbranchbydefault configuration set as in above.  A new
     branch is created forking off of the current HEAD;

 (2) allow omission of branch-point if no branch has such
     configuration; in other words, existing repositories that
     do not have the allowbranchbydefault configuration anywhere
     are not affected.  A new branch is created forking off of
     the current HEAD;

 (3) otherwise, it barfs if you do not give an explicit
     branch-point.

and a newly created repository that is newbie friendly has one such configuration automatically set for 'master' (if created with git-init) or whatever the primary branch is (if created with git-clone).

Note that (2) is rather important, although I think the current implementation of repo-config is cumbersome to use for this purpose and probably needs to be enhanced.

On Thu, Dec 07, 2006 at 01:23:00PM -0800, Junio C Hamano wrote:

That makes the default behavior more complicated to explain. Is there really sufficient evidence that this a serious problem?

"J. Bruce Fields" <bfields@fieldses.org> wrote:

[snip]

I'm seeing bad branches all to often with some of the folks I have to work with. They apparently have been unable to learn the new trick of either remembering what branch they are currently on and what changes it has, or to always supply the branch they want to start from with their new branch.

Consequently they are cussing at Git rather often, as "this damn Git crap always does the wrong with my files". Despite it being their own fault for not thinking before doing...

Of course many of these users also don't understand the value of a good short diff for a simple change. *sigh* But right now I just want to stop them from creating branches off the wrong branch point 95% of the time.

On Thu, Dec 07, 2006 at 04:59:14PM -0500, Shawn Pearce wrote:

Well, it's true that "git branch" is the first thing I type whenever I sit down, just to remember where I am....

Would the trick of putting the branch name in the shell prompt work?

But my main complaint is just that I wouldn't want to see the behavior of defaulting to HEAD--behavior which is simple, easy to explain, and shared by most other git commands--by something significantly more complicated. That's more a complaint about Junio's suggestion than yours, though.

"J. Bruce Fields" <bfields@fieldses.org> wrote:

Its in the prompt for all of these users; I forced it in as part of
the system's /etc/profile.d.  They just forget that they should think
about where they should start their branch from before they make it.
 

True, defaulting to HEAD is something that is done almost everywhere. Changing it for `git checkout -b` may surprise a lot of people, almost as much as --index vs. --cached.

Maybe what I should do is stop whining about the command line Porcelain-ish and get branch controls working in git-gui. Then I can take away the command line from these users who are causing me so much grief.

On Fri, Dec 08, 2006 at 12:59:38AM -0500, Shawn Pearce wrote:

Maybe they don't really want to use topic branches at all? Could they get away with just committing everything to master? Seems like kind of a shame, though. Hm.

"J. Bruce Fields" <bfields@fieldses.org> wrote:

Good idea.  But...

No, because they are working on at least two different unrelated changes at once, and we aren't sure which will graduate into the testing environment first. If the unrelated changes are intermingled on the same branch then moving one moves both; and often at least one of those unrelated changes isn't functioning right and could cause headaches for the testing team.

Shawn Pearce <spearce@spearce.org> writes:

I did not mean to change the default to something other than HEAD depending on the configuration.

... which is the same as before.

... which allows people to do the same as before, but only on selected "primary" branches;

... which allows people to keep using the current behaviour in existing repositories;

... but a newly created repositories would have an allowbranchbydefault entry on "master" (and only on "master"), which means new people would be prevented from making mistakes when on a non-master branch 'foo':

	$ git branch bar

and end up a foobar branch that is not based on 'master'. They will instead get an error message that says "Hey, are you sure you want to fork off of this branch 'foo'?"

But I do not deeply care about this. An option to disable "default to HEAD" altogether is fine.

On Thu, Dec 07, 2006 at 10:31:52PM -0800, Junio C Hamano wrote:

Right, I understand that behavior in existing repositories is not changed...

... my concern is the default behavior on newly created repositories, which (unless I've misunderstood) would become more complicated.

OK.  Me neither, to be honest.