summaryrefslogtreecommitdiff
path: root/builtin-checkout.c
AgeCommit message (Collapse)AuthorFilesLines
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-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-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-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-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-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-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-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-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-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>
2008-07-15add context pointer to read_tree_recursive()Libravatar René Scharfe1-2/+2
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-02Refactor "tracking statistics" code used by "git checkout"Libravatar Junio C Hamano1-88/+6
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-29checkout: "best effort" checkoutLibravatar Junio C Hamano1-4/+18
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-29checkout: consolidate reset_{to_new,clean_to_new}()Libravatar Junio C Hamano1-35/+15
These two were very similar functions with only tiny bit of difference. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28checkout: make reset_clean_to_new() not die by itselfLibravatar Junio C Hamano1-3/+6
Instead, have its error percolate up through the callchain and let it be the exit status of the main command. No semantic changes yet. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28"git checkout -- paths..." should error out when paths cannot be writtenLibravatar Junio C Hamano1-2/+5
When "git checkout -- paths..." cannot update work tree for whatever reason, checkout_entry() correctly issued an error message for the path to the end user, but the command ignored the error, causing the entire command to succeed. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Merge branch 'js/config-cb'Libravatar Junio C Hamano1-1/+1
* js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
2008-05-25Merge branch 'jc/unpack-trees-reword'Libravatar Junio C Hamano1-0/+2
* jc/unpack-trees-reword: unpack-trees: allow Porcelain to give different error messages
2008-05-19unpack-trees: allow Porcelain to give different error messagesLibravatar Junio C Hamano1-0/+2
The plumbing output is sacred as it is an API. We _could_ change it if it is broken in such a way that it cannot convey necessary information fully, but we just do not _reword_ for the sake of rewording. If somebody does not like it, s/he is complaining too late. S/he should have been here in early May 2005 and make the language used by the API closer to what humans read. S/he wasn't here. Too bad, and it is too late. And people who complain should look at a bigger picture. Look at what was suggested by one of them and think for five seconds: $ git checkout mytopic -fatal: Entry 'frotz' not uptodate. Cannot merge. +fatal: Entry 'frotz' has local changes. Cannot merge. If you do not see something wrong with this output, your brain has already been rotten with use of git for too long a time. Nobody asked us to "merge" but why are we talking about "Cannot merge"? This patch introduces a mechanism to allow Porcelains to specify messages that are different from the ones that is given by the underlying plumbing implementation of read-tree, so that we can reword the message Porcelains give without disrupting the output from the plumbing. $ git-checkout pu error: You have local changes to 'Makefile'; cannot switch branches. There are other places that ask unpack_trees() to n-way merge, detect issues and let it issue error message on its own, but I did this as a demonstration and replaced only one message. Yes I know about C99 structure initializers. I'd love to use them but we try to be nice to compilers without it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-14Provide git_config with a callback-data parameterLibravatar Johannes Schindelin1-1/+1
git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Extend interface of add_files_to_cache to allow ignore indexing errorsLibravatar Alex Riesen1-1/+1
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-03Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: checkout: don't rfc2047-encode oneline on detached HEAD filter-branch: Documentation fix.
2008-05-03checkout: don't rfc2047-encode oneline on detached HEADLibravatar Jeff King1-1/+1
When calling pretty_print_commit, there is an implicit assumption that passing in a non-NULL "subject" variable for oneline or email formats means that the output is part of a subject and therefore "subject" to rfc2047 encoding. This is not the desired effect when reporting the movement of detached HEAD. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-27git checkout: add -t alias for --trackLibravatar Miklos Vajna1-1/+1
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-09Make 'unpack_trees()' have a separate source and destination indexLibravatar Linus Torvalds1-3/+6
We will always unpack into our own internal index, but we will take the source from wherever specified, and we will optionally write the result to a specified index (optionally, because not everybody even _wants_ any result: the index diffing really wants to just walk the tree and index in parallel). This ends up removing a fair number more lines than it adds, for the simple reason that we can now skip all the crud that tried to be oh-so-careful about maintaining our position in the index as we were traversing and modifying it. Since we don't actually modify the source index any more, we can just update the 'o->pos' pointer without worrying about whether an index entry got removed or replaced or added to. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-09Make 'unpack_trees()' take the index to work on as an argumentLibravatar Linus Torvalds1-0/+6
This is just a very mechanical conversion, and makes everybody set it to '&the_index' before calling, but at least it makes it more explicit where we work with the index. The next stage would be to split that index usage up into a 'source' and a 'destination' index, so that we can unpack into a different index than we started out from. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-02cleanup: remove unused git_checkout_configLibravatar Denis Cheng1-6/+1
Directly call git_default_config instead. Signed-off-by: Denis Cheng <crquan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-29Write index file on any checkout of filesLibravatar Daniel Barkalow1-15/+15
We need to rewrite the index file when we check out files, even if we haven't modified the blob info by reading from another tree, so that we get the stat cache to include the fact that we just modified the file so it doesn't need to be refreshed. While we're at it, move everything that needs to be done to check out some paths from a tree (or the current index) into checkout_paths(). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-29Fix builtin checkout crashing when given an invalid pathLibravatar Alex Riesen1-0/+4
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'js/branch-track'Libravatar Junio C Hamano1-9/+5
* js/branch-track: doc: documentation update for the branch track changes branch: optionally setup branch.*.merge from upstream local branches Conflicts: Documentation/config.txt Documentation/git-branch.txt Documentation/git-checkout.txt builtin-branch.c cache.h t/t7201-co.sh
2008-02-24checkout: error out when index is unmerged even with -mLibravatar Junio C Hamano1-17/+18
Even when -m is given to allow fallilng back to 3-way merge while switching branches, we should refuse if the original index is unmerged. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-23checkout: show progress when checkout takes long time while switching branchesLibravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-21checkout: updates to tracking reportLibravatar Junio C Hamano1-5/+5
Ask branch_get() for the new branch explicitly instead of letting it return a potentially stale information. Tighten the logic to find the tracking branch to deal better with misconfigured repositories (i.e. branch.*.merge can exist but it may not have a refspec that fetches to .it) Also fixes grammar in a message, as pointed out by Jeff King. The function is about reporting and not automatically fast-forwarding to the upstream, so stop calling it "adjust-to". Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-21builtin-checkout.c: Remove unused prefix arguments in switch_branches pathLibravatar Daniel Barkalow1-6/+4
This path doesn't actually care where in the tree you started out, since it must change the whole thing anyway. With the gratuitous bug removed, the argument is unused. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20checkout: work from a subdirectoryLibravatar Junio C Hamano1-1/+0
When switching branches from a subdirectory, checkout rewritten in C extracted the toplevel of the tree in there. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20checkout: tone down the "forked status" diagnostic messagesLibravatar Junio C Hamano1-40/+64
When checking out a branch that is behind or forked from a branch you are building on top of, we used to show full left-right log but if you already _know_ you have long history since you forked, it is a bit too much. This tones down the message quite a bit, by only showing the number of commits each side has since they diverged. Also the message is not shown at all under --quiet. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19branch: optionally setup branch.*.merge from upstream local branchesLibravatar Jay Soffian1-9/+5
"git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19Clean up reporting differences on branch switchLibravatar Daniel Barkalow1-71/+7
This also changes it such that: $ git checkout will give the same information without changing branches. This is good for finding out if the fetch you did recently had anything to say about the branch you've been on, whose name you don't remember at the moment. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-18builtin-checkout.c: fix possible usage segfaultLibravatar Jay Soffian1-0/+1
Not terminating the options[] array with OPT_END can cause usage ("git checkout -h") output to segfault. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-16checkout: notice when the switched branch is behind or forkedLibravatar Junio C Hamano1-0/+136
When you are switching to a branch that is marked to merge from somewhere else, e.g. when you have: [branch "next"] remote = upstream merge = refs/heads/next [remote "upstream"] url = ... fetch = refs/heads/*:refs/remotes/linus/* and you say "git checkout next", the branch you checked out may be behind, and you may want to update from the upstream before continuing to work. This patch makes the command to check the upstream (in this example, "refs/remotes/linus/next") and our branch "next", and: (1) if they match, nothing happens; (2) if you are ahead (i.e. the upstream is a strict ancestor of you), one line message tells you so; (3) otherwise, you are either behind or you and the upstream have forked. One line message will tell you which and then you will see a "log --pretty=oneline --left-right". We could enhance this with an option that tells the command to check if there is no local change, and automatically fast forward when you are truly behind. But I ripped out that change because I was unsure what the right way should be to allow users to control it (issues include that checkout should not become automatically interactive). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-16Build in checkoutLibravatar Daniel Barkalow1-0/+477
The only differences in behavior should be: - git checkout -m with non-trivial merging won't print out merge-recursive messages (see the change in t7201-co.sh) - git checkout -- paths... will give a sensible error message if HEAD is invalid as a commit. - some intermediate states which were written to disk in the shell version (in particular, index states) are only kept in memory in this version, and therefore these can no longer be revealed by later write operations becoming impossible. - when we change branches, we discard MERGE_MSG, SQUASH_MSG, and rr-cache/MERGE_RR, like reset always has. I'm not 100% sure I got the merge recursive setup exactly right; the base for a non-trivial merge in the shell code doesn't seem theoretically justified to me, but I tried to match it anyway, and the tests all pass this way. Other than these items, the results should be identical to the shell version, so far as I can tell. [jc: squashed lock-file fix from Dscho in] Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>