summaryrefslogtreecommitdiff
path: root/git-checkout.sh
Commit message (Collapse)AuthorAgeFilesLines
* Fix "git checkout -b foo ':/substring'"Junio C Hamano2008-02-011-3/+4
| | | | | | | | | | Because ':/substring' extended SHA1 expression cannot take postfix modifiers such as ^{tree} and ^{commit}, we would need to do it in multiple steps. With the patch, you can start a new branch from a randomly-picked commit whose message has the named string in it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix a typo in checkout.sh and cleanup one-line help messagesJohannes Sixt2007-12-111-4/+4
| | | | | | | This also shortens option descriptions to fit in 80 columns. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git checkout's reflog: even when detaching the HEAD, say from whereJohannes Schindelin2007-11-281-2/+3
| | | | | | | | | | When checking out another ref, the reflogs already record from which branch you switched. Do that also when switching to a detached HEAD. While at it, record also when coming _from_ a detached HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2007-11-251-1/+1
|\ | | | | | | | | | | | | | | | | * maint: user-manual: recovering from corruption user-manual: clarify language about "modifying" old commits user-manual: failed push to public repository user-manual: define "branch" and "working tree" at start git-checkout: describe detached head correctly
| * git-checkout: describe detached head correctlyJunio C Hamano2007-11-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | When you have a file called HEAD in the work tree, the code to report where the HEAD is at when "git checkout $commit^0" is done triggered unnecessary ambiguity checking. Explicitly mark the command line with "--" and make it clear that we are talking about a revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ds/checkout-upper'Junio C Hamano2007-11-181-3/+3
|\ \ | | | | | | | | | | | | | | | * ds/checkout-upper: git-checkout: Test for relative path use. git-checkout: Support relative paths containing "..".
| * | git-checkout: Support relative paths containing "..".David Symonds2007-11-111-3/+3
| | | | | | | | | | | | | | | Signed-off-by: David Symonds <dsymonds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdashPierre Habouzit2007-11-051-50/+49
|/ / | | | | | | | | | | Also fix some space versus tabs issues. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | post-checkout hook, tests, and docsJosh England2007-09-291-0/+12
|/ | | | | | | | Updated post-checkout hook to take a flag specifying whether the checkout is a branch checkout or a file checkout (from the index). Signed-off-by: Josh England <jjengla@sandia.gov> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Alter git-checkout reflog message to include "from" branchSean2007-07-041-1/+2
| | | | | | | | | | As suggested by Junio, adding the current branch name to the reflog message for git-checkout would be helpful. For example: "checkout: moving from next to master" Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-021-20/+20
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2007-06-081-1/+2
|\ | | | | | | | | * maint: checkout: do not get confused with ambiguous tag/branch names
| * checkout: do not get confused with ambiguous tag/branch namesJunio C Hamano2007-06-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although it is not advisable, we have always allowed a branch and a tag to have the same basename (i.e. it is not illegal to have refs/heads/frotz and refs/tags/frotz at the same time). When talking about a specific commit, the interpretation of 'frotz' has always been "use tag and then check branch", although we warn when ambiguities exist. However "git checkout $name" is defined to (1) first see if it matches the branch name, and if so switch to that branch; (2) otherwise it is an instruction to detach HEAD to point at the commit named by $name. We did not follow this definition when $name appeared under both refs/heads/ and refs/tags/ -- we switched to the branch but read the tree from the tagged commit, which was utterly bogus. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | War on whitespaceJunio C Hamano2007-06-071-2/+2
| | | | | | | | | | | | | | | | | | This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-update-ref: add --no-deref option for overwriting/detaching refSven Verdoolaege2007-05-101-9/+1
|/ | | | | | | | git-checkout is also adapted to make use of this new option instead of the handcrafted command sequence. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* add file checkout progressNicolas Pitre2007-04-231-3/+5
| | | | | | | | | | It is nice to see what is happening when checking out large amount of files, either with git-checkout or git-reset. The new progress code already decides what is a "significant amount" and displays progress only in that case.. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* checkout: allow detaching to HEAD even when switching to the tip of a branchJunio C Hamano2007-04-031-2/+2
| | | | | | | | | | | | You cannot currently checkout the tip of an existing branch without moving to the branch. This allows you to detach your HEAD and place it at such a commit, with: $ git checkout master^0 Signed-off-by: Junio C Hamano <junkio@cox.net>
* checkout: report where the new HEAD is upon detaching HEADJunio C Hamano2007-03-231-2/+10
| | | | | | | | | After "git reset" moves the HEAD around, it reports which commit you are on, which gives the user a warm fuzzy feeling of assurance. Give the same assurance from git-checkout when moving the detached HEAD around. Signed-off-by: Junio C Hamano <junkio@cox.net>
* improve checkout message when asking for same branchNicolas Pitre2007-03-201-1/+6
| | | | | | | | Change the feedback message if doing 'git checkout foo' when already on branch "foo". Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch, git-branch: Support local --track via a special remote '.'Paolo Bonzini2007-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for a dummy remote '.' to avoid having to declare a fake remote like [remote "local"] url = . fetch = refs/heads/*:refs/heads/* Such a builtin remote simplifies the operation of "git-fetch", which will populate FETCH_HEAD but will not pretend that two repositories are in use, will not create a thin pack, and will not perform any useless remapping of names. The speed improvement is around 20%, and it should improve more if "git-fetch" is converted to a builtin. To this end, git-parse-remote is grown with a new kind of remote, 'builtin'. In git-fetch.sh, we treat the builtin remote specially in that it needs no pack/store operations. In fact, doing git-fetch on a builtin remote will simply populate FETCH_HEAD appropriately. The patch also improves of the --track/--no-track support, extending it so that branch.<name>.remote items referring '.' can be created. Finally, it fixes a typo in git-checkout.sh. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge GIT 1.5.0.4Junio C Hamano2007-03-141-1/+1
|\
| * git-checkout: fix "eval" used for merge labelling.Junio C Hamano2007-03-141-1/+1
| | | | | | | | | | | | | | | | The symbolic notation of the fork point can contain whitespaces (e.g. "git checkout -m 'HEAD@{9 hours ago}'"). Quote strings properly when using eval to prepare GITHEAD_$new Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-branch, git-checkout: autosetup for remote branch trackingPaolo Bonzini2007-03-101-6/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | In order to track and build on top of a branch 'topic' you track from your upstream repository, you often would end up doing this sequence: git checkout -b mytopic origin/topic git config --add branch.mytopic.remote origin git config --add branch.mytopic.merge refs/heads/topic This would first fork your own 'mytopic' branch from the 'topic' branch you track from the 'origin' repository; then it would set up two configuration variables so that 'git pull' without parameters does the right thing while you are on your own 'mytopic' branch. This commit adds a --track option to git-branch, so that "git branch --track mytopic origin/topic" performs the latter two actions when creating your 'mytopic' branch. If the configuration variable branch.autosetupmerge is set to true, you do not have to pass the --track option explicitly; further patches in this series allow setting the variable with a "git remote add" option. The configuration variable is off by default, and there is a --no-track option to countermand it even if the variable is set. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Let git-checkout always drop any detached headNicolas Pitre2007-02-031-15/+2
| | | | | | | | | | | | | | | | | | We used to refuse leaving a detached HEAD when it wasn't matching an existing ref so not to lose any commit that might have been performed while not on any branch (unless -f was provided). But this protection was completely bogus since it was still possible to move to HEAD^ while still remaining detached but losing the last commit anyway if there was one. Now that we have a proper reflog for HEAD it is best to simply remove that bogus (and admitedly annoying) protection and simply display the last HEAD position instead. If one wants to recover a lost detached state then it can be retrieved from the HEAD reflog. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'master' into np/dreflogJunio C Hamano2007-02-031-9/+20
|\ | | | | | | | | | | | | | | | | This is to resolve conflicts early in preparation for possible inclusion of "reflog on detached HEAD" series by Nico, as having it in 1.5.0 would really help us remove confusion between detached and attached states. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * add a quiet option to git-checkoutNicolas Pitre2007-02-011-9/+14
| | | | | | | | | | | | | | | | Those new messages are certainly nice, but there might be cases where they are simply unwelcome, like when git-commit is used within scripts. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * reword the detached head message a little againNicolas Pitre2007-02-011-1/+1
| | | | | | | | | | | | | | Seems clearer this way, to me at least. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * detached HEAD -- finishing touchesJunio C Hamano2007-02-011-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates "git-checkout" to report which branch you are switching to. Especially for people who do not use __git_ps1 from contrib/completion/git-completion.bash this would give a friendlier feedback of what is going on, and should make the reminder message much less scary. Here is a sample session (the prompt tells which branch I am on). * I have some local modification and realize that the change deserves to be on its own new topic branch. [git.git (master)]$ git diff --stat git-checkout.sh | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) * So I switch to a new branch. I get a listing of local modifications and assuring "Switched to a new branch" message. [git.git (master)]$ git checkout -b jc/checkout M git-checkout.sh Switched to a new branch "jc/checkout" * If I switch back to "master", I get essentially the same. [git.git (jc/checkout)]$ git checkout master M git-checkout.sh Switched to branch "master" * Detaching head would say which commit I am at and reminds me that I am not on any branch (not that I would detach my HEAD while keeping precious local changes around in any real-world workflow -- this is just a sample session). [git.git (master)]$ git checkout master^ M git-checkout.sh Note: you are not on any branch and are at commit "master^" If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new_branch_name> * Coming back to an attached state can lose the detached HEAD, so I get warned and stopped. [git.git]$ git checkout master You are not on any branch and switching to branch 'master' may lose your changes. At this point, you can do one of two things: (1) Decide it is Ok and say 'git checkout -f master'; (2) Start a new branch from the current commit, by saying 'git checkout -b <branch-name>'. Leaving your HEAD detached; not switching to branch 'master'. * Moving around while my HEAD is detached is Ok. I still get the list of local modifications. [git.git]$ git checkout master^0 M git-checkout.sh * The previous step that switched to the tip commit is an obscure but useful trick. My HEAD is still detached but now it is pointed at by an existing ref, so I can come back safely. [git.git]$ git checkout master M git-checkout.sh Switched to branch "master" * And we are back on the "master" branch. [git.git (master)]$ exit Signed-off-by: Junio C Hamano <junkio@cox.net>
| * tone down the detached head warningNicolas Pitre2007-01-311-3/+3
| | | | | | | | | | | | | | | | | | This is not meant to frighten people or even to suggest they might be doing something wrong, but rather to notify them of a state change and provide a likely option in the case this state was entered by mistake. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | add reflog when moving HEAD to a new branchNicolas Pitre2007-01-281-1/+1
| | | | | | | | | | Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | add reflog entries for HEAD when detachedNicolas Pitre2007-01-281-2/+3
|/ | | | | Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* fix suggested branch creation command when detaching headNicolas Pitre2007-01-261-3/+3
| | | | | | | | | | | | | | | | | | | | Doing: $ git checkout HEAD^ Generates the following message: |warning: you are not on ANY branch anymore. |If you meant to create a new branch from the commit, you need -b to |associate a new branch with the wanted checkout. Example: | git checkout -b <new_branch_name> HEAD^ Of course if the user does as told at this point the created branch won't be located at the expected commit. Reword this message a bit to avoid such confusion. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-checkout -m: fix merge caseJunio C Hamano2007-01-231-10/+5
| | | | | | | | | | Commit c1a4278e switched the "merging checkout" implementation from 3-way read-tree to merge-recursive, but forgot that merge-recursive will signal an unmerged state with its own exit status code. This prevented the clean-up phase (paths cleanly merged should not be updated in the index) from running. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use merge-recursive in git-checkout -m (branch switching)Junio C Hamano2007-01-161-2/+3
| | | | | | | This allows "git checkout -m <other-branch>" to notice renames and carry local changes in the working tree forward. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use cd_to_toplevel in scripts that implement it by hand.Junio C Hamano2007-01-121-5/+1
| | | | | | | | | | This converts scripts that do "cd $(rev-parse --show-cdup)" by hand to use cd_to_toplevel. I think git-fetch does not have to go to the toplevel, but that should be dealt with in a separate patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'jc/bare'Junio C Hamano2007-01-111-0/+1
|\ | | | | | | | | | | | | | | * jc/bare: Disallow working directory commands in a bare repository. git-fetch: allow updating the current branch in a bare repository. Introduce is_bare_repository() and core.bare configuration variable Move initialization of log_all_ref_updates
| * Disallow working directory commands in a bare repository.Shawn O. Pearce2007-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user tries to run a porcelainish command which requires a working directory in a bare repository they may get unexpected results which are difficult to predict and may differ from command to command. Instead we should detect that the current repository is a bare repository and refuse to run the command there, as there is no working directory associated with it. [jc: updated Shawn's original somewhat -- bugs are mine.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-checkout: handle local changes sanely when detaching HEADJunio C Hamano2007-01-091-11/+25
| | | | | | | | | | | | | | | | | | | | When switching branches, we usually first try read-tree to make sure that we do not lose the local changes and then updated the HEAD using update-ref. However, we detached and updated HEAD before these checks, which was quite bad in a repository with local changes. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-checkout: safety check for detached HEAD checks existing refsJunio C Hamano2007-01-091-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | Checking for reachability from refs does not help much if the state we are currently on is somewhere in the middle. We will lose where we were. So this makes sureh that HEAD is something directly pointed at by one of the existing refs (most likely a tag for a user who has been "sightseeing"). Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-checkout: fix branch name output from the commandJunio C Hamano2007-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | When switching branches with "git checkout", we internally did $arg^0 (aka $arg^{commit}) suffix but there was no need to. The improvement is easily visible in the change to an existing test t/3200-branch.sh in this commit; it was expecting rather ugly message. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-checkout: safety when coming back from the detached HEAD state.Junio C Hamano2007-01-081-0/+18
| | | | | | | | | | | | | | | | | | After making commits in the detached HEAD state, if you run "git checkout" to switch to an existing branch, you will lose your work. Make sure the switched-to branch is a fast-forward of the current HEAD, or require -f when switching. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-checkout: rewording comments regarding detached HEAD.Junio C Hamano2007-01-081-9/+12
| | | | | | | | | | | | | | | | We used to say "you are not on a branch" before the initial commit. This is incorrect -- the user is on a branch yet to be born, but its name has been already determined. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-checkout: do not warn detaching HEAD when it is already detached.Junio C Hamano2007-01-081-3/+8
| | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Detached HEAD (experimental)Junio C Hamano2007-01-081-5/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows "git checkout v1.4.3" to dissociate the HEAD of repository from any branch. After this point, "git branch" starts reporting that you are not on any branch. You can go back to an existing branch by saying "git checkout master", for example. This is still experimental. While I think it makes sense to allow commits on top of detached HEAD, it is rather dangerous unless you are careful in the current form. Next "git checkout master" will obviously lose what you have done, so we might want to require "git checkout -f" out of a detached HEAD if we find that the HEAD commit is not an ancestor of any other branches. There is no such safety valve implemented right now. On the other hand, the reason the user did not start the ad-hoc work on a new branch with "git checkout -b" was probably because the work was of a throw-away nature, so the convenience of not having that safety valve might be even better. The user, after accumulating some commits on top of a detached HEAD, can always create a new branch with "git checkout -b" not to lose useful work done while the HEAD was detached. We'll see. Signed-off-by: Junio C Hamano <junkio@cox.net>
* checkout: make the message about the need for a new branch a bit clearerNicolas Pitre2006-12-221-2/+5
| | | | | Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Loosen "working file will be lost" check in Porcelain-ishJunio C Hamano2006-12-051-2/+3
| | | | | | | | This uses the previous update to read-tree in Porcelain-ish commands "git checkout" and "git merge" to loosen the check when switching branches. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-checkout: allow pathspec to recover lost working tree directoryJunio C Hamano2006-11-151-1/+5
| | | | | | | | | | | | | It is often wanted on the #git channel that this were to work to recover removed directory: rm -fr Documentation git checkout -- Documentation git checkout HEAD -- Documentation ;# alternatively Now it does. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-checkout: do not allow -f and -m at the same time.Junio C Hamano2006-11-151-0/+5
| | | | | | | Instead of silently ignoring one over the other, complain on this incompatible combination. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'master' into lj/refsJunio C Hamano2006-09-271-1/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * master: (72 commits) runstatus: do not recurse into subdirectories if not needed grep: fix --fixed-strings combined with expression. grep: free expressions and patterns when done. Corrected copy-and-paste thinko in ignore executable bit test case. An illustration of rev-list --parents --pretty=raw Allow git-checkout when on a non-existant branch. gitweb: Decode long title for link tooltips git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1 Ignore executable bit when adding files if filemode=0. Remove empty ref directories that prevent creating a ref. Use const for interpolate arguments git-archive: update documentation Deprecate merge-recursive.py gitweb: fix over-eager application of esc_html(). Allow '(no author)' in git-svn's authors file. Allow 'svn fetch' on '(no date)' revisions in Subversion. git-repack: allow git-repack to run in subdirectory Remove upload-tar and make git-tar-tree a thin wrapper to git-archive git-tar-tree: Move code for git-archive --format=tar to archive-tar.c git-tar-tree: Remove duplicate git_config() call ...
| * Allow git-checkout when on a non-existant branch.Shawn Pearce2006-09-271-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've seen some users get into situtations where their HEAD symbolic-ref is pointing at a non-existant ref. (Sometimes this happens during clone when the remote repository lacks a 'master' branch.) If this happens the user is unable to use git-checkout to switch branches as there is no prior commit to merge from. So instead of giving the user low-level errors about how HEAD can't be resolved and how not a single revision was given change the type of checkout to be a force and go through with the user's request anyway. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status