summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-06-24Revert "Merge branch 'jg/status-config'"Libravatar Junio C Hamano1-11/+0
This reverts commit 1a22bd31f0a5130ce6c934951a5526ceb774c2be, reversing changes made to 3e7a5b489e45ae8a3a0b222893d58b172d883136. It makes it impossible to "git commit" when status.short is set, and also "git status --porcelain" output is affected by status.branch.
2013-06-23Merge branch 'jg/status-config'Libravatar Junio C Hamano1-0/+11
"git status" learned status.branch and status.short configuration variables to use --branch and --short options by default (override with --no-branch and --no-short options from the command line). * jg/status-config: status: introduce status.branch to enable --branch by default status: introduce status.short to enable --short by default
2013-06-20Merge branch 'rs/logical-vs-binary-or'Libravatar Junio C Hamano3-6/+6
Code cleanup. * rs/logical-vs-binary-or: use logical OR (||) instead of binary OR (|) in logical context
2013-06-20Merge branch 'mm/color-auto-default'Libravatar Junio C Hamano1-0/+5
Flip the default for color.ui to 'auto', which is what many tutorials recommend new users to do. * mm/color-auto-default: make color.ui default to 'auto' config: refactor management of color.ui's default value
2013-06-15status: introduce status.branch to enable --branch by defaultLibravatar Jorge Juan Garcia Garcia1-0/+4
Some people often run 'git status -b'. The config variable status.branch allows to set it by default. Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14Merge branch 'mh/reflife'Libravatar Junio C Hamano5-51/+57
Define memory ownership and lifetime rules for what for-each-ref feeds to its callbacks (in short, "you do not own it, so make a copy if you want to keep it"). * mh/reflife: (25 commits) refs: document the lifetime of the args passed to each_ref_fn register_ref(): make a copy of the bad reference SHA-1 exclude_existing(): set existing_refs.strdup_strings string_list_add_refs_by_glob(): add a comment about memory management string_list_add_one_ref(): rename first parameter to "refname" show_head_ref(): rename first parameter to "refname" show_head_ref(): do not shadow name of argument add_existing(): do not retain a reference to sha1 do_fetch(): clean up existing_refs before exiting do_fetch(): reduce scope of peer_item object_array_entry: fix memory handling of the name field find_first_merges(): remove unnecessary code find_first_merges(): initialize merges variable using initializer fsck: don't put a void*-shaped peg in a char*-shaped hole object_array_remove_duplicates(): rewrite to reduce copying revision: use object_array_filter() in implementation of gc_boundary() object_array: add function object_array_filter() revision: split some overly-long lines cmd_diff(): make it obvious which cases are exclusive of each other cmd_diff(): rename local variable "list" -> "entry" ...
2013-06-13use logical OR (||) instead of binary OR (|) in logical contextLibravatar René Scharfe3-6/+6
The compiler can short-circuit the evaluation of conditions strung together with logical OR operators instead of computing the resulting bitmask with binary ORs. More importantly, this patch makes the intent of the changed code clearer, because the logical context (as opposed to binary context) becomes immediately obvious. While we're at it, simplify the check for patch->is_rename in builtin/apply.c a bit; it can only be 0 or 1, so we don't need a comparison operator. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11status: introduce status.short to enable --short by defaultLibravatar Jorge Juan Garcia Garcia1-0/+7
Some people always run 'git status -s'. The configuration variable status.short allows to set it by default. Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11Merge branch 'rs/unpack-trees-plug-leak'Libravatar Junio C Hamano1-2/+3
* rs/unpack-trees-plug-leak: unpack-trees: free cache_entry array members for merges diff-lib, read-tree, unpack-trees: mark cache_entry array paramters const diff-lib, read-tree, unpack-trees: mark cache_entry pointers const unpack-trees: create working copy of merge entry in merged_entry unpack-trees: factor out dup_entry read-cache: mark cache_entry pointers const cache: mark cache_entry pointers const
2013-06-10make color.ui default to 'auto'Libravatar Matthieu Moy1-1/+1
Most users seem to like having colors enabled, and colors can help beginners to understand the output of some commands (e.g. notice immediately the boundary between commits in the output of "git log"). Many tutorials tell the users to set color.ui=auto as a very first step, which tend to indicate that color.ui=none is not the recommanded value, hence should not be the default. These tutorials would benefit from skipping this step and starting the real Git manipulations earlier. Other beginners do not know about color.ui=auto, and may not discover it by themselves, hence live with black&white outputs while they may have preferred colors. A few people (e.g. color-blind) prefer having no colors, but they can easily set color.ui=never for this (and googling "disable colors in git" already tells them how to do so), but this needs not occupy space in beginner-oriented documentations. A transition period with Git emitting a warning when color.ui is unset would be possible, but the discomfort of having the warning seems superior to the benefit: users may be surprised by the change, but not harmed by it. The default value is changed, and the documentation is reworded to mention "color.ui=false" first, since the primary use of color.ui after this change is to disable colors, not to enable it. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-09Merge branch 'jn/config-ignore-inaccessible' into maintLibravatar Junio C Hamano1-2/+2
A git daemon that starts as "root" and then drops privilege often leaves $HOME set to that of the root user, which is unreadable by the daemon process, which was diagnosed as a configuration error. Make per-user configuration files that are inaccessible due to EACCES as though these files do not exist to avoid this issue, as the tightening which was originally meant as an additional security has annoyed enough sysadmins. * jn/config-ignore-inaccessible: config: allow inaccessible configuration under $HOME
2013-06-06Merge branch 'rr/push-head'Libravatar Junio C Hamano1-7/+14
"git push $there HEAD:branch" did not resolve HEAD early enough, so it was easy to flip it around while push is still going on and push out a branch that the user did not originally intended when the command was started. * rr/push-head: push: make push.default = current use resolved HEAD push: fail early with detached HEAD and current push: factor out the detached HEAD error message
2013-06-06Merge branch 'nd/clone-connectivity-shortcut'Libravatar Junio C Hamano2-14/+39
Special case "git clone" and use lighter-weight implementation to check the completeness of the history behind refs. * nd/clone-connectivity-shortcut: clone: open a shortcut for connectivity check index-pack: remove dead code (it should never happen) fetch-pack: prepare updated shallow file before fetching the pack clone: let the user know when check_everything_connected is run
2013-06-06Merge branch 'nd/prune-packed-dryrun-verbose'Libravatar Junio C Hamano2-9/+8
* nd/prune-packed-dryrun-verbose: prune-packed: avoid implying "1" is DRY_RUN in prune_packed_objects()
2013-06-05Merge branch 'rs/commit-m-no-edit'Libravatar Junio C Hamano1-4/+6
"git commit --allow-empty-message -m ''" should not start an editor. * rs/commit-m-no-edit: commit: don't start editor if empty message is given with -m
2013-06-02Merge branch 'tr/line-log'Libravatar Junio C Hamano2-91/+39
* tr/line-log: git-log(1): remove --full-line-diff description line-log: fix documentation formatting log -L: improve comments in process_all_files() log -L: store the path instead of a diff_filespec log -L: test merge of parallel modify/rename t4211: pass -M to 'git log -M -L...' test log -L: fix overlapping input ranges log -L: check range set invariants when we look it up Speed up log -L... -M log -L: :pattern:file syntax to find by funcname Implement line-history search (git log -L) Export rewrite_parents() for 'log -L' Refactor parse_loc
2013-06-02Merge branch 'mc/describe-first-parent'Libravatar Junio C Hamano1-0/+5
* mc/describe-first-parent: describe: Add --first-parent option
2013-06-02Merge branch 'jk/fetch-always-update-tracking'Libravatar Junio C Hamano1-22/+51
"git fetch origin master" unlike "git fetch origin" or "git fetch" did not update "refs/remotes/origin/master"; this was an early design decision to keep the update of remote tracking branches predictable, but in practice it turns out that people find it more convenient to opportunisticly update them whenever we have a chance, and we have been updating them when we run "git push" which already breaks the original "predictability" anyway. Now such a fetch does update refs/remotes/origin/master. * jk/fetch-always-update-tracking: fetch: don't try to update unfetched tracking refs fetch: opportunistically update tracking refs refactor "ref->merge" flag fetch/pull doc: untangle meaning of bare <ref> t5510: start tracking-ref tests from a known state
2013-06-02Merge branch 'vv/help-unknown-ref'Libravatar Junio C Hamano1-1/+2
Detect "git merge foo" that might have meant "git merge origin/foo" and give an error message that is more specific than "foo is not something we can merge". * vv/help-unknown-ref: merge: use help_unknown_ref() help: add help_unknown_ref()
2013-06-02Merge branch 'nd/clone-local-with-colon'Libravatar Junio C Hamano1-0/+2
"git clone foo/bar:baz" cannot be a request to clone from a remote over git-over-ssh specified in the scp style. Detect this case and clone from a local repository at "foo/bar:baz". * nd/clone-local-with-colon: clone: allow cloning local paths with colons in them
2013-06-02Merge branch 'fc/fast-export-persistent-marks'Libravatar Junio C Hamano1-7/+15
Optimization for fast-export by avoiding unnecessarily resolving arbitrary object name and parsing object when only presence and type information is necessary, etc. * fc/fast-export-persistent-marks: fast-{import,export}: use get_sha1_hex() to read from marks file fast-export: don't parse commits while reading marks file fast-export: do not parse non-commit objects while reading marks file
2013-06-02diff-lib, read-tree, unpack-trees: mark cache_entry array paramters constLibravatar René Scharfe1-1/+2
Change the type merge_fn_t to accept the array of cache_entry pointers as const pointers to const pointers. This documents the fact that the merge functions don't modify the cache_entry contents or replace any of the pointers in the array. Only a single cast is necessary in unpack_nondirectories because adding two const modifiers at once is not allowed in C. The cast is safe in that it doesn't mask any modfication; call_unpack_fn only needs the array for reading. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02diff-lib, read-tree, unpack-trees: mark cache_entry pointers constLibravatar René Scharfe1-1/+1
Add const to struct cache_entry pointers throughout the tree which are only used for reading. This allows callers to pass in const pointers. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02exclude_existing(): set existing_refs.strdup_stringsLibravatar Michael Haggerty1-1/+1
The each_ref_fn add_existing() adds refnames to the existing_refs list. But the lifetimes of these refnames is not guaranteed by the refs API, so configure the string_list to make copies as it adds them. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02add_existing(): do not retain a reference to sha1Libravatar Michael Haggerty1-3/+4
Its lifetime is not guaranteed, so make a copy. Free the memory when the string_list is cleared. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02do_fetch(): clean up existing_refs before exitingLibravatar Michael Haggerty1-5/+9
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02do_fetch(): reduce scope of peer_itemLibravatar Michael Haggerty1-3/+3
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29push: make push.default = current use resolved HEADLibravatar Ramkumar Ramachandra1-1/+1
With this change, the output of the push (with push.default set to current) changes subtly from: $ git push ... * [new branch] HEAD -> push-current-head to: $ git push ... * [new branch] push-current-head -> push-current-head This patch was written with a different motivation. There is a problem unique to push.default = current: # on branch push-current-head $ git push # on another terminal $ git checkout master # return to the first terminal # the push tried to push master! This happens because the 'git checkout' on the second terminal races with the 'git push' on the first terminal. Although this patch does not solve the core problem (there is still no guarantee that 'git push' on the first terminal will resolve HEAD before 'git checkout' changes HEAD on the second), it works in practice. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29push: fail early with detached HEAD and currentLibravatar Ramkumar Ramachandra1-0/+5
Setting push.default to current adds the refspec "HEAD" for the transport layer to handle. If "HEAD" doesn't resolve to a branch (and since no refspec rhs is specified), the push fails after some time with a cryptic error message: $ git push error: unable to push to unqualified destination: HEAD The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'git@github.com:artagnon/git' Fail early with a nicer error message: $ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use git push ram HEAD:<name-of-remote-branch> Just like in the upstream and simple cases. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'jn/config-ignore-inaccessible'Libravatar Junio C Hamano1-2/+2
When $HOME is misconfigured to point at an unreadable directory, we used to complain and die. This loosens the check. * jn/config-ignore-inaccessible: config: allow inaccessible configuration under $HOME
2013-05-29Merge branch 'mh/packed-refs-various'Libravatar Junio C Hamano2-2/+1
Update reading and updating packed-refs file, correcting corner case bugs. * mh/packed-refs-various: (33 commits) refs: handle the main ref_cache specially refs: change do_for_each_*() functions to take ref_cache arguments pack_one_ref(): do some cheap tests before a more expensive one pack_one_ref(): use write_packed_entry() to do the writing pack_one_ref(): use function peel_entry() refs: inline function do_not_prune() pack_refs(): change to use do_for_each_entry() refs: use same lock_file object for both ref-packing functions pack_one_ref(): rename "path" parameter to "refname" pack-refs: merge code from pack-refs.{c,h} into refs.{c,h} pack-refs: rename handle_one_ref() to pack_one_ref() refs: extract a function write_packed_entry() repack_without_ref(): write peeled refs in the rewritten file t3211: demonstrate loss of peeled refs if a packed ref is deleted refs: change how packed refs are deleted search_ref_dir(): return an index rather than a pointer repack_without_ref(): silence errors for dangling packed refs t3210: test for spurious error messages for dangling packed refs refs: change the internal reference-iteration API refs: extract a function peel_entry() ...
2013-05-29Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-42/+50
Enhance "check-ignore" (1.8.2 update) to work more like "check-attr" over bidi-pipes. * as/check-ignore: t0008: use named pipe (FIFO) to test check-ignore streaming Documentation: add caveats about I/O buffering for check-{attr,ignore} check-ignore: allow incremental streaming of queries via --stdin check-ignore: move setup into cmd_check_ignore() check-ignore: add -n / --non-matching option t0008: remove duplicated test fixture data
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-05-29Merge branch 'jc/prune-all'Libravatar Junio C Hamano2-9/+9
We used the approxidate() parser for "--expire=<timestamp>" options of various commands, but it is better to treat --expire=all and --expire=now a bit more specially than using the current timestamp. Update "git gc" and "git reflog" with a new parsing function for expiry dates. * jc/prune-all: prune: introduce OPT_EXPIRY_DATE() and use it api-parse-options.txt: document "no-" for non-boolean options git-gc.txt, git-reflog.txt: document new expiry options date.c: add parse_expiry_date()
2013-05-29push: factor out the detached HEAD error messageLibravatar Ramkumar Ramachandra1-6/+8
With push.default set to upstream or simple, and a detached HEAD, git push prints the following error: $ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use git push ram HEAD:<name-of-remote-branch> This error is not unique to upstream or simple: current cannot push with a detached HEAD either. So, factor out the error string in preparation for using it in current. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28commit: don't start editor if empty message is given with -mLibravatar René Scharfe1-4/+6
If an empty message is specified with the option -m of git commit then the editor is started. That's unexpected and unnecessary. Instead of using the length of the message string for checking if the user specified one, directly remember if the option -m was given. Reported-by: Mislav Marohnić <mislav.marohnic@gmail.com> Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28fsck: don't put a void*-shaped peg in a char*-shaped holeLibravatar Michael Haggerty1-1/+1
The source of this nonsense was 04d3975937 fsck: reduce stack footprint , which wedged a pointer to parent into the object_array_entry's name field. The parent pointer was passed to traverse_one_object(), even though that function *didn't use it*. The useless code has been deleted over time. Commit a1cdc25172 fsck: drop unused parameter from traverse_one_object() removed the parent pointer from traverse_one_object()'s signature. Commit c0aa335c95 Remove unused variables removed the code that read the parent pointer back out of the name field. This commit takes the last step: don't write the parent pointer into the name field in the first place. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28cmd_diff(): make it obvious which cases are exclusive of each otherLibravatar Michael Haggerty1-5/+4
At first glance the OBJ_COMMIT, OBJ_TREE, and OBJ_BLOB cases look like they might be mutually exclusive. But the OBJ_COMMIT case doesn't end the loop iteration with "continue" like the other two cases, but rather falls through. So use if...else if...else construct to make it more obvious that only the last two cases are mutually exclusive. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28cmd_diff(): rename local variable "list" -> "entry"Libravatar Michael Haggerty1-4/+4
It's not a list, it's an array entry. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28cmd_diff(): use an object_array for holding treesLibravatar Michael Haggerty1-19/+18
Change cmd_diff() to use a (struct object_array) for holding the trees that it accumulates, rather than rolling its own equivalent. Incidentally, this change removes a hard-coded limit of 100 trees in combined diff, not that it matters in practice. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28builtin_diff_tree(): make it obvious that function wants two entriesLibravatar Michael Haggerty1-9/+10
Instead of accepting an array and using exactly two elements from the array, take two single (struct object_array_entry *) arguments. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28fetch: make own copies of refnamesLibravatar Michael Haggerty1-2/+2
Do not retain references to refnames passed to the each_ref_fn callback add_existing(), because their lifetime is not guaranteed. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28describe: make own copy of refnameLibravatar Michael Haggerty1-2/+4
Do not retain a reference to the refname passed to the each_ref_fn callback get_name(), because there is no guarantee of the lifetimes of these names. Instead, make a local copy when needed. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28prune-packed: avoid implying "1" is DRY_RUN in prune_packed_objects()Libravatar Nguyễn Thái Ngọc Duy2-9/+8
Commit b60daf0 (Make git-prune-packed a bit more chatty. - 2007-01-12) changes the meaning of prune_packed_objects()'s argument, from "dry run or not dry run" to a bitmap. It however forgot to update prune_packed_objects() caller in builtin/prune.c to use new DRY_RUN macro. It's fine (for a long time!) but there is a risk that someday someone may change the value of DRY_RUN to something else and builtin/prune.c suddenly breaks. Avoid that possibility. While at there, change "opts == VERBOSE" to "opts & VERBOSE" as there is no obvious reason why we only be chatty when DRY_RUN is not set. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28fetch: don't try to update unfetched tracking refsLibravatar John Keeping1-1/+1
Since commit f269048 (fetch: opportunistically update tracking refs, 2013-05-11) we update tracking refs opportunistically when fetching remote branches. However, if there is a configured non-pattern refspec that does not match any of the refspecs given on the command line then a fatal error occurs. Fix this by setting the "missing_ok" flag when calling get_fetch_map. Test-added-by: Jeff King <peff@peff.net> Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28clone: open a shortcut for connectivity checkLibravatar Nguyễn Thái Ngọc Duy2-12/+34
In order to make sure the cloned repository is good, we run "rev-list --objects --not --all $new_refs" on the repository. This is expensive on large repositories. This patch attempts to mitigate the impact in this special case. In the "good" clone case, we only have one pack. If all of the following are met, we can be sure that all objects reachable from the new refs exist, which is the intention of running "rev-list ...": - all refs point to an object in the pack - there are no dangling pointers in any object in the pack - no objects in the pack point to objects outside the pack The second and third checks can be done with the help of index-pack as a slight variation of --strict check (which introduces a new condition for the shortcut: pack transfer must be used and the number of objects large enough to call index-pack). The first is checked in check_everything_connected after we get an "ok" from index-pack. "index-pack + new checks" is still faster than the current "index-pack + rev-list", which is the whole point of this patch. If any of the conditions fail, we fall back to the good old but expensive "rev-list ..". In that case it's even more expensive because we have to pay for the new checks in index-pack. But that should only happen when the other side is either buggy or malicious. Cloning linux-2.6 over file:// before after real 3m25.693s 2m53.050s user 5m2.037s 4m42.396s sys 0m13.750s 0m16.574s A more realistic test with ssh:// over wireless before after real 11m26.629s 10m4.213s user 5m43.196s 5m19.444s sys 0m35.812s 0m37.630s This shortcut is not applied to shallow clones, partly because shallow clones should have no more objects than a usual fetch and the cost of rev-list is acceptable, partly to avoid dealing with corner cases when grafting is involved. This shortcut does not apply to unpack-objects code path either because the number of objects must be small in order to trigger that code path. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28index-pack: remove dead code (it should never happen)Libravatar Nguyễn Thái Ngọc Duy1-2/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20describe: Add --first-parent optionLibravatar Mike Crowe1-0/+5
Only consider the first parent commit when walking the commit history. This is useful if you only wish to match tags on your branch after a merge. Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-15config: refactor management of color.ui's default valueLibravatar Matthieu Moy1-0/+5
The meaning of get_colorbool_found and get_diff_color_found is "the config value if found, and -1 otherwise", but get_color_ui_found had a slightly different meaning, as it has the value 0 (which corresponds to the default value from the user point of view) when color.ui is unset. Make get_color_ui_found default to -1, and make it explicit that 0 is the default value when nothing else is found. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12fetch: opportunistically update tracking refsLibravatar Jeff King1-0/+16
When we run a regular "git fetch" without arguments, we update the tracking refs according to the configured refspec. However, when we run "git fetch origin master" (or "git pull origin master"), we do not look at the configured refspecs at all, and just update FETCH_HEAD. We miss an opportunity to update "refs/remotes/origin/master" (or whatever the user has configured). Some users find this confusing, because they would want to do further comparisons against the old state of the remote master, like: $ git pull origin master $ git log HEAD...origin/master In the currnet code, they are comparing against whatever commit happened to be in origin/master from the last time they did a complete "git fetch". This patch will update a ref from the RHS of a configured refspec whenever we happen to be fetching its LHS. That makes the case above work. The downside is that any users who really care about whether and when their tracking branches are updated may be surprised. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>