summaryrefslogtreecommitdiff
path: root/builtin/fetch.c
AgeCommit message (Collapse)AuthorFilesLines
2013-06-14Merge branch 'mh/reflife'Libravatar Junio C Hamano1-12/+17
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-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-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-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-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>
2013-05-12refactor "ref->merge" flagLibravatar Jeff King1-22/+35
Each "struct ref" has a boolean flag that is set by the fetch code to determine whether the ref should be marked as "not-for-merge" or not when we write it out to FETCH_HEAD. It would be useful to turn this boolean into a tri-state, with the third state meaning "do not bother writing it out to FETCH_HEAD at all". That would let us add extra refs to the set of refs to be stored (e.g., to store copies of things we fetched) without impacting FETCH_HEAD. This patch turns it into an enum that covers the tri-state case, and hopefully makes the code more explicit and easier to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Merge branch 'jk/gc-auto-after-fetch'Libravatar Junio C Hamano1-0/+5
Help "fetch only" repositories that do not trigger "gc --auto" often enough. * jk/gc-auto-after-fetch: fetch-pack: avoid repeatedly re-scanning pack directory fetch: run gc --auto after fetching
2013-01-26Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetchLibravatar Junio C Hamano1-0/+5
* jk/maint-gc-auto-after-fetch: fetch-pack: avoid repeatedly re-scanning pack directory fetch: run gc --auto after fetching
2013-01-26fetch: run gc --auto after fetchingLibravatar Jeff King1-0/+5
We generally try to run "gc --auto" after any commands that might introduce a large number of new objects. An obvious place to do so is after running "fetch", which may introduce new loose objects or packs (depending on the size of the fetch). While an active developer repository will probably eventually trigger a "gc --auto" on another action (e.g., git-rebase), there are two good reasons why it is nicer to do it at fetch time: 1. Read-only repositories which track an upstream (e.g., a continuous integration server which fetches and builds, but never makes new commits) will accrue loose objects and small packs, but never coalesce them into a more efficient larger pack. 2. Fetching is often already perceived to be slow to the user, since they have to wait on the network. It's much more pleasant to include a potentially slow auto-gc as part of the already-long network fetch than in the middle of productive work with git-rebase or similar. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11fetch: add --unshallow for turning shallow repo into complete oneLibravatar Nguyễn Thái Ngọc Duy1-1/+16
The user can do --depth=2147483647 (*) for restoring complete repo now. But it's hard to remember. Any other numbers larger than the longest commit chain in the repository would also do, but some guessing may be involved. Make easy-to-remember --unshallow an alias for --depth=2147483647. Make upload-pack recognize this special number as infinite depth. The effect is essentially the same as before, except that upload-pack is more efficient because it does not have to traverse to the bottom anymore. The chance of a user actually wanting exactly 2147483647 commits depth, not infinite, on a repository with a history that long, is probably too small to consider. The client can learn to add or subtract one commit to avoid the special treatment when that actually happens. (*) This is the largest positive number a 32-bit signed integer can contain. JGit and older C Git store depth as "int" so both are OK with this number. Dulwich does not support shallow clone. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-24Merge branch 'dj/fetch-all-tags' into maintLibravatar Junio C Hamano1-22/+29
"git fetch --all", when passed "--no-tags", did not honor the "--no-tags" option while fetching from individual remotes (the same issue existed with "--tags", but combination "--all --tags" makes much less sense than "--all --no-tags"). * dj/fetch-all-tags: fetch --all: pass --tags/--no-tags through to each remote submodule: use argv_array instead of hand-building arrays fetch: use argv_array instead of hand-building arrays argv-array: fix bogus cast when freeing array argv-array: add pop function
2012-09-18Merge branch 'nd/fetch-status-alignment'Libravatar Junio C Hamano1-8/+7
The status report from "git fetch", when messages like 'up-to-date' are translated, did not align the branch names well. * nd/fetch-status-alignment: fetch: align per-ref summary report in UTF-8 locales
2012-09-14fetch: align per-ref summary report in UTF-8 localesLibravatar Nguyễn Thái Ngọc Duy1-8/+7
fetch does printf("%-*s", width, "foo") where "foo" can be a utf-8 string, but width is in bytes, not columns. For ASCII it's fine as one byte takes one column. For utf-8, this may result in misaligned ref summary table. Introduce gettext_width() function that returns the string length in columns (currently only supports utf-8 locales). Make the code use TRANSPORT_SUMMARY(x) where the length is compensated properly in non-English locales. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'dj/fetch-all-tags'Libravatar Junio C Hamano1-0/+4
"git fetch --all", when passed "--no-tags", did not honor the "--no-tags" option while fetching from individual remotes (the same issue existed with "--tags", but combination "--all --tags" makes much less sense than "--all --no-tags"). * dj/fetch-all-tags: fetch --all: pass --tags/--no-tags through to each remote
2012-09-11Merge branch 'jk/argv-array'Libravatar Junio C Hamano1-22/+25
Use argv-array API in "git fetch" implementation. * jk/argv-array: submodule: use argv_array instead of hand-building arrays fetch: use argv_array instead of hand-building arrays argv-array: fix bogus cast when freeing array argv-array: add pop function
2012-09-11Merge branch 'jc/merge-bases'Libravatar Junio C Hamano1-1/+1
Optimise the "merge-base" computation a bit, and also update its users that do not need the full merge-base information to call a cheaper subset. * jc/merge-bases: reduce_heads(): reimplement on top of remove_redundant() merge-base: "--is-ancestor A B" get_merge_bases_many(): walk from many tips in parallel in_merge_bases(): use paint_down_to_common() merge_bases_many(): split out the logic to paint history in_merge_bases(): omit unnecessary redundant common ancestor reduction http-push: use in_merge_bases() for fast-forward check receive-pack: use in_merge_bases() for fast-forward check in_merge_bases(): support only one "other" commit
2012-09-07fetch --all: pass --tags/--no-tags through to each remoteLibravatar Dan Johnson1-0/+4
When fetch is invoked with --all, we need to pass the tag-following preference to each individual fetch; without this, we will always auto-follow tags, preventing us from fetching the remote tags into a remote-specific namespace, for example. Reported-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Dan Johnson <ComputerDruid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02submodule: use argv_array instead of hand-building arraysLibravatar Jens Lehmann1-1/+1
fetch_populated_submodules() allocates the full argv array it uses to recurse into the submodules from the number of given options plus the six argv values it is going to add. It then initializes it with those values which won't change during the iteration and copies the given options into it. Inside the loop the two argv values different for each submodule get replaced with those currently valid. However, this technique is brittle and error-prone (as the comment to explain the magic number 6 indicates), so let's replace it with an argv_array. Instead of replacing the argv values, push them to the argv_array just before the run_command() call (including the option separating them) and pop them from the argv_array right after that. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02fetch: use argv_array instead of hand-building arraysLibravatar Jeff King1-22/+25
Fetch invokes itself recursively when recursing into submodules or handling "fetch --multiple". In both cases, it builds the child's command line by pushing options onto a statically-sized array. In both cases, the array is currently just big enough to handle the largest possible case. However, this technique is brittle and error-prone, so let's replace it with a dynamic argv_array. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27in_merge_bases(): support only one "other" commitLibravatar Junio C Hamano1-1/+1
In early days of its life, I planned to make it possible to compute "is a commit contained in all of these other commits?" with this function, but it turned out that no caller needed it. Just make it take two commit objects and add a comment to say what these two functions do. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: fetch: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-24/+24
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'nd/i18n'Libravatar Junio C Hamano1-2/+2
More message strings marked for i18n. By Nguyễn Thái Ngọc Duy (10) and Jonathan Nieder (1) * nd/i18n: help: replace underlining "help -a" headers using hyphens with a blank line i18n: bundle: mark strings for translation i18n: index-pack: mark strings for translation i18n: apply: update say_patch_name to give translators complete sentence i18n: apply: mark strings for translation i18n: remote: mark strings for translation i18n: make warn_dangling_symref() automatically append \n i18n: help: mark strings for translation i18n: mark relative dates for translation strbuf: convenience format functions with \n automatically appended Makefile: feed all header files to xgettext
2012-04-26Merge branch 'mb/fetch-call-a-non-branch-a-ref'Libravatar Junio C Hamano1-4/+13
The report from "git fetch" said "new branch" even for a non branch ref. By Marc Branchaud * mb/fetch-call-a-non-branch-a-ref: fetch: describe new refs based on where it came from fetch: Give remote_ref to update_local_ref() as well
2012-04-24i18n: make warn_dangling_symref() automatically append \nLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This helps remove \n from translatable strings Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-23Merge branch 'jl/maint-submodule-recurse-fetch'Libravatar Junio C Hamano1-3/+3
"git fetch" that recurses into submodules on demand did not check if it needs to go into submodules when non branches (most notably, tags) are fetched. By Jens Lehmann * jl/maint-submodule-recurse-fetch: submodules: recursive fetch also checks new tags for submodule commits
2012-04-17fetch: describe new refs based on where it came fromLibravatar Marc Branchaud1-3/+11
update_local_ref() used to say "[new branch]" when we stored a new ref outside refs/tags/ hierarchy, but the message is more about what we fetched, so use the refname at the origin to make that decision. Also, only call a new ref a "branch" if it's under refs/heads/. Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17fetch: Give remote_ref to update_local_ref() as wellLibravatar Marc Branchaud1-1/+2
This way, the function can look at the remote side to adjust the informational message it gives. Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-14submodules: recursive fetch also checks new tags for submodule commitsLibravatar Jens Lehmann1-3/+3
Since 88a21979c (fetch/pull: recurse into submodules when necessary) all fetched commits are examined if they contain submodule changes (unless configuration or command line options inhibit that). If a newly recorded submodule commit is not present in the submodule, a fetch is run inside it to download that commit. Checking new refs was done in an else branch where it wasn't executed for tags. This normally isn't a problem because tags are only fetched with the branches they live on, then checking the new commits in the fetched branches for submodule commits will also process all tags. But when a specific tag is fetched (or the refspec contains refs/tags/) commits only reachable by tags won't be searched for submodule commits, which is a bug. Fix that by moving the code outside the if/else construct to handle new tags just like any other ref. The performance impact of adding tags that most of the time lie on a branch which is checked anyway for new submodule commit should be minimal, as since 6859de4 (fetch: avoid quadratic loop checking for updated submodules) all ref-tips are collected first and then fed to a single rev-list. Spotted-by: Jeff King <peff@peff.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-20Merge branch 'cb/transfer-no-progress'Libravatar Junio C Hamano1-2/+2
* cb/transfer-no-progress: push/fetch/clone --no-progress suppresses progress output
2012-02-13push/fetch/clone --no-progress suppresses progress outputLibravatar Clemens Buchacher1-2/+2
By default, progress output is disabled if stderr is not a terminal. The --progress option can be used to force progress output anyways. Conversely, --no-progress does not force progress output. In particular, if stderr is a terminal, progress output is enabled. This is unintuitive. Change --no-progress to force output off. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-29Merge branch 'nd/maint-refname-in-hierarchy-check'Libravatar Junio C Hamano1-1/+1
* nd/maint-refname-in-hierarchy-check: Fix incorrect ref namespace check
2012-01-11Fix incorrect ref namespace checkLibravatar Nguyễn Thái Ngọc Duy1-1/+1
The reason why the trailing slash is needed is obvious. refs/stash and HEAD are not namespace, but complete refs. Do full string compare on them. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-03write first for-merge ref to FETCH_HEAD firstLibravatar Joey Hess1-74/+86
The FETCH_HEAD refname is supposed to refer to the ref that was fetched and should be merged. However all fetched refs are written to .git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply takes the first ref as the FETCH_HEAD, which is often the wrong one, when other branches were also fetched. The solution is to write the for-merge ref(s) to FETCH_HEAD first. Then, unless --append is used, the FETCH_HEAD refname behaves as intended. If the user uses --append, they presumably are doing so in order to preserve the old FETCH_HEAD. While we are at it, update an old example in the read-tree documentation that implied that each entry in FETCH_HEAD only has the object name, which is not true for quite a while. [jc: adjusted tests] Signed-off-by: Joey Hess <joey@kitenet.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'maint'Libravatar Junio C Hamano1-38/+49
* maint: Update draft release notes for 1.7.8.1 Git 1.7.7.5 Git 1.7.6.5 blame: don't overflow time buffer fetch: create status table using strbuf Conflicts: RelNotes
2011-12-13Merge branch 'maint-1.7.7' into maintLibravatar Junio C Hamano1-38/+49
* maint-1.7.7: Git 1.7.7.5 Git 1.7.6.5 blame: don't overflow time buffer fetch: create status table using strbuf checkout,merge: loosen overwriting untracked file check based on info/exclude cast variable in call to free() in builtin/diff.c and submodule.c apply: get rid of useless x < 0 comparison on a size_t type Conflicts: Documentation/git.txt GIT-VERSION-GEN RelNotes builtin/fetch.c
2011-12-13Merge branch 'maint-1.7.6' into maint-1.7.7Libravatar Junio C Hamano1-38/+49
* maint-1.7.6: Git 1.7.6.5 blame: don't overflow time buffer fetch: create status table using strbuf Conflicts: Documentation/git.txt GIT-VERSION-GEN RelNotes
2011-12-13Merge branch 'jk/maint-fetch-status-table' into maint-1.7.6Libravatar Junio C Hamano1-38/+49
* jk/maint-fetch-status-table: fetch: create status table using strbuf
2011-12-09fetch: create status table using strbufLibravatar Jeff King1-38/+49
When we fetch from a remote, we print a status table like: From url * [new branch] foo -> origin/foo We create this table in a static buffer using sprintf. If the remote refnames are long, they can overflow this buffer and smash the stack. Instead, let's use a strbuf to build the string. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-2/+1
* jc/pull-signed-tag: commit-tree: teach -m/-F options to read logs from elsewhere commit-tree: update the command line parsing commit: teach --amend to carry forward extra headers merge: force edit and no-ff mode when merging a tag object commit: copy merged signed tags to headers of merge commit merge: record tag objects without peeling in MERGE_HEAD merge: make usage of commit->util more extensible fmt-merge-msg: Add contents of merged tag in the merge message fmt-merge-msg: package options into a structure fmt-merge-msg: avoid early returns refs DWIMmery: use the same rule for both "git fetch" and others fetch: allow "git fetch $there v1.0" to fetch a tag merge: notice local merging of tags and keep it unwrapped fetch: do not store peeled tag object names in FETCH_HEAD Split GPG interface into its own helper library Conflicts: builtin/fmt-merge-msg.c builtin/merge.c
2011-11-04fetch: do not store peeled tag object names in FETCH_HEADLibravatar Linus Torvalds1-2/+1
We do not want to record tags as parents of a merge when the user does "git pull $there tag v1.0" to merge tagged commit, but that is not a good enough excuse to peel the tag down to commit when storing in FETCH_HEAD. The caller of underlying "git fetch $there tag v1.0" may have other uses of information contained in v1.0 tag in mind. [jc: the test adjustment is to update for the new expectation] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-26Merge branch 'cn/fetch-prune'Libravatar Junio C Hamano1-5/+28
* cn/fetch-prune: fetch: treat --tags like refs/tags/*:refs/tags/* when pruning fetch: honor the user-provided refspecs when pruning refs remote: separate out the remote_find_tracking logic into query_refspecs t5510: add tests for fetch --prune fetch: free all the additional refspecs Conflicts: remote.c
2011-10-17Merge branch 'tc/fetch-leak'Libravatar Junio C Hamano1-4/+9
* tc/fetch-leak: fetch: plug two leaks on error exit in store_updated_refs Conflicts: builtin/fetch.c
2011-10-15fetch: treat --tags like refs/tags/*:refs/tags/* when pruningLibravatar Carlos Martín Nieto1-2/+21
If --tags is specified, add that refspec to the list given to prune_refs so it knows to treat it as a filter on what refs to should consider for prunning. This way git fetch --prune --tags origin only prunes tags and doesn't delete the branch refs. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-15fetch: honor the user-provided refspecs when pruning refsLibravatar Carlos Martín Nieto1-4/+8
If the user gave us refspecs on the command line, we should use those when deciding whether to prune a ref instead of relying on the refspecs in the config. Previously, running git fetch --prune origin refs/heads/master:refs/remotes/origin/master would delete every other ref under the origin namespace because we were using the refspec to filter the available refs but using the configured refspec to figure out if a ref had been deleted on the remote. This is clearly the wrong thing to do. Change prune_refs and get_stale_heads to simply accept a list of references and a list of refspecs. The caller of either function needs to decide what refspecs should be used to decide whether a ref is stale. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-07fetch: plug two leaks on error exit in store_updated_refsLibravatar Tay Ray Chuan1-4/+9
Close FETCH_HEAD and release the string url even if we have to leave the function store_updated_refs() early. Reported-by: Chris Wilson <cwilson@vigilantsw.com> Helped-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-07fetch: free all the additional refspecsLibravatar Carlos Martín Nieto1-1/+1
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'jc/receive-verify'Libravatar Junio C Hamano1-56/+14
* jc/receive-verify: receive-pack: check connectivity before concluding "git push" check_everything_connected(): libify check_everything_connected(): refactor to use an iterator fetch: verify we have everything we need before updating our ref Conflicts: builtin/fetch.c
2011-10-05Merge branch 'jc/fetch-verify'Libravatar Junio C Hamano1-56/+63
* jc/fetch-verify: fetch: verify we have everything we need before updating our ref rev-list --verify-object list-objects: pass callback data to show_objects()