summaryrefslogtreecommitdiff
path: root/builtin-checkout.c
AgeCommit message (Collapse)Author
2009-01-28Merge branch 'tr/previous-branch'Junio C Hamano
* 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-26Merge branch 'cb/add-pathspec'Junio C Hamano
* cb/add-pathspec: remove pathspec_match, use match_pathspec instead clean up pathspec matching
2009-01-18checkout: implement "-" abbreviation, add docs and testsThomas Rast
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-18sha1_name: tweak @{-N} lookupThomas Rast
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-18checkout: implement "@{-N}" shortcut name for N-th last branchJunio C Hamano
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-18Move run_hook() from builtin-commit.c into run-command.c (libgit)Stephan Beyer
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-18checkout: don't crash on file checkout before running post-checkout hookStephan Beyer
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-15remove pathspec_match, use match_pathspec insteadClemens Buchacher
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-12Merge branch 'jc/maint-do-not-switch-to-non-commit' into maintJunio C Hamano
* 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'Junio C Hamano
* 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 commitJunio C Hamano
"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-08builtin-checkout.c: check error return from read_cache()Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-28Merge branch 'maint'Junio C Hamano
* 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-28git checkout: don't warn about unborn branch if -f is already passedMatt McCutchen
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'Junio C Hamano
* 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" detectionJunio C Hamano
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'Junio C Hamano
* 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.Alexandre Julliard
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.cJunio C Hamano
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 maintJunio C Hamano
* 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 initializerBrandon Casey
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 failedDmitry Potapov
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'Shawn O. Pearce
* 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'Shawn O. Pearce
* 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'Shawn O. Pearce
* 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 modeJonas Fonseca
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-22Merge branch 'db/maint-checkout-b'Junio C Hamano
* db/maint-checkout-b: Check early that a new branch is new and valid
2008-09-22Check early that a new branch is new and validDaniel Barkalow
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-19Merge branch 'jc/maint-checkout-keep-remove' into maintJunio C Hamano
* jc/maint-checkout-keep-remove: checkout: do not lose staged removal
2008-09-16Merge branch 'jc/maint-checkout-keep-remove'Junio C Hamano
* jc/maint-checkout-keep-remove: checkout: do not lose staged removal
2008-09-10Merge branch 'jc/maint-checkout-fix' into maintJunio C Hamano
* jc/maint-checkout-fix: checkout: do not check out unmerged higher stages randomly
2008-09-10checkout: do not lose staged removalJunio C Hamano
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-08Merge branch 'jc/maint-checkout-fix'Junio C Hamano
* jc/maint-checkout-fix: checkout: do not check out unmerged higher stages randomly Conflicts: t/t7201-co.sh
2008-09-03Merge branch 'maint'Junio C Hamano
* 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 HEADJeff King
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-09-01checkout --conflict=<style>: recreate merge in a non-default styleJunio C Hamano
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-31merge-recursive: introduce merge_optionsMiklos Vajna
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-31checkout -m: recreate merge when checking out of unmerged indexJunio C Hamano
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-31checkout --ours/--theirs: allow checking out one side of a conflicting mergeJunio C Hamano
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-31checkout -f: allow ignoring unmerged paths when checking out of the indexJunio C Hamano
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 randomlyJunio C Hamano
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-23Extend "checkout --track" DWIM to support more casesAlex Riesen
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 omittedJohannes Schindelin
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-25git-checkout: improve error messages, detect ambiguities.Pierre Habouzit
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-24Merge branch 'maint' into ph/checkoutJunio C Hamano
* maint: git-checkout: fix command line parsing.
2008-07-23git-checkout: fix command line parsing.Pierre Habouzit
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>
2008-07-15add context pointer to read_tree_recursive()René Scharfe
Add a pointer parameter to read_tree_recursive(), which is passed to the callback function. This allows callers of read_tree_recursive() to share data with the callback without resorting to global variables. All current callers pass NULL. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-03Refactor "tracking statistics" code used by "git checkout"Junio C Hamano
People seem to like "Your branch is ahead by N commit" report made by "git checkout", but the interface into the statistics function was a bit clunky. This splits the function into three parts: * The core "commit counting" function that takes "struct branch" and returns number of commits to show if we are ahead, behind or forked; * Convenience "stat formating" function that takes "struct branch" and formats the report into a given strbuf, using the above function; * "checkout" specific function that takes "branch_info" (type that is internal to checkout implementation), calls the above function and print the formatted result. in the hope that the former two can be more easily reusable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-30checkout: "best effort" checkoutJunio C Hamano
When unpack_trees() returned an error while switching branches, we used to stop right there, exiting without writing the index out or switching HEAD. This is Ok when unpack_trees() returned an error because it detected untracked files or locally modified paths that could be overwritten by branch switching, because that error return is done before we start to modify the work tree. But it is undesirable if unpack_trees() already started to update the work tree and a failure is returned because some but not all paths are updated in the work tree, perhaps because a directory that some files need to go in was read-only by mistake, or a file that will be overwritten by branch switching had a mandatory lock on it and we failed to unlink it. This changes the behaviour upon such an error to complete the branch switching; the files updated in the work tree will hopefully be much more consistent with the index and HEAD derived from the switched-to branch. We still issue error messages, and exit the command with non-zero status, so scripted callers need to notice it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-30checkout: consolidate reset_{to_new,clean_to_new}()Junio C Hamano
These two were very similar functions with only tiny bit of difference. Signed-off-by: Junio C Hamano <gitster@pobox.com>