kernel/git - git - PowerEL Git System

42903 Commits

6 Branches

36 Tags

131 MiB

Tree: a1bc3dd464

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Erik Faye-Lund	8338f771fe	checkout: do not corrupt HEAD on empty repo In `abe1998` ("git checkout -b: allow switching out of an unborn branch"), a code-path overly-optimisticly assumed that a branch-name was specified. This is not always the case, and as a result a NULL-pointer was attempted printed to .git/HEAD. This could lead to at least two different failure modes: 1) vsnprintf formated the NULL-string as something useful (e.g "(null)") 2) vsnprintf crashed Neither were very convenient for formatting a new HEAD-reference. To fix this, reintroduce some strictness so we only take this new codepath if a banch-name was specified. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	abe199808c	git checkout -b: allow switching out of an unborn branch Running "git checkout -b another" immediately after "git init" when you do not even have a commit on 'master' fails with: $ git checkout -b another fatal: You are on a branch yet to be born This is unnecessary, if we redefine "git checkout -b $name" that does not take any $start_point (which has to be a commit) as "I want to check out a new branch $name from the state I am in". Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	cc580af885	checkout: do not imply "-f" on unborn branches When checkout sees that HEAD points to a non-existent ref, it currently acts as if "-f" was given; this behavior dates back to `5a03e7f`, which enabled checkout from unborn branches in the shell version of "git-checkout". The reasoning given is to avoid the code path which tries to merge the tree contents. When checkout was converted to C, this code remained intact. The unfortunate side effect of this strategy is that the "force" code path will overwrite working tree and index state that may be precious to the user. Instead of enabling "force", this patch uses the normal "merge" codepath for an unborn branch, but substitutes the empty tree for the "old" commit. This means that in the absence of an index, any files in the working tree will be treated as untracked files, and a checkout which would overwrite them is aborted. Similarly, any paths in the index will be merged with an empty entry as the base, meaning that unless the new branch's content is identical to what's in the index, there will be a conflict and the checkout will be aborted. The user is then free to correct the situation or proceed with "-f" as appropriate. This patch also removes the "warning: you are on a branch yet to be born" message. Its function was to warn the user that we were enabling the "-f" option. Since we are no longer doing that, there is no reason for the user to care whether we are switching away from an unborn branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago

Erik Faye-Lund

8338f771fe

checkout: do not corrupt HEAD on empty repo

In abe1998 ("git checkout -b: allow switching out of an unborn
branch"), a code-path overly-optimisticly assumed that a
branch-name was specified. This is not always the case, and as
a result a NULL-pointer was attempted printed to .git/HEAD.

This could lead to at least two different failure modes:
 1) vsnprintf formated the NULL-string as something useful (e.g
    "(null)")
 2) vsnprintf crashed

Neither were very convenient for formatting a new HEAD-reference.

To fix this, reintroduce some strictness so we only take this
new codepath if a banch-name was specified.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

Junio C Hamano

abe199808c

git checkout -b: allow switching out of an unborn branch

Running "git checkout -b another" immediately after "git init" when you do
not even have a commit on 'master' fails with:

    $ git checkout -b another
    fatal: You are on a branch yet to be born

This is unnecessary, if we redefine "git checkout -b $name" that does not
take any $start_point (which has to be a commit) as "I want to check out a
new branch $name from the state I am in".

Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

Jeff King

cc580af885

checkout: do not imply "-f" on unborn branches

When checkout sees that HEAD points to a non-existent ref,
it currently acts as if "-f" was given; this behavior dates
back to 5a03e7f, which enabled checkout from unborn branches
in the shell version of "git-checkout". The reasoning given
is to avoid the code path which tries to merge the tree
contents. When checkout was converted to C, this code
remained intact.

The unfortunate side effect of this strategy is that the
"force" code path will overwrite working tree and index
state that may be precious to the user. Instead of enabling
"force", this patch uses the normal "merge" codepath for an
unborn branch, but substitutes the empty tree for the "old"
commit.

This means that in the absence of an index, any files in the
working tree will be treated as untracked files, and a
checkout which would overwrite them is aborted. Similarly,
any paths in the index will be merged with an empty entry
as the base, meaning that unless the new branch's content is
identical to what's in the index, there will be a conflict
and the checkout will be aborted.

The user is then free to correct the situation or proceed
with "-f" as appropriate.

This patch also removes the "warning: you are on a branch
yet to be born" message. Its function was to warn the user
that we were enabling the "-f" option. Since we are no
longer doing that, there is no reason for the user to care
whether we are switching away from an unborn branch.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

16 years ago

3 Commits (a1bc3dd46433c6e7e6f1ca5f3bd5429858a60078)