- 13 5月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
The logic in 83ae209b (checkout branch: prime cache-tree fully, 2009-04-20) is bogus; checkout can switch branches with a dirty index and in such a case the tree won't match HEAD. Add t2014-switch to catch this breakage. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 4月, 2009 1 次提交
-
-
由 Mike Ralphson 提交于
Signed-off-by: NMike Ralphson <mike@abacus.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 4月, 2009 2 次提交
-
-
由 Junio C Hamano 提交于
When switching to another branch, the earlier code relied on incremental invalidation of cache-tree entries to degrade it. While it is not wrong per-se, we know that the resulting index must fully match the branch we are switching to unless the -m (merge) option is used. We should simply fully re-prime the cache-tree using the new tree object in such a case. And for safety, invalidate the cache-tree as a whole in other cases. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The interface to build cache-tree belongs there. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 4月, 2009 1 次提交
-
-
由 Jari Aalto 提交于
Most of the time when we give branch name in the message, we quote it inside a pair of single-quotes. git-checkout uses double-quotes; this patch corrects the inconsistency. Signed-off-by: NJari Aalto <jari.aalto@cante.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 4月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
While 'git checkout <submodule>' should not update the submodule's working directory, it should update the index. This is in line with how submodules are handled in the rest of Git. While at it, test 'git reset [<commit>] <submodule>', too. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 3月, 2009 1 次提交
-
-
由 Miklos Vajna 提交于
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 3月, 2009 3 次提交
-
-
由 Junio C Hamano 提交于
This allows a common calling sequence strbuf_branchname(&ref, name); strbuf_splice(&ref, 0, 0, "refs/heads/", 11); if (check_ref_format(ref.buf)) die(...); to be refactored into if (strbuf_check_branch_ref(&ref, name)) die(...); Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The function takes a user-supplied string that is supposed to be a branch name, and puts it in a strbuf after expanding possible shorthand notation. A handful of open coded sequence to do this in the existing code have been changed to use this helper function. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
These allow you to say "git checkout @{-2}" to switch to the branch two "branch switching" ago by pretending as if you typed the name of that branch. As it is likely that we will be introducing more short-hands to write the name of a branch without writing it explicitly, rename the functions from "nth_last_branch" to more generic "branch_name", to prepare for different semantics. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 3月, 2009 1 次提交
-
-
由 Keith Cascio 提交于
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: NKeith Cascio <keith@cs.ucla.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 1月, 2009 5 次提交
-
-
由 Thomas Rast 提交于
Have '-' mean the same as '@{-1}', i.e., the last branch we were on. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas 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: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
由 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: NDaniel Barkalow <barkalow@iabervon.org> Mentored-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan 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: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 1月, 2009 1 次提交
-
-
由 Clemens 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: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 1月, 2009 1 次提交
-
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com> Acked-by: NDaniel Barkalow <barkalow@iabervon.org>
-
- 08 12月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 11月, 2008 1 次提交
-
-
由 Matt 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: NMatt McCutchen <matt@mattmccutchen.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 11月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
Earlier commit 55218834 (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 55218834 added the check for the initial checkout condition are updated to use this function. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 11月, 2008 1 次提交
-
-
由 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: NAlexandre Julliard <julliard@winehq.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 10月, 2008 1 次提交
-
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
- 13 10月, 2008 1 次提交
-
-
由 Brandon 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: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 06 10月, 2008 1 次提交
-
-
由 Dmitry Potapov 提交于
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 25 9月, 2008 1 次提交
-
-
由 Jonas Fonseca 提交于
Signed-off-by: NJonas Fonseca <fonseca@diku.dk> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 9月, 2008 1 次提交
-
-
由 Daniel 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: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 9月, 2008 1 次提交
-
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
- 04 9月, 2008 1 次提交
-
-
由 Jeff 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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 9月, 2008 1 次提交
-
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
- 31 8月, 2008 5 次提交
-
-
由 Miklos 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: NMiklos Vajna <vmiklos@frugalware.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio 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: NJunio C Hamano <gitster@pobox.com>
-
- 23 8月, 2008 1 次提交
-
-
由 Alex Riesen 提交于
The code handles additionally "refs/remotes/<something>/name", "remotes/<something>/name", and "refs/<namespace>/name". Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2008 1 次提交
-
-
由 Johannes 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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 7月, 2008 1 次提交
-
-
由 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: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 7月, 2008 1 次提交
-
-
由 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: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-