Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2009, 19:31 UTC
Message-ID: <7veip5db7p.fsf@alter.siamese.dyndns.org>
In-Reply-To: <76718490910140549l4a6b4f60je64d1b71a1a33d1d@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 17 quoted lines

> What if instead we do something like this:
>
> $ git checkout v1.5.5
> Note: moving to 'v1.5.5' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
>   git checkout -b <new_branch_name>
> HEAD is now at 1d2375d... GIT 1.5.5
> $ [edit foo.c]
> $ git add foo.c
> $ git commit -m "edited some file"
> Cannot commit to v1.5.5. Please use git commit -b <branch> to specify
> the name of a new branch to commit to, or use git commit --detach to
> force a detached commit.
>
> So we modify git to, by default, no longer allow creating a commit
> while detached or on a branch that cannot be committed to.

I'd probably object to such a change if there is no easy way to turn it off per session (that means "expert mode" configuration variable, or a command line option per "git commit" invocation, are not a viable escape hatch), as I do it all the time, while reworking on an existing series. E.g.

    $ git checkout $(git merge-base master topic)
    $ work on redoing topic
      - cherry-picking parts from topic~$n
      - editing
      - committing
    $ git show-branch HEAD topic
    $ git branch -f topic

is a very common sequence of how I personally work, at day-job and also while maintaining git itself.

I probably would not mind such a change if I can say "I am detaching now in order to build on a non-branch. Do not bother me with unwarranted and misguided helpfulness until I am done" once upfront when I perform the first checkout.