summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-10-30handle_duplicate(): mark error message for translationLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30ref_remote_duplicates(): extract a function handle_duplicate()Libravatar Michael Haggerty1-8/+10
It will become more complex in a moment. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30ref_remove_duplicates(): simplify loop logicLibravatar Michael Haggerty3-26/+38
Change the loop body into the more straightforward * remove item from the front of the old list * if necessary, add it to the tail of the new list and return a pointer to the new list (even though it is currently always the same as the input argument, because the first element in the list is currently never deleted). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30t5536: new test of refspec conflicts when fetchingLibravatar Michael Haggerty1-0/+96
Add some tests that "git fetch" handles refspec conflicts (i.e., when the same local reference should be updated from two different remote references) correctly. There is a small bug when updating references opportunistically, namely that an explicit user wish like git fetch origin \ refs/heads/branch1:refs/remotes/origin/branch2 \ refs/heads/branch2:refs/remotes/origin/branch1 should override a configured refspec like +refs/heads/*:refs/remotes/origin/* The current code incorrectly treats this as a fatal error. In a few commits we will improve the error messages for refspec conflicts in general and also turn this buggy fatal error into a warning. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30ref_remove_duplicates(): avoid redundant bisectionLibravatar Michael Haggerty1-6/+6
The old code called string_list_lookup(), and if that failed called string_list_insert(), thus doing the bisection search through the string list twice in the latter code path. Instead, just call string_list_insert() right away. If an entry for that peer reference name already existed, then its util pointer is always non-NULL. Of course this doesn't change the fact that the repeated string_list_insert() calls make the function scale like O(N^2) if the input reference list is not already approximately sorted. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30git-fetch.txt: improve description of tag auto-followingLibravatar Michael Haggerty1-7/+7
Make it clearer that tags are fetched independent of which branches were fetched from the remote in any particular fetch. (Tags are even fetched if they point at objects that are in the current repository but not reachable, which is probably a bug.) Put less emphasis on the mechanism and more on the effect of tag auto-following. Also mention the options and configuration settings that can change the tag-fetching behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch-options.txt: simplify ifdef/ifndef/endif usageLibravatar Michael Haggerty1-4/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch, remote: properly convey --no-prune options to subprocessesLibravatar Michael Haggerty2-5/+5
If --no-prune is passed to one of the following commands: git fetch --all git fetch --multiple git fetch --recurse-submodules git remote update then it must also be passed to the "fetch" subprocesses that those commands use to do their work. Otherwise there might be a fetch.prune or remote.<name>.prune configuration setting that causes pruning to occur, contrary to the user's express wish. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30builtin/remote.c:update(): use struct argv_arrayLibravatar Michael Haggerty1-16/+17
Use struct argv_array for calling the "git fetch" subprocesses. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30builtin/remote.c: reorder function definitionsLibravatar Michael Haggerty1-81/+78
Reorder function definitions to remove the need for forward declarations. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30query_refspecs(): move some constants out of the loopLibravatar Michael Haggerty1-2/+2
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch --prune: prune only based on explicit refspecsLibravatar Michael Haggerty4-42/+30
The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch --tags: fetch tags *in addition to* other stuffLibravatar Michael Haggerty7-38/+78
Previously, fetch's "--tags" option was considered equivalent to specifying the refspec "refs/tags/*:refs/tags/*" on the command line; in particular, it caused the remote.<name>.refspec configuration to be ignored. But it is not very useful to fetch tags without also fetching other references, whereas it *is* quite useful to be able to fetch tags *in addition to* other references. So change the semantics of this option to do the latter. If a user wants to fetch *only* tags, then it is still possible to specifying an explicit refspec: git fetch <remote> 'refs/tags/*:refs/tags/*' Please note that the documentation prior to 1.8.0.3 was ambiguous about this aspect of "fetch --tags" behavior. Commit f0cb2f137c 2012-12-14 fetch --tags: clarify documentation made the documentation match the old behavior. This commit changes the documentation to match the new behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch: only opportunistically update references based on command lineLibravatar Michael Haggerty1-12/+32
The old code processed (tags == TAGS_SET) before adding the entries used to opportunistically update references mentioned on the command line. The result was that all tags were also considered candidates for opportunistic updating. This is harmless for two reasons: (a) because it would only add entries if there is a configured refspec that covers tags *and* both --tags and another refspec appear on the command-line; (b) because any extra entries would be deleted later by the call to ref_remove_duplicates() anyway. But, to avoid extra work and extra memory usage, and to make the implementation better match the intention, change the algorithm slightly: compute the opportunistic refspecs based only on the command-line arguments, storing the results into a separate temporary list. Then add the tags (which have to come earlier in the list so that they are not de-duped in favor of an opportunistic entry). Then concatenate the temporary list onto the main list. This change will also make later changes easier. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30get_expanded_map(): avoid memory leakLibravatar Michael Haggerty1-3/+3
The old code could leak *expn_name if match_name_with_pattern() succeeded but ignore_symref_update() returned true. So make sure that *expn_name is freed in any case. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30get_expanded_map(): add docstringLibravatar Michael Haggerty1-0/+7
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30builtin/fetch.c: reorder function definitionsLibravatar Michael Haggerty1-101/+97
Reorder function definitions to avoid the need for a forward declaration of function find_non_local_tags(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-24get_ref_map(): rename local variablesLibravatar Michael Haggerty1-6/+6
Rename "refs" -> "refspecs" and "ref_count" -> "refspec_count" to reduce confusion, because they describe an array of "struct refspec", as opposed to the "struct ref" objects that are also used in this function. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-24api-remote.txt: correct section "struct refspec"Libravatar Michael Haggerty1-10/+10
* Replace reference to function parse_ref_spec() with references to functions parse_fetch_refspec() and parse_push_refspec(). * Correct description of src and dst: they *do* include the '*' characters. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-24t5510: check that "git fetch --prune --tags" does not prune branchesLibravatar Michael Haggerty1-0/+4
"git fetch --prune --tags" is currently interpreted as follows: * "--tags" is equivalent to specifying a refspec "refs/tags/*:refs/tags/*", and supersedes any default refspecs configured via remote.$REMOTE.fetch. * "--prune" only operates on the refspecs being fetched. Therefore, "git fetch --prune --tags" prunes tags in refs/tags/* but does not fetch or prune other references. The fact that this command does not prune references outside of refs/tags/* was previously untested. So add a test that verifies the status quo. However, the status quo is surprising, so it will be changed later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-24t5510: prepare test refs more straightforwardlyLibravatar Michael Haggerty1-4/+4
"git fetch" was being used with contrived refspecs to create tags and remote-tracking branches in test repositories in preparation for the actual tests. This is obscure and also makes one wonder whether this is indeed just preparation or whether some side-effect of "git fetch" is being tested. So use the more straightforward commands "git tag" / "git update-ref" when preparing branches in test repositories. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-24t5510: use the correct tag name in testLibravatar Michael Haggerty1-1/+1
Fix an apparent copy-paste error: A few lines earlier, a tag "refs/tags/sometag" is created. Check for the (non-)existence of that tag, not "somebranch", which is otherwise never mentioned in the script. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Update draft release notes to 1.8.5Libravatar Junio C Hamano1-0/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Sync with 'maint'Libravatar Junio C Hamano1-0/+13
2013-10-23Almost 1.8.4.2 ;-)Libravatar Junio C Hamano1-0/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Merge branch 'jc/ls-files-killed-optim' into maintLibravatar Junio C Hamano4-17/+67
"git ls-files -k" needs to crawl only the part of the working tree that may overlap the paths in the index to find killed files, but shared code with the logic to find all the untracked files, which made it unnecessarily inefficient. * jc/ls-files-killed-optim: dir.c::test_one_path(): work around directory_exists_in_index_icase() breakage t3010: update to demonstrate "ls-files -k" optimization pitfalls ls-files -k: a directory only can be killed if the index has a non-directory dir.c: use the cache_* macro to access the current index
2013-10-23Merge branch 'jh/checkout-auto-tracking' into maintLibravatar Junio C Hamano4-8/+45
"git branch --track" had a minor regression in v1.8.3.2 and later that made it impossible to base your local work on anything but a local branch of the upstream repository you are tracking from. * jh/checkout-auto-tracking: t3200: fix failure on case-insensitive filesystems branch.c: Relax unnecessary requirement on upstream's remote ref name t3200: Add test demonstrating minor regression in 41c21f2 Refer to branch.<name>.remote/merge when documenting --track t3200: Minor fix when preparing for tracking failure t2024: Fix &&-chaining and a couple of typos
2013-10-23Merge branch 'nd/fetch-into-shallow' into maintLibravatar Junio C Hamano12-160/+152
When there is no sufficient overlap between old and new history during a "git fetch" into a shallow repository, objects that the sending side knows the receiving end has were unnecessarily sent. * nd/fetch-into-shallow: Add testcase for needless objects during a shallow fetch list-objects: mark more commits as edges in mark_edges_uninteresting list-objects: reduce one argument in mark_edges_uninteresting upload-pack: delegate rev walking in shallow fetch to pack-objects shallow: add setup_temporary_shallow() shallow: only add shallow graft points to new shallow file move setup_alternate_shallow and write_shallow_commits to shallow.c
2013-10-23Merge branch 'bc/gnome-keyring'Libravatar Junio C Hamano2-134/+167
Cleanups and tweaks for credential handling to work with ancient versions of the gnome-keyring library that are still in use. * bc/gnome-keyring: contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring contrib/git-credential-gnome-keyring.c: report failure to store password contrib/git-credential-gnome-keyring.c: use glib messaging functions contrib/git-credential-gnome-keyring.c: use glib memory allocation functions contrib/git-credential-gnome-keyring.c: use secure memory for reading passwords contrib/git-credential-gnome-keyring.c: use secure memory functions for passwds contrib/git-credential-gnome-keyring.c: use gnome helpers in keyring_object() contrib/git-credential-gnome-keyring.c: set Gnome application name contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before accessing contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not ssize_t contrib/git-credential-gnome-keyring.c: exit non-zero when called incorrectly contrib/git-credential-gnome-keyring.c: add static where applicable contrib/git-credential-gnome-keyring.c: *style* use "if ()" not "if()" etc. contrib/git-credential-gnome-keyring.c: remove unused die() function contrib/git-credential-gnome-keyring.c: remove unnecessary pre-declarations
2013-10-23Merge branch 'po/dot-url'Libravatar Junio C Hamano2-2/+8
Explain how '.' can be used to refer to the "current repository" in the documentation. * po/dot-url: doc/cli: make "dot repository" an independent bullet point config doc: update dot-repository notes doc: command line interface (cli) dot-repository dwimmery
2013-10-23Merge branch 'jc/prompt-upstream'Libravatar Junio C Hamano1-1/+6
An enhancement to the GIT_PS1_SHOWUPSTREAM facility. * jc/prompt-upstream: git-prompt.sh: optionally show upstream branch name
2013-10-23Merge branch 'hu/cherry-pick-previous-branch'Libravatar Junio C Hamano2-2/+14
"git cherry-pick" without further options would segfault. Could use a follow-up to handle '-' after argv[1] better. * hu/cherry-pick-previous-branch: cherry-pick: handle "-" after parsing options
2013-10-23Merge branch 'mg/more-textconv'Libravatar Junio C Hamano14-57/+237
Make "git grep" and "git show" pay attention to --textconv when dealing with blob objects. * mg/more-textconv: grep: honor --textconv for the case rev:path grep: allow to use textconv filters t7008: demonstrate behavior of grep with textconv cat-file: do not die on --textconv without textconv filters show: honor --textconv for blobs diff_opt: track whether flags have been set explicitly t4030: demonstrate behavior of show with textconv
2013-10-23Merge branch 'jc/pack-objects'Libravatar Junio C Hamano1-11/+12
* jc/pack-objects: pack-objects: shrink struct object_entry
2013-10-18Update draft release notes to 1.8.5Libravatar Junio C Hamano1-0/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18Merge branch 'maint'Libravatar Junio C Hamano1-1/+5
* maint: git-merge: document the -S option
2013-10-18Merge branch 'jc/reflog-doc'Libravatar Junio C Hamano3-3/+49
Document rules to use GIT_REFLOG_ACTION variable in the scripted Porcelain. git-rebase--interactive locally violates them, but it is a leaf user that does not call out to or dot-source other scripts, so it does not urgently need to be fixed. * jc/reflog-doc: setup_reflog_action: document the rules for using GIT_REFLOG_ACTION
2013-10-18Merge branch 'sb/repack-in-c'Libravatar Junio C Hamano5-1/+391
Rewrite "git repack" in C. * sb/repack-in-c: repack: improve warnings about failure of renaming and removing files repack: retain the return value of pack-objects repack: rewrite the shell script in C
2013-10-18Merge branch 'jk/clone-progress-to-stderr'Libravatar Junio C Hamano4-28/+32
Some progress and diagnostic messages from "git clone" were incorrectly sent to the standard output stream, not to the standard error stream. * jk/clone-progress-to-stderr: clone: always set transport options clone: treat "checking connectivity" like other progress clone: send diagnostic messages to stderr
2013-10-18Merge git://github.com/git-l10n/git-poLibravatar Junio C Hamano1-2367/+3193
* git://github.com/git-l10n/git-po: l10n: fr.po: 2135/2135 messages translated
2013-10-18git-merge: document the -S optionLibravatar Nicolas Vigier1-1/+5
The option to gpg sign a merge commit is available but was not documented. Use wording from the git-commit(1) manpage. Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18l10n: fr.po: 2135/2135 messages translatedLibravatar Jean-Noel Avila1-2367/+3193
Signed-off-by: Sebastien Helleu <flashcode@flashtux.org> Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
2013-10-17Update draft release notes to 1.8.5Libravatar Junio C Hamano1-0/+4
2013-10-17Merge branch 'jk/format-patch-from'Libravatar Junio C Hamano4-1/+49
"format-patch --from=<whom>" forgot to omit unnecessary in-body from line, i.e. when <whom> is the same as the real author. * jk/format-patch-from: format-patch: print in-body "From" only when needed
2013-10-17Merge branch 'es/name-hash-no-trailing-slash-in-dirs'Libravatar Junio C Hamano5-51/+50
Clean up the internal of the name-hash mechanism used to work around case insensitivity on some filesystems to cleanly fix a long-standing API glitch where the caller of cache_name_exists() that ask about a directory with a counted string was required to have '/' at one location past the end of the string. * es/name-hash-no-trailing-slash-in-dirs: dir: revert work-around for retired dangerous behavior name-hash: stop storing trailing '/' on paths in index_state.dir_hash employ new explicit "exists in index?" API name-hash: refactor polymorphic index_name_exists()
2013-10-17Merge branch 'jk/trailing-slash-in-pathspec'Libravatar Junio C Hamano3-20/+14
Code refactoring. * jk/trailing-slash-in-pathspec: reset: handle submodule with trailing slash rm: re-use parse_pathspec's trailing-slash removal
2013-10-17Merge branch 'lc/filter-branch-too-many-refs'Libravatar Junio C Hamano1-2/+2
"git filter-branch" in a repository with many refs blew limit of command line length. * lc/filter-branch-too-many-refs: Allow git-filter-branch to process large repositories with lots of branches.
2013-10-17Merge branch 'jc/checkout-detach-doc'Libravatar Junio C Hamano1-6/+8
"git checkout [--detach] <commit>" was listed poorly in the synopsis section of its documentation. * jc/checkout-detach-doc: checkout: update synopsys and documentation on detaching HEAD
2013-10-17Sync with maintLibravatar Junio C Hamano2-21/+65
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17Start preparing for 1.8.4.2Libravatar Junio C Hamano2-1/+51
Signed-off-by: Junio C Hamano <gitster@pobox.com>