Jay Soffian <jaysoffian@xxxxxxxxx> writes:
> 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.
--
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