summaryrefslogtreecommitdiff
path: root/builtin/checkout.c
AgeCommit message (Collapse)AuthorFilesLines
2013-07-22Merge branch 'nd/const-struct-cache-entry'Libravatar Junio C Hamano1-4/+4
* nd/const-struct-cache-entry: Convert "struct cache_entry *" to "const ..." wherever possible
2013-07-11Merge branch 'rr/rebase-checkout-reflog'Libravatar Junio C Hamano1-3/+8
Invocations of "git checkout" used internally by "git rebase" were counted as "checkout", and affected later "git checkout -" to the the user to an unexpected place. * rr/rebase-checkout-reflog: checkout: respect GIT_REFLOG_ACTION status: do not depend on rebase reflog messages t/t2021-checkout-last: "checkout -" should work after a rebase finishes wt-status: remove unused field in grab_1st_switch_cbdata t7512: test "detached from" as well
2013-07-09Convert "struct cache_entry *" to "const ..." wherever possibleLibravatar Nguyễn Thái Ngọc Duy1-4/+4
I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18builtin/checkout.c: don't leak memory in check_tracking_nameLibravatar Brandon Casey1-2/+5
remote_find_tracking() populates the query struct with an allocated string in the dst member. So, we do not need to xstrdup() the string, since we can transfer ownership from the query struct (which will go out of scope at the end of this function) to our callback struct, but we must free the string if it will not be used so we will not leak memory. Let's do so. Signed-off-by: Brandon Casey <drafnel@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17checkout: respect GIT_REFLOG_ACTIONLibravatar Ramkumar Ramachandra1-3/+8
GIT_REFLOG_ACTION is an environment variable specifying the reflog message to write after an action is completed. Several other commands including merge, reset, and commit respect it. Fix the failing tests in t/checkout-last by making checkout respect it too. You can now expect $ git checkout - to work as expected after any operation that internally uses "checkout" as its implementation detail, e.g. "rebase". Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'jh/checkout-auto-tracking'Libravatar Junio C Hamano1-20/+22
Update "git checkout foo" that DWIMs the intended "upstream" and turns it into "git checkout -t -b foo remotes/origin/foo" to correctly take existing remote definitions into account. The remote "origin" may be what uniquely map its own branch to remotes/some/where/foo but that some/where may not be "origin". * jh/checkout-auto-tracking: glossary: Update and rephrase the definition of a remote-tracking branch branch.c: Validate tracking branches with refspecs instead of refs/remotes/* t9114.2: Don't use --track option against "svn-remote"-tracking branches t7201.24: Add refspec to keep --track working t3200.39: tracking setup should fail if there is no matching refspec. checkout: Use remote refspecs when DWIMming tracking branches t2024: Show failure to use refspec when DWIMming remote branch names t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
2013-04-22Merge branch 'nd/checkout-keep-sparse'Libravatar Junio C Hamano1-0/+5
Make the initial "sparse" selection of the paths more sticky across "git checkout". * nd/checkout-keep-sparse: checkout: add --ignore-skip-worktree-bits in sparse checkout mode
2013-04-21checkout: Use remote refspecs when DWIMming tracking branchesLibravatar Johan Herland1-20/+22
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15checkout: add --ignore-skip-worktree-bits in sparse checkout modeLibravatar Nguyễn Thái Ngọc Duy1-0/+5
"git checkout -- <paths>" is usually used to restore all modified files in <paths>. In sparse checkout mode, this command is overloaded with another meaning: to add back all files in <paths> that are excluded by sparse patterns. As the former makes more sense for day-to-day use. Switch it to the default and the latter enabled with --ignore-skip-worktree-bits. While at there, add info/sparse-checkout to gitrepository-layout.txt Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-08checkout: abbreviate hash in suggest_reattachLibravatar Kevin Bracey1-1/+1
After printing the list of left-behind commits (with abbreviated hashes), use an abbreviated hash in the suggested 'git branch' command; there's no point in outputting a full 40-character hex string in some friendly advice. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27checkout: avoid unnecessary match_pathspec callsLibravatar Nguyễn Thái Ngọc Duy1-7/+36
In checkout_paths() we do this - for all updated items, call match_pathspec - for all items, call match_pathspec (inside unmerge_cache) - for all items, call match_pathspec (for showing "path .. is unmerged) - for updated items, call match_pathspec and update paths That's a lot of duplicate match_pathspec(s) and the function is not exactly cheap to be called so many times, especially on large indexes. This patch makes it call match_pathspec once per updated index entry, save the result in ce_flags and reuse the results in the following loops. The changes in 0a1283b (checkout $tree $path: do not clobber local changes in $path not in $tree - 2011-09-30) limit the affected paths to ones we read from $tree. We do not do anything to other modified entries in this case, so the "for all items" above could be modified to "for all updated items". But.. The command's behavior now is modified slightly: unmerged entries that match $path, but not updated by $tree, are now NOT touched. Although this should be considered a bug fix, not a regression. A new test is added for this change. And while at there, free ps_matched after use. The following command is tested on webkit, 215k entries. The pattern is chosen mainly to make match_pathspec sweat: git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*" before after real 0m3.493s 0m2.737s user 0m2.239s 0m1.586s sys 0m1.252s 0m1.151s Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-15checkout: print a message when switching unborn branchesLibravatar Jeff King1-0/+3
When we switch to a new branch using checkout, we usually output a message indicating what happened. However, when we switch from an unborn branch to a new branch, we do not print anything, which may leave the user wondering what happened. The reason is that the unborn branch is a special case (see abe1998), and does not follow the usual switch_branches code path. Let's add a similar informational message to the special case to match the usual code path. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'nd/checkout-option-parsing-fix'Libravatar Junio C Hamano1-116/+158
The option parsing of "git checkout" had error checking, dwim and defaulting missing options, all mixed in the code, and issuing an appropriate error message with useful context was getting harder. Reorganize the code and allow giving a proper diagnosis when the user says "git checkout -b -t foo bar" (e.g. "-t" is not a good name for a branch). * nd/checkout-option-parsing-fix: checkout: reorder option handling checkout: move more parameters to struct checkout_opts checkout: pass "struct checkout_opts *" as const pointer
2012-09-11checkout: reorder option handlingLibravatar Nguyễn Thái Ngọc Duy1-77/+112
checkout operates in three different modes. On top of that it tries to be smart by guessing the branch name for switching. This results in messy option handling code. This patch reorders it so that - cmd_checkout() is responsible for parsing, preparing input and determining mode - Code of each mode is in checkout_paths() and checkout_branch(), where sanity checks are performed Another slight improvement is always print branch name (or commit name) when printing errors related ot them. This helps catch the case where an option is mistaken as branch/commit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-07Merge branch 'nd/i18n-parseopt-help'Libravatar Junio C Hamano1-20/+20
A lot of i18n mark-up for the help text from "git <cmd> -h". * nd/i18n-parseopt-help: (66 commits) Use imperative form in help usage to describe an action Reduce translations by using same terminologies i18n: write-tree: mark parseopt strings for translation i18n: verify-tag: mark parseopt strings for translation i18n: verify-pack: mark parseopt strings for translation i18n: update-server-info: mark parseopt strings for translation i18n: update-ref: mark parseopt strings for translation i18n: update-index: mark parseopt strings for translation i18n: tag: mark parseopt strings for translation i18n: symbolic-ref: mark parseopt strings for translation i18n: show-ref: mark parseopt strings for translation i18n: show-branch: mark parseopt strings for translation i18n: shortlog: mark parseopt strings for translation i18n: rm: mark parseopt strings for translation i18n: revert, cherry-pick: mark parseopt strings for translation i18n: rev-parse: mark parseopt strings for translation i18n: reset: mark parseopt strings for translation i18n: rerere: mark parseopt strings for translation i18n: status: mark parseopt strings for translation i18n: replace: mark parseopt strings for translation ...
2012-08-29checkout: move more parameters to struct checkout_optsLibravatar Nguyễn Thái Ngọc Duy1-33/+35
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29checkout: pass "struct checkout_opts *" as const pointerLibravatar Nguyễn Thái Ngọc Duy1-16/+21
This struct contains various switches to system and it feels somewhat safer to have the compiler reassure us that nowhere else changes it. One field that is changed, writeout_error, is split out and passed as another argument. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-22Merge branch 'tr/void-diff-setup-done'Libravatar Junio C Hamano1-2/+1
Remove unnecessary code. * tr/void-diff-setup-done: diff_setup_done(): return void
2012-08-20i18n: checkout: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-20/+20
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03diff_setup_done(): return voidLibravatar Thomas Rast1-2/+1
diff_setup_done() has historically returned an error code, but lost the last nonzero return in 943d5b7 (allow diff.renamelimit to be set regardless of -M/-C, 2006-08-09). The callers were in a pretty confused state: some actually checked for the return code, and some did not. Let it return void, and patch all callers to take this into account. This conveniently also gets rid of a handful of different(!) error messages that could never be triggered anyway. Note that the function can still die(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-27Merge branch 'jk/maint-checkout-orphan-check-fix'Libravatar Junio C Hamano1-1/+1
"git checkout <branchname>" to come back from a detached HEAD state incorrectly computed reachability of the detached HEAD, resulting in unnecessary warnings. * jk/maint-checkout-orphan-check-fix: checkout: don't confuse ref and object flags
2012-07-25checkout: don't confuse ref and object flagsLibravatar Jeff King1-1/+1
When we are leaving a detached HEAD, we do a revision traversal to check whether we are orphaning any commits, marking the commit we're leaving as the start of the traversal, and all existing refs as uninteresting. Prior to commit 468224e5, we did so by calling for_each_ref, and feeding each resulting refname to setup_revisions. Commit 468224e5 refactored this to simply mark the pending objects, saving an extra lookup. However, it confused the "flags" parameter to the each_ref_fn clalback, which is about the flags we found while looking up the ref with the object flag. Because REF_ISSYMREF ("this ref is a symbolic ref, e.g. refs/remotes/origin/HEAD") happens to be the same bit pattern as SEEN ("we have picked this object up from the pending list and moved it to revs.commits list"), we incorrectly reported that a commit previously at the detached HEAD will become unreachable if the only ref that can reach the commit happens to be pointed at by a symbolic ref. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-11Strip namelen out of ce_flags into a ce_namelen fieldLibravatar Thomas Gummerer1-1/+2
Strip the name length from the ce_flags field and move it into its own ce_namelen field in struct cache_entry. This will both give us a tiny bit of a performance enhancement when working with long pathnames and is a refactoring for more readability of the code. It enhances readability, by making it more clear what is a flag, and where the length is stored and make it clear which functions use stages in comparisions and which only use the length. It also makes CE_NAMEMASK private, so that users don't mistakenly write the name length in the flags. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Merge branch 'cw/no-detaching-an-unborn'Libravatar Junio C Hamano1-0/+2
"git checkout --detach", when you are still on an unborn branch, should be forbidden, but it wasn't. * cw/no-detaching-an-unborn: git-checkout: disallow --detach on unborn branch
2012-06-26git-checkout: disallow --detach on unborn branchLibravatar Chris Webb1-0/+2
abe199808c (git checkout -b: allow switching out of an unborn branch) introduced a bug demonstrated by git checkout --orphan foo git checkout --detach git symbolic-ref HEAD which gives 'refs/heads/(null)'. This happens because we strbuf_addf(&branch_ref, "refs/heads/%s", opts->new_branch) when opts->new_branch can be NULL for --detach. Catch and forbid this case, adding a test to t2017 to catch it in future. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25Merge branch 'ap/checkout-no-progress-for-non-tty'Libravatar Junio C Hamano1-2/+2
The progress indicator for a large "git checkout" was sent to stderr even if it is not a terminal.
2012-05-24checkout: no progress messages if !isatty(2).Libravatar Avery Pennarun1-2/+2
If stderr isn't a tty, we shouldn't be printing incremental progress messages. In particular, this affects 'git checkout -f . >&logfile' unless you provided -q. And git-new-workdir has no way to provide -q. It would probably be better to have progress.c check isatty(2) all the time, but that wouldn't allow things like 'git push --progress' to force progress reporting to on, so I won't try to solve the general case right now. Actual fix suggested by Jeff King. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-14Merge branch 'ef/checkout-empty' into maintLibravatar Junio C Hamano1-1/+1
Running "git checkout" on an unborn branch used to corrupt HEAD (regression in 1.7.10); this makes it error out. By Erik Faye-Lund * ef/checkout-empty: checkout: do not corrupt HEAD on empty repo
2012-05-11Merge branch 'ef/checkout-empty'Libravatar Junio C Hamano1-1/+1
Running "git checkout" on an unborn branch used to corrupt HEAD (regression in 1.7.10); this makes it error out. By Erik Faye-Lund * ef/checkout-empty: checkout: do not corrupt HEAD on empty repo
2012-05-10Merge branch 'js/checkout-detach-count'Libravatar Junio C Hamano1-6/+7
When checking out another commit from an already detached state, we used to report all commits that are not reachable from any of the refs as lossage, but some of them might be reachable from the new HEAD, and there is no need to warn about them. By Johannes Sixt * js/checkout-detach-count: checkout (detached): truncate list of orphaned commits at the new HEAD t2020-checkout-detach: check for the number of orphaned commits
2012-05-08checkout: do not corrupt HEAD on empty repoLibravatar Erik Faye-Lund1-1/+1
In abe1998 ("git checkout -b: allow switching out of an unborn branch"), a code-path overly-optimisticly assumed that a branch-name was specified. This is not always the case, and as a result a NULL-pointer was attempted printed to .git/HEAD. This could lead to at least two different failure modes: 1) vsnprintf formated the NULL-string as something useful (e.g "(null)") 2) vsnprintf crashed Neither were very convenient for formatting a new HEAD-reference. To fix this, reintroduce some strictness so we only take this new codepath if a banch-name was specified. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04checkout (detached): truncate list of orphaned commits at the new HEADLibravatar Johannes Sixt1-6/+7
When git checkout switches from a detached HEAD to any other commit, then all orphaned commits were listed in a warning: Warning: you are leaving 2 commits behind...: a5e5396 another fixup 6aa1af6 fixup foo But if the new commit is actually one from this list (6aa1af6 in this example), then the list in the warning can be truncated at the new HEAD, because history beginning at HEAD is not "left behind". This makes it so. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-16Merge branch 'jk/branch-quiet'Libravatar Junio C Hamano1-0/+1
Even with "-q"uiet option, "checkout" used to report setting up tracking. Also "branch" learns "-q"uiet option to squelch informational message. By Jeff King * jk/branch-quiet: teach "git branch" a --quiet option checkout: suppress tracking message with "-q"
2012-03-26checkout: suppress tracking message with "-q"Libravatar Jeff King1-0/+1
Like the "switched to..." message (which is already suppressed by "-q"), this message is purely informational. Let's silence it if the user asked us to be quiet. This patch is slightly more than a one-liner, because we have to teach create_branch to propagate the flag all the way down to install_branch_config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16Merge branch 'jc/checkout-out-of-unborn' into maintLibravatar Junio C Hamano1-0/+19
* jc/checkout-out-of-unborn: git checkout -b: allow switching out of an unborn branch
2012-02-12Merge branch 'jc/checkout-out-of-unborn'Libravatar Junio C Hamano1-0/+19
* jc/checkout-out-of-unborn: git checkout -b: allow switching out of an unborn branch
2012-02-06git checkout -b: allow switching out of an unborn branchLibravatar Junio C Hamano1-0/+19
Running "git checkout -b another" immediately after "git init" when you do not even have a commit on 'master' fails with: $ git checkout -b another fatal: You are on a branch yet to be born This is unnecessary, if we redefine "git checkout -b $name" that does not take any $start_point (which has to be a commit) as "I want to check out a new branch $name from the state I am in". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: print advice on checking out detached HEADLibravatar Nguyễn Thái Ngọc Duy1-15/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19Merge branch 'jc/checkout-m-twoway'Libravatar Junio C Hamano1-24/+36
* jc/checkout-m-twoway: checkout_merged(): squelch false warning from some gcc Test 'checkout -m -- path' checkout -m: no need to insist on having all 3 stages
2011-12-19Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-8/+7
* nd/resolve-ref: Rename resolve_ref() to resolve_ref_unsafe() Convert resolve_ref+xstrdup to new resolve_refdup function revert: convert resolve_ref() to read_ref_full()
2011-12-15checkout_merged(): squelch false warning from some gccLibravatar Junio C Hamano1-1/+1
gcc 4.6.2 (there may be others) does not realize that the variable "mode" can never be used uninitialized in this function and issues a false warning under -Wuninitialized option. Squelch it with an unnecessary initialization; it is not like a single assignment matters to the performance in this codepath that writes out to the filesystem with checkout_entry() anyway. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'nd/ignore-might-be-precious'Libravatar Junio C Hamano1-3/+8
* nd/ignore-might-be-precious: checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
2011-12-13Merge branch 'jn/branch-move-to-self'Libravatar Junio C Hamano1-4/+11
* jn/branch-move-to-self: Allow checkout -B <current-branch> to update the current branch branch: allow a no-op "branch -M <current-branch> HEAD"
2011-12-13Convert resolve_ref+xstrdup to new resolve_refdup functionLibravatar Nguyễn Thái Ngọc Duy1-8/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-3/+5
* nd/resolve-ref: Copy resolve_ref() return value for longer use Convert many resolve_ref() calls to read_ref*() and ref_exists() Conflicts: builtin/fmt-merge-msg.c builtin/merge.c refs.c
2011-12-06checkout -m: no need to insist on having all 3 stagesLibravatar Junio C Hamano1-24/+36
The content level merge machinery ll_merge() is prepared to merge correctly in "both sides added differently" case by using an empty blob as if it were the common ancestor. "checkout -m" could do the same, but didn't bother supporting it and instead insisted on having all three stages. Reported-by: Pete Harlan Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Copy resolve_ref() return value for longer useLibravatar Nguyễn Thái Ngọc Duy1-1/+3
resolve_ref() may return a pointer to a static buffer. Callers that use this value longer than a couple of statements should copy the value to avoid some hidden resolve_ref() call that may change the static buffer's value. The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c demonstrates this. The first call is in cmd_merge() branch = resolve_ref("HEAD", head_sha1, 0, &flag); Then deep in lookup_commit_or_die() a few lines after, resolve_ref() may be called again and destroy "branch". lookup_commit_or_die lookup_commit_reference lookup_commit_reference_gently parse_object lookup_replace_object do_lookup_replace_object prepare_replace_object for_each_replace_ref do_for_each_ref get_loose_refs get_ref_dir get_ref_dir resolve_ref All call sites are checked and made sure that xstrdup() is called if the value should be saved. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Merge branch 'nd/maint-ignore-exclude'Libravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-11-28Allow checkout -B <current-branch> to update the current branchLibravatar Jonathan Nieder1-4/+11
When on master, "git checkout -B master <commit>" is a more natural way to say "git reset --keep <commit>", which was originally invented for the exact purpose of moving to the named commit while keeping the local changes around. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28checkout,merge: disallow overwriting ignored files with --no-overwrite-ignoreLibravatar Nguyễn Thái Ngọc Duy1-3/+8
Ignored files usually are generated files (e.g. .o files) and can be safely discarded. However sometimes users may have important files in working directory, but still want a clean "git status", so they mark them as ignored files. But in this case, these files should not be overwritten without asking first. Enable this use case with --no-overwrite-ignore, where git only sees tracked and untracked files, no ignored files. Those who mix discardable ignored files with important ones may have to sort it out themselves. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>