summaryrefslogtreecommitdiff
path: root/builtin/checkout.c
AgeCommit message (Collapse)AuthorFilesLines
2012-07-27Merge branch 'jk/maint-checkout-orphan-check-fix'Libravatar Junio C Hamano1-1/+1
"git checkout <branchname>" to come back from a detached HEAD state incorrectly computed reachability of the detached HEAD, resulting in unnecessary warnings. * jk/maint-checkout-orphan-check-fix: checkout: don't confuse ref and object flags
2012-07-25checkout: don't confuse ref and object flagsLibravatar Jeff King1-1/+1
When we are leaving a detached HEAD, we do a revision traversal to check whether we are orphaning any commits, marking the commit we're leaving as the start of the traversal, and all existing refs as uninteresting. Prior to commit 468224e5, we did so by calling for_each_ref, and feeding each resulting refname to setup_revisions. Commit 468224e5 refactored this to simply mark the pending objects, saving an extra lookup. However, it confused the "flags" parameter to the each_ref_fn clalback, which is about the flags we found while looking up the ref with the object flag. Because REF_ISSYMREF ("this ref is a symbolic ref, e.g. refs/remotes/origin/HEAD") happens to be the same bit pattern as SEEN ("we have picked this object up from the pending list and moved it to revs.commits list"), we incorrectly reported that a commit previously at the detached HEAD will become unreachable if the only ref that can reach the commit happens to be pointed at by a symbolic ref. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-11Strip namelen out of ce_flags into a ce_namelen fieldLibravatar Thomas Gummerer1-1/+2
Strip the name length from the ce_flags field and move it into its own ce_namelen field in struct cache_entry. This will both give us a tiny bit of a performance enhancement when working with long pathnames and is a refactoring for more readability of the code. It enhances readability, by making it more clear what is a flag, and where the length is stored and make it clear which functions use stages in comparisions and which only use the length. It also makes CE_NAMEMASK private, so that users don't mistakenly write the name length in the flags. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Merge branch 'cw/no-detaching-an-unborn'Libravatar Junio C Hamano1-0/+2
"git checkout --detach", when you are still on an unborn branch, should be forbidden, but it wasn't. * cw/no-detaching-an-unborn: git-checkout: disallow --detach on unborn branch
2012-06-26git-checkout: disallow --detach on unborn branchLibravatar Chris Webb1-0/+2
abe199808c (git checkout -b: allow switching out of an unborn branch) introduced a bug demonstrated by git checkout --orphan foo git checkout --detach git symbolic-ref HEAD which gives 'refs/heads/(null)'. This happens because we strbuf_addf(&branch_ref, "refs/heads/%s", opts->new_branch) when opts->new_branch can be NULL for --detach. Catch and forbid this case, adding a test to t2017 to catch it in future. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25Merge branch 'ap/checkout-no-progress-for-non-tty'Libravatar Junio C Hamano1-2/+2
The progress indicator for a large "git checkout" was sent to stderr even if it is not a terminal.
2012-05-24checkout: no progress messages if !isatty(2).Libravatar Avery Pennarun1-2/+2
If stderr isn't a tty, we shouldn't be printing incremental progress messages. In particular, this affects 'git checkout -f . >&logfile' unless you provided -q. And git-new-workdir has no way to provide -q. It would probably be better to have progress.c check isatty(2) all the time, but that wouldn't allow things like 'git push --progress' to force progress reporting to on, so I won't try to solve the general case right now. Actual fix suggested by Jeff King. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-14Merge branch 'ef/checkout-empty' into maintLibravatar Junio C Hamano1-1/+1
Running "git checkout" on an unborn branch used to corrupt HEAD (regression in 1.7.10); this makes it error out. By Erik Faye-Lund * ef/checkout-empty: checkout: do not corrupt HEAD on empty repo
2012-05-11Merge branch 'ef/checkout-empty'Libravatar Junio C Hamano1-1/+1
Running "git checkout" on an unborn branch used to corrupt HEAD (regression in 1.7.10); this makes it error out. By Erik Faye-Lund * ef/checkout-empty: checkout: do not corrupt HEAD on empty repo
2012-05-10Merge branch 'js/checkout-detach-count'Libravatar Junio C Hamano1-6/+7
When checking out another commit from an already detached state, we used to report all commits that are not reachable from any of the refs as lossage, but some of them might be reachable from the new HEAD, and there is no need to warn about them. By Johannes Sixt * js/checkout-detach-count: checkout (detached): truncate list of orphaned commits at the new HEAD t2020-checkout-detach: check for the number of orphaned commits
2012-05-08checkout: do not corrupt HEAD on empty repoLibravatar Erik Faye-Lund1-1/+1
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>
2012-05-04checkout (detached): truncate list of orphaned commits at the new HEADLibravatar Johannes Sixt1-6/+7
When git checkout switches from a detached HEAD to any other commit, then all orphaned commits were listed in a warning: Warning: you are leaving 2 commits behind...: a5e5396 another fixup 6aa1af6 fixup foo But if the new commit is actually one from this list (6aa1af6 in this example), then the list in the warning can be truncated at the new HEAD, because history beginning at HEAD is not "left behind". This makes it so. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-16Merge branch 'jk/branch-quiet'Libravatar Junio C Hamano1-0/+1
Even with "-q"uiet option, "checkout" used to report setting up tracking. Also "branch" learns "-q"uiet option to squelch informational message. By Jeff King * jk/branch-quiet: teach "git branch" a --quiet option checkout: suppress tracking message with "-q"
2012-03-26checkout: suppress tracking message with "-q"Libravatar Jeff King1-0/+1
Like the "switched to..." message (which is already suppressed by "-q"), this message is purely informational. Let's silence it if the user asked us to be quiet. This patch is slightly more than a one-liner, because we have to teach create_branch to propagate the flag all the way down to install_branch_config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16Merge branch 'jc/checkout-out-of-unborn' into maintLibravatar Junio C Hamano1-0/+19
* jc/checkout-out-of-unborn: git checkout -b: allow switching out of an unborn branch
2012-02-12Merge branch 'jc/checkout-out-of-unborn'Libravatar Junio C Hamano1-0/+19
* jc/checkout-out-of-unborn: git checkout -b: allow switching out of an unborn branch
2012-02-06git checkout -b: allow switching out of an unborn branchLibravatar Junio C Hamano1-0/+19
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>
2012-01-16clone: print advice on checking out detached HEADLibravatar Nguyễn Thái Ngọc Duy1-15/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19Merge branch 'jc/checkout-m-twoway'Libravatar Junio C Hamano1-24/+36
* jc/checkout-m-twoway: checkout_merged(): squelch false warning from some gcc Test 'checkout -m -- path' checkout -m: no need to insist on having all 3 stages
2011-12-19Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-8/+7
* nd/resolve-ref: Rename resolve_ref() to resolve_ref_unsafe() Convert resolve_ref+xstrdup to new resolve_refdup function revert: convert resolve_ref() to read_ref_full()
2011-12-15checkout_merged(): squelch false warning from some gccLibravatar Junio C Hamano1-1/+1
gcc 4.6.2 (there may be others) does not realize that the variable "mode" can never be used uninitialized in this function and issues a false warning under -Wuninitialized option. Squelch it with an unnecessary initialization; it is not like a single assignment matters to the performance in this codepath that writes out to the filesystem with checkout_entry() anyway. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'nd/ignore-might-be-precious'Libravatar Junio C Hamano1-3/+8
* nd/ignore-might-be-precious: checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
2011-12-13Merge branch 'jn/branch-move-to-self'Libravatar Junio C Hamano1-4/+11
* jn/branch-move-to-self: Allow checkout -B <current-branch> to update the current branch branch: allow a no-op "branch -M <current-branch> HEAD"
2011-12-13Convert resolve_ref+xstrdup to new resolve_refdup functionLibravatar Nguyễn Thái Ngọc Duy1-8/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-3/+5
* nd/resolve-ref: Copy resolve_ref() return value for longer use Convert many resolve_ref() calls to read_ref*() and ref_exists() Conflicts: builtin/fmt-merge-msg.c builtin/merge.c refs.c
2011-12-06checkout -m: no need to insist on having all 3 stagesLibravatar Junio C Hamano1-24/+36
The content level merge machinery ll_merge() is prepared to merge correctly in "both sides added differently" case by using an empty blob as if it were the common ancestor. "checkout -m" could do the same, but didn't bother supporting it and instead insisted on having all three stages. Reported-by: Pete Harlan Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Copy resolve_ref() return value for longer useLibravatar Nguyễn Thái Ngọc Duy1-1/+3
resolve_ref() may return a pointer to a static buffer. Callers that use this value longer than a couple of statements should copy the value to avoid some hidden resolve_ref() call that may change the static buffer's value. The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c demonstrates this. The first call is in cmd_merge() branch = resolve_ref("HEAD", head_sha1, 0, &flag); Then deep in lookup_commit_or_die() a few lines after, resolve_ref() may be called again and destroy "branch". lookup_commit_or_die lookup_commit_reference lookup_commit_reference_gently parse_object lookup_replace_object do_lookup_replace_object prepare_replace_object for_each_replace_ref do_for_each_ref get_loose_refs get_ref_dir get_ref_dir resolve_ref All call sites are checked and made sure that xstrdup() is called if the value should be saved. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Merge branch 'nd/maint-ignore-exclude'Libravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-11-28Allow checkout -B <current-branch> to update the current branchLibravatar Jonathan Nieder1-4/+11
When on master, "git checkout -B master <commit>" is a more natural way to say "git reset --keep <commit>", which was originally invented for the exact purpose of moving to the named commit while keeping the local changes around. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28checkout,merge: disallow overwriting ignored files with --no-overwrite-ignoreLibravatar Nguyễn Thái Ngọc Duy1-3/+8
Ignored files usually are generated files (e.g. .o files) and can be safely discarded. However sometimes users may have important files in working directory, but still want a clean "git status", so they mark them as ignored files. But in this case, these files should not be overwritten without asking first. Enable this use case with --no-overwrite-ignore, where git only sees tracked and untracked files, no ignored files. Those who mix discardable ignored files with important ones may have to sort it out themselves. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-preciousLibravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-11-28checkout,merge: loosen overwriting untracked file check based on info/excludeLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Back in 1127148 (Loosen "working file will be lost" check in Porcelain-ish - 2006-12-04), git-checkout.sh learned to quietly overwrite ignored files. Howver the code only took .gitignore files into account. Standard ignored files include all specified in .gitignore files in working directory _and_ $GIT_DIR/info/exclude. This patch makes sure ignored files in info/exclude can also be overwritten automatically in the spirit of the original patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-13Convert many resolve_ref() calls to read_ref*() and ref_exists()Libravatar Nguyễn Thái Ngọc Duy1-2/+2
resolve_ref() may return a pointer to a static buffer, which is not safe for long-term use because if another resolve_ref() call happens, the buffer may be changed. Many call sites though do not care about this buffer. They simply check if the return value is NULL or not. Convert all these call sites to new wrappers to reduce resolve_ref() calls from 57 to 34. If we change resolve_ref() prototype later on to avoid passing static buffer out, this helps reduce changes. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17Merge branch 'jc/checkout-from-tree-keep-local-changes'Libravatar Junio C Hamano1-1/+5
* jc/checkout-from-tree-keep-local-changes: checkout $tree $path: do not clobber local changes in $path not in $tree
2011-10-13Merge branch 'rs/pending'Libravatar Junio C Hamano1-28/+18
* rs/pending: commit: factor out clear_commit_marks_for_object_array checkout: use leak_pending flag bundle: use leak_pending flag bisect: use leak_pending flag revision: add leak_pending flag checkout: use add_pending_{object,sha1} in orphan check revision: factor out add_pending_sha1 checkout: check for "Previous HEAD" notice in t2020 Conflicts: builtin/checkout.c revision.c
2011-10-10Merge branch 'mh/check-ref-format-3'Libravatar Junio C Hamano1-1/+1
* mh/check-ref-format-3: (23 commits) add_ref(): verify that the refname is formatted correctly resolve_ref(): expand documentation resolve_ref(): also treat a too-long SHA1 as invalid resolve_ref(): emit warnings for improperly-formatted references resolve_ref(): verify that the input refname has the right format remote: avoid passing NULL to read_ref() remote: use xstrdup() instead of strdup() resolve_ref(): do not follow incorrectly-formatted symbolic refs resolve_ref(): extract a function get_packed_ref() resolve_ref(): turn buffer into a proper string as soon as possible resolve_ref(): only follow a symlink that contains a valid, normalized refname resolve_ref(): use prefixcmp() resolve_ref(): explicitly fail if a symlink is not readable Change check_refname_format() to reject unnormalized refnames Inline function refname_format_print() Make collapse_slashes() allocate memory for its result Do not allow ".lock" at the end of any refname component Refactor check_refname_format() Change check_ref_format() to take a flags argument Change bad_ref_char() to return a boolean value ...
2011-10-05Change check_ref_format() to take a flags argumentLibravatar Michael Haggerty1-1/+1
Change check_ref_format() to take a flags argument that indicates what is acceptable in the reference name (analogous to "git check-ref-format"'s "--allow-onelevel" and "--refspec-pattern"). This is more convenient for callers and also fixes a failure in the test suite (and likely elsewhere in the code) by enabling "onelevel" and "refspec-pattern" to be allowed independently of each other. Also rename check_ref_format() to check_refname_format() to make it obvious that it deals with refnames rather than references themselves. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'jk/argv-array'Libravatar Junio C Hamano1-19/+8
* jk/argv-array: run_hook: use argv_array API checkout: use argv_array API bisect: use argv_array API quote: provide sq_dequote_to_argv_array refactor argv_array into generic code quote.h: fix bogus comment add sha1_array API docs
2011-10-03commit: factor out clear_commit_marks_for_object_arrayLibravatar René Scharfe1-7/+1
Factor out the code to clear the commit marks for a whole struct object_array from builtin/checkout.c into its own exported function clear_commit_marks_for_object_array and use it in bisect and bundle as well. It handles tags and commits and ignores objects of any other type. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-03checkout: use leak_pending flagLibravatar René Scharfe1-13/+12
Instead of going through all the references again when we clear the commit marks, do it like bisect and bundle and gain ownership of the list of pending objects which we constructed from those references. We simply copy the struct object_array that points to the list, set the flag leak_pending and then prepare_revision_walk won't destroy it and it's ours. We use it to clear the marks and free it at the end. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-03checkout: use add_pending_{object,sha1} in orphan checkLibravatar René Scharfe1-27/+12
Instead of building a list of textual arguments for setup_revisions, use add_pending_object and add_pending_sha1 to queue the objects directly. This is both faster and simpler. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-30checkout $tree $path: do not clobber local changes in $path not in $treeLibravatar Junio C Hamano1-1/+5
Checking paths out of a tree is (currently) defined to do: - Grab the paths from the named tree that match the given pathspec, and add them to the index; - Check out the contents from the index for paths that match the pathspec to the working tree; and while at it - If the given pathspec did not match anything, suspect a typo from the command line and error out without updating the index nor the working tree. Suppose that the branch you are working on has dir/myfile, and the "other" branch has dir/other but not dir/myfile. Further imagine that you have either modified or removed dir/myfile in your working tree, but you have not run "git add dir/myfile" or "git rm dir/myfile" to tell Git about your local change. Running $ git checkout other dir would add dir/other to the index with the contents taken out of the "other" branch, and check out the paths from the index that match the pathspec "dir", namely, "dir/other" and "dir/myfile", overwriting your local changes to "dir/myfile", even though "other" branch does not even know about that file. Fix it by updating the working tree only with the index entries that was read from the "other" tree. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-23Merge branch 'cb/maint-ls-files-error-report' into maintLibravatar Junio C Hamano1-3/+3
* cb/maint-ls-files-error-report: t3005: do not assume a particular order of stdout and stderr of git-ls-files ls-files: fix pathspec display on error
2011-09-16Merge branch 'ci/forbid-unwanted-current-branch-update'Libravatar Junio C Hamano1-1/+2
* ci/forbid-unwanted-current-branch-update: branch --set-upstream: regression fix
2011-09-16branch --set-upstream: regression fixLibravatar Junio C Hamano1-1/+2
The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-14checkout: use argv_array APILibravatar Jeff King1-19/+8
We were using a similar ad-hoc rev_list_args structure, but this saves some code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28Merge branch 'ci/forbid-unwanted-current-branch-update'Libravatar Junio C Hamano1-9/+3
* ci/forbid-unwanted-current-branch-update: Show interpreted branch name in error messages Prevent force-updating of the current branch
2011-08-23Merge branch 'cb/maint-ls-files-error-report'Libravatar Junio C Hamano1-3/+3
* cb/maint-ls-files-error-report: ls-files: fix pathspec display on error
2011-08-22Prevent force-updating of the current branchLibravatar Conrad Irwin1-9/+3
"git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-16Merge branch 'jc/checkout-reflog-fix' into maintLibravatar Junio C Hamano1-2/+5
* jc/checkout-reflog-fix: checkout: do not write bogus reflog entry out