summaryrefslogtreecommitdiff
path: root/builtin-checkout.c
AgeCommit message (Collapse)AuthorFilesLines
2009-03-23builtin-checkout: use warning() instead of fprintf(stderr, "warning: ")Libravatar Miklos Vajna1-2/+2
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20Merge branch 'mv/parseopt-ls-files'Libravatar Junio C Hamano1-1/+1
* mv/parseopt-ls-files: ls-files: fix broken --no-empty-directory t3000: use test_cmp instead of diff parse-opt: migrate builtin-ls-files. Turn the flags in struct dir_struct into a single variable Conflicts: builtin-ls-files.c t/t3000-ls-files-others.sh
2009-03-04Fix neglect of diff_setup()/diff_setup_done() symmetry.Libravatar Keith Cascio1-0/+2
Code that calls diff_setup(), including via init_revisions(), should later call diff_setup_done(), possibly via setup_revisions(). Failure to do so could cause errors, especially in the future when we add responsibilities to diff_setup_done(). This instance causes no known errors with the present code. But it resulted in an error with an experimental patch. Signed-off-by: Keith Cascio <keith@cs.ucla.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18Turn the flags in struct dir_struct into a single variableLibravatar Johannes Schindelin1-1/+1
By having flags represented as bits in the new member variable 'flags', it will be easier to use parse_options when dir_struct is involved. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-28Merge branch 'tr/previous-branch'Libravatar Junio C Hamano1-2/+13
* tr/previous-branch: t1505: remove debugging cruft Simplify parsing branch switching events in reflog Introduce for_each_recent_reflog_ent(). interpret_nth_last_branch(): plug small memleak Fix reflog parsing for a malformed branch switching entry Fix parsing of @{-1}@{1} interpret_nth_last_branch(): avoid traversing the reflog twice checkout: implement "-" abbreviation, add docs and tests sha1_name: support @{-N} syntax in get_sha1() sha1_name: tweak @{-N} lookup checkout: implement "@{-N}" shortcut name for N-th last branch Conflicts: sha1_name.c
2009-01-25Merge branch 'cb/add-pathspec'Libravatar Junio C Hamano1-3/+3
* cb/add-pathspec: remove pathspec_match, use match_pathspec instead clean up pathspec matching
2009-01-17checkout: implement "-" abbreviation, add docs and testsLibravatar Thomas Rast1-0/+3
Have '-' mean the same as '@{-1}', i.e., the last branch we were on. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17sha1_name: tweak @{-N} lookupLibravatar Thomas Rast1-1/+3
Have the lookup only look at "interesting" checkouts, meaning those that tell you "Already on ..." don't count even though they also cause a reflog entry. Let interpret_nth_last_branch() return the number of characters parsed, so that git-checkout can verify that the branch spec was @{-N}, not @{-1}^2 or something like that. (The latter will be added later.) Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17checkout: implement "@{-N}" shortcut name for N-th last branchLibravatar Junio C Hamano1-2/+8
Implement a shortcut @{-N} for the N-th last branch checked out, that works by parsing the reflog for the message added by previous git-checkout invocations. We expand the @{-N} to the branch name, so that you end up on an attached HEAD on that branch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17Move run_hook() from builtin-commit.c into run-command.c (libgit)Libravatar Stephan Beyer1-17/+5
A function that runs a hook is used in several Git commands. builtin-commit.c has the one that is most general for cases without piping. The one in builtin-gc.c prints some useful warnings. This patch moves a merged version of these variants into libgit and lets the other builtins use this libified run_hook(). The run_hook() function used in receive-pack.c feeds the standard input of the pre-receive or post-receive hooks. This function is renamed to run_receive_hook() because the libified run_hook() cannot handle this. Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17checkout: don't crash on file checkout before running post-checkout hookLibravatar Stephan Beyer1-2/+4
In the case of git init echo exit >.git/hooks/post-checkout chmod +x .git/hooks/post-checkout touch foo git add foo rm foo git checkout -- foo git-checkout resulted in a Segmentation fault, because there is no new branch set for the post-checkout hook. This patch makes use of the null SHA as it is set for the old branch. While at it, I removed the xstrdup() around the sha1_to_hex(...) calls in builtin-checkout.c/post_checkout_hook() because sha1_to_hex() uses four buffers for the hex-dumped SHA and we only need two. (Duplicating one buffer is only needed if we need more than four.) Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-14remove pathspec_match, use match_pathspec insteadLibravatar Clemens Buchacher1-3/+3
Both versions have the same functionality. This removes any redundancy. This also adds makes two extensions to match_pathspec: - If pathspec is NULL, return 1. This reflects the behavior of git commands, for which no paths usually means "match all paths". - If seen is NULL, do not use it. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-11Merge branch 'jc/maint-do-not-switch-to-non-commit' into maintLibravatar Junio C Hamano1-1/+1
* jc/maint-do-not-switch-to-non-commit: git checkout: do not allow switching to a tree-ish that is not a commit
2009-01-03Merge branch 'jc/maint-do-not-switch-to-non-commit'Libravatar Junio C Hamano1-1/+1
* jc/maint-do-not-switch-to-non-commit: git checkout: do not allow switching to a tree-ish that is not a commit
2009-01-03git checkout: do not allow switching to a tree-ish that is not a commitLibravatar Junio C Hamano1-1/+1
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch rooted at the current HEAD, because in that case, the two structure fields used to see if the command was invoked without any argument (hence it needs to default to checking out the HEAD) were populated incorrectly. Upon seeing a command line argument that we took as a rev, we should store that string in new.name, even if that does not name a commit. This will correctly trigger the existing safety logic. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
2008-12-07builtin-checkout.c: check error return from read_cache()Libravatar Junio C Hamano1-2/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-27Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: sha1_file.c: resolve confusion EACCES vs EPERM sha1_file: avoid bogus "file exists" error message git checkout: don't warn about unborn branch if -f is already passed bash: offer refs instead of filenames for 'git revert' bash: remove dashed command leftovers git-p4: fix keyword-expansion regex fast-export: use an unsorted string list for extra_refs Add new testcase to show fast-export does not always exports all tags
2008-11-27git checkout: don't warn about unborn branch if -f is already passedLibravatar Matt McCutchen1-1/+1
I think it's unnecessary to warn that the checkout has been forced due to an unborn current branch if -f has been explicitly passed. For one project, I am using git-new-workdir to create workdirs from a bare repository whose HEAD is set to an unborn branch, and this warning started to irritate me. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-12Merge branch 'maint'Libravatar Junio C Hamano1-2/+1
* maint: Start 1.6.0.5 cycle Fix pack.packSizeLimit and --max-pack-size handling checkout: Fix "initial checkout" detection Remove the period after the git-check-attr summary Conflicts: RelNotes
2008-11-12checkout: Fix "initial checkout" detectionLibravatar Junio C Hamano1-2/+1
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07) tightened the rule to prevent switching branches from losing local changes, so that staged removal of paths can be protected, while attempting to keep a loophole to still allow a special case of switching out of an un-checked-out state. However, the loophole was made a bit too tight, and did not allow switching from one branch (in an un-checked-out state) to check out another branch. The change to builtin-checkout.c in this commit loosens it to allow this, by not insisting the original commit and the new commit to be the same. It also introduces a new function, is_index_unborn (and an associated macro, is_cache_unborn), to check if the repository is truly in an un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE did not exist when populating the in-core index structure. A few places the earlier commit 5521883 added the check for the initial checkout condition are updated to use this function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-09Merge branch 'maint'Libravatar Junio C Hamano1-4/+4
* maint: Documentation: bisect: change a few instances of "git-cmd" to "git cmd" Documentation: rev-list: change a few instances of "git-cmd" to "git cmd" checkout: Don't crash when switching away from an invalid branch.
2008-11-09checkout: Don't crash when switching away from an invalid branch.Libravatar Alexandre Julliard1-4/+4
When using alternates, it is possible for HEAD to end up pointing to an invalid commit. git checkout should be able to recover from that situation without crashing. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-19Fix mismerge at cdb22c4 in builtin-checkout.cLibravatar Junio C Hamano1-3/+0
The code to complain when -b is not given but an explicit --track/--no-track override was given from the command line was unchanged on one branch and reworked on the other branch. The merge result incorrectly kept it. Spotted by Matt McCutchen. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-18Merge branch 'db/maint-checkout-b' into maintLibravatar Junio C Hamano1-0/+12
* db/maint-checkout-b: Check early that a new branch is new and valid
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-8/+4
Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06do not segfault if make_cache_entry failedLibravatar Dmitry Potapov1-0/+2
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-29Merge branch 'jc/better-conflict-resolution'Libravatar Shawn O. Pearce1-21/+173
* jc/better-conflict-resolution: Fix AsciiDoc errors in merge documentation git-merge documentation: describe how conflict is presented checkout --conflict=<style>: recreate merge in a non-default style checkout -m: recreate merge when checking out of unmerged index git-merge-recursive: learn to honor merge.conflictstyle merge.conflictstyle: choose between "merge" and "diff3 -m" styles rerere: understand "diff3 -m" style conflicts with the original rerere.c: use symbolic constants to keep track of parsing states xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less xmerge.c: minimum readability fixups xdiff-merge: optionally show conflicts in "diff3 -m" style xdl_fill_merge_buffer(): separate out a too deeply nested function checkout --ours/--theirs: allow checking out one side of a conflicting merge checkout -f: allow ignoring unmerged paths when checking out of the index Conflicts: Documentation/git-checkout.txt builtin-checkout.c builtin-merge-recursive.c t/t7201-co.sh
2008-09-25Merge branch 'mv/merge-recursive'Libravatar Shawn O. Pearce1-3/+8
* mv/merge-recursive: builtin-merge: release the lockfile in try_merge_strategy() merge-recursive: get rid of virtual_id merge-recursive: move current_{file,directory}_set to struct merge_options merge-recursive: move the global obuf to struct merge_options merge-recursive: get rid of the index_only global variable merge-recursive: move call_depth to struct merge_options cherry-pick/revert: make direct internal call to merge_tree() builtin-merge: avoid run_command_v_opt() for recursive and subtree merge-recursive: introduce merge_options merge-recursive.c: Add more generic merge_recursive_generic() Split out merge_recursive() to merge-recursive.c
2008-09-25Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* maint: Update release notes for 1.6.0.3 checkout: Do not show local changes when in quiet mode for-each-ref: Fix --format=%(subject) for log message without newlines git-stash.sh: don't default to refs/stash if invalid ref supplied maint: check return of split_cmdline to avoid bad config strings
2008-09-25checkout: Do not show local changes when in quiet modeLibravatar Jonas Fonseca1-1/+1
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-21Merge branch 'db/maint-checkout-b'Libravatar Junio C Hamano1-0/+12
* db/maint-checkout-b: Check early that a new branch is new and valid
2008-09-21Check early that a new branch is new and validLibravatar Daniel Barkalow1-0/+12
If you fail to update refs to change branches in checkout, your index and working tree are left already updated. We don't have an easy way to undo this, but at least we can check things that would make the creation of a new branch fail. These checks were in the shell version, and were lost in the C conversion. The messages are from the shell version, and should probably be made nicer. [jc: added test to t7201] Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-18Merge branch 'jc/maint-checkout-keep-remove' into maintLibravatar Junio C Hamano1-0/+2
* jc/maint-checkout-keep-remove: checkout: do not lose staged removal
2008-09-16Merge branch 'jc/maint-checkout-keep-remove'Libravatar Junio C Hamano1-0/+2
* jc/maint-checkout-keep-remove: checkout: do not lose staged removal
2008-09-10Merge branch 'jc/maint-checkout-fix' into maintLibravatar Junio C Hamano1-1/+28
* jc/maint-checkout-fix: checkout: do not check out unmerged higher stages randomly
2008-09-09checkout: do not lose staged removalLibravatar Junio C Hamano1-0/+2
The logic to checkout a different commit implements the safety to never lose user's local changes. For example, switching from a commit to another commit, when you have changed a path that is different between them, need to merge your changes to the version from the switched-to commit, which you may not necessarily be able to resolve easily. By default, "git checkout" refused to switch branches, to give you a chance to stash your local changes (or use "-m" to merge, accepting the risks of getting conflicts). This safety, however, had one deliberate hole since early June 2005. When your local change was to remove a path (and optionally to stage that removal), the command checked out the path from the switched-to commit nevertheless. This was to allow an initial checkout to happen smoothly (e.g. an initial checkout is done by starting with an empty index and switching from the commit at the HEAD to the same commit). We can tighten the rule slightly to allow this special case to pass, without losing sight of removal explicitly done by the user, by noticing if the index is truly empty when the operation begins. For historical background, see: http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646 This case is marked as *0* in the message, which both Linus and I said "it feels somewhat wrong but otherwise we cannot start from an empty index". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-07Merge branch 'jc/maint-checkout-fix'Libravatar Junio C Hamano1-1/+28
* jc/maint-checkout-fix: checkout: do not check out unmerged higher stages randomly Conflicts: t/t7201-co.sh
2008-09-03Merge branch 'maint'Libravatar Junio C Hamano1-6/+4
* maint: Start 1.6.0.2 maintenance cycle tests: use "git xyzzy" form (t7200 - t9001) tests: use "git xyzzy" form (t7000 - t7199) Fix passwd(5) ref and reflect that commit doens't use commit-tree improve handling of sideband message display tests: use "git xyzzy" form (t3600 - t6999) tests: use "git xyzzy" form (t0000 - t3599) checkout: fix message when leaving detached HEAD clone: fix creation of explicitly named target directory 'git foo' program identifies itself without dash in die() messages setup_git_directory(): fix move to worktree toplevel directory update-index: fix worktree setup Start conforming code to "git subcmd" style read-tree: setup worktree if merge is required grep: fix worktree setup diff*: fix worktree setup Conflicts: RelNotes t/t3900-i18n-commit.sh t/t7003-filter-branch.sh
2008-09-03checkout: fix message when leaving detached HEADLibravatar Jeff King1-6/+4
The shell version of git checkout would print: Previous HEAD position was 1234abcd... commit subject line when leaving a detached HEAD for another commit. Ths C version attempted to implement this, but got the condition wrong such that the behavior never triggered. This patch simplifies the conditions for showing the message to the ones used by the shell version: any time we are leaving a detached HEAD and the new and old commits are not the same (this suppresses it for the "git checkout -b new" case recommended when you enter the detached state). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-31checkout --conflict=<style>: recreate merge in a non-default styleLibravatar Junio C Hamano1-1/+9
This new option does essentially the same thing as -m option when checking unmerged paths out of the index, but it uses the specified style instead of configured merge.conflictstyle. Setting "merge.conflictstyle" to "diff3" is usually less useful than using the default "merge" style, because the latter allows a conflict that results by both sides changing the same region in a very similar way to get simplified substancially by reducing the common lines. However, when one side removed a group of lines (perhaps a function was moved to some other file) while the other side modified it, the default "merge" style does not give any clue as to why the hunk is left conflicting. You would need the original to understand what is going on. The recommended use would be not to set merge.conflictstyle variable so that you would usually use the default "merge" style conflict, and when the result in a path in a particular merge is too hard to understand, use "git checkout --conflict=diff3 $path" to check it out with the original to review what is going on. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30merge-recursive: introduce merge_optionsLibravatar Miklos Vajna1-3/+8
This makes it possible to avoid passing the labels of branches as arguments to merge_recursive(), merge_trees() and merge_recursive_generic(). It also takes care of subtree merge, output buffering, verbosity, and rename limits - these were global variables till now in merge-recursive.c. A new function, named init_merge_options(), is introduced as well, it clears the struct merge_info, then initializes with default values, finally updates the default values based on the config and environment variables. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30checkout -m: recreate merge when checking out of unmerged indexLibravatar Junio C Hamano1-2/+102
This teaches git-checkout to recreate a merge out of unmerged index entries while resolving conflicts. With this patch, checking out an unmerged path from the index now have the following possibilities: * Without any option, an attempt to checkout an unmerged path will atomically fail (i.e. no other cleanly-merged paths are checked out either); * With "-f", other cleanly-merged paths are checked out, and unmerged paths are ignored; * With "--ours" or "--theirs, the contents from the specified stage is checked out; * With "-m" (we should add "--merge" as synonym), the 3-way merge is recreated from the staged object names and checked out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30checkout --ours/--theirs: allow checking out one side of a conflicting mergeLibravatar Junio C Hamano1-1/+38
This lets you to check out 'our' (or 'their') version of an unmerged path out of the index while resolving conflicts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30checkout -f: allow ignoring unmerged paths when checking out of the indexLibravatar Junio C Hamano1-18/+23
Earlier we made "git checkout $pathspec" to atomically refuse the operation of $pathspec matched any path with unmerged stages. This patch allows: $ git checkout -f a b c to ignore, instead of error out on, such unmerged paths. The fix to prevent checkout of an unmerged path from random stages is still there. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30checkout: do not check out unmerged higher stages randomlyLibravatar Junio C Hamano1-1/+28
During a conflicted merge when you have unmerged stages for a path F in the index, if you said: $ git checkout F we rewrote F as many times as we have stages for it, and the last one (typically "theirs") was left in the work tree, without resolving the conflict. This fixes it by noticing that a specified pathspec pattern matches an unmerged path, and by erroring out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22Extend "checkout --track" DWIM to support more casesLibravatar Alex Riesen1-13/+13
The code handles additionally "refs/remotes/<something>/name", "remotes/<something>/name", and "refs/<namespace>/name". Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-11checkout --track: make up a sensible branch name if '-b' was omittedLibravatar Johannes Schindelin1-3/+18
What does the user most likely want with this command? $ git checkout --track origin/next Exactly. A branch called 'next', that tracks origin's branch 'next'. Make it so. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-24git-checkout: improve error messages, detect ambiguities.Libravatar Pierre Habouzit1-17/+65
The patch is twofold: it moves the option consistency checks just under the parse_options call so that it doesn't get in the way of the tree reference vs. pathspecs desambiguation. The other part rewrites the way to understand arguments so that when git-checkout fails it does with an understandable message. Compared to the previous behavior we now have: - a better error message when doing: git checkout <blob reference> -- now complains about the reference not pointing to a tree, instead of things like: error: pathspec <blob reference> did not match any file(s) known to git. error: pathspec '--' did not match any file(s) known to git. - a better error message when doing: git checkout <path> -- It now complains about <path> not being a reference instead of the completely obscure: error: pathspec '--' did not match any file(s) known to git. - an error when -- wasn't used, and the first argument is ambiguous (i.e. can be interpreted as both ref and as path). Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23Merge branch 'maint' into ph/checkoutLibravatar Junio C Hamano1-1/+2
* maint: git-checkout: fix command line parsing.
2008-07-23git-checkout: fix command line parsing.Libravatar Pierre Habouzit1-1/+2
This fixes an issue when you use: $ git checkout -- <path1> [<paths>...] and that <path1> can also be understood as a reference. git-checkout mistakenly understands this as the same as: $ git checkout <path1> -- [<paths>...] because parse-options was eating the '--' and the argument parser thought he was parsing: $ git checkout <path1> [<paths>...] Where there indeed is an ambiguity Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>