git/builtin/clone.c, branch v2.12.2

Merge branch 'rs/absolute-pathdup'

2017-02-02T21:36:55Z

Code cleanup. * rs/absolute-pathdup: use absolute_pathdup() abspath: add absolute_pathdup()

use absolute_pathdup()

2017-01-27T18:18:15Z

Apply the semantic patch for converting callers that duplicate the result of absolute_path() to call absolute_pathdup() instead, which avoids an extra string copy to a static buffer. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jc/lock-report-on-error'

2016-12-19T22:45:35Z

Git 2.11 had a minor regression in "merge --ff-only" that competed with another process that simultanously attempted to update the index. We used to explain what went wrong with an error message, but the new code silently failed. The error message has been resurrected. * jc/lock-report-on-error: lockfile: LOCK_REPORT_ON_ERROR hold_locked_index(): align error handling with hold_lockfile_for_update() wt-status: implement opportunisitc index update correctly

hold_locked_index(): align error handling with hold_lockfile_for_update()

2016-12-07T19:31:59Z

Callers of the hold_locked_index() function pass 0 when they want to prepare to write a new version of the index file without wishing to die or emit an error message when the request fails (e.g. somebody else already held the lock), and pass 1 when they want the call to die upon failure. This option is called LOCK_DIE_ON_ERROR by the underlying lockfile API, and the hold_locked_index() function translates the paramter to LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update(). Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop translating. Callers other than the ones that are replaced with this change pass '0' to the function; no behaviour change is intended with this patch. Signed-off-by: Junio C Hamano --- Among the callers of hold_locked_index() that passes 0: - diff.c::refresh_index_quietly() at the end of "git diff" is an opportunistic update; it leaks the lockfile structure but it is just before the program exits and nobody should care. - builtin/describe.c::cmd_describe(), builtin/commit.c::cmd_status(), sequencer.c::read_and_refresh_cache() are all opportunistic updates and they are OK. - builtin/update-index.c::cmd_update_index() takes a lock upfront but we may end up not needing to update the index (i.e. the entries may be fully up-to-date), in which case we do not need to issue an error upon failure to acquire the lock. We do diagnose and die if we indeed need to update, so it is OK. - wt-status.c::require_clean_work_tree() IS BUGGY. It asks silence, does not check the returned value. Compare with callsites like cmd_describe() and cmd_status() to notice that it is wrong to call update_index_if_able() unconditionally.

clone,fetch: explain the shallow-clone option a little more clearly

2016-12-05T22:50:57Z

"deepen by excluding" does not make sense because excluding a revision does not deepen a repository; it makes the repository more shallow. Signed-off-by: Alex Henrie Signed-off-by: Junio C Hamano

Merge branch 'jk/clone-copy-alternates-fix' into maint

2016-10-28T16:01:14Z

"git clone" of a local repository can be done at the filesystem level, but the codepath did not check errors while copying and adjusting the file that lists alternate object stores. * jk/clone-copy-alternates-fix: clone: detect errors in normalize_path_copy

Merge branch 'jk/clone-copy-alternates-fix'

2016-10-17T20:25:18Z

Merge branch 'nd/shallow-deepen'

2016-10-10T21:03:50Z

The existing "git fetch --depth=" option was hard to use correctly when making the history of an existing shallow clone deeper. A new option, "--deepen=", has been added to make this easier to use. "git clone" also learned "--shallow-since=" and "--shallow-exclude=" options to make it easier to specify "I am interested only in the recent N months worth of history" and "Give me only the history since that version". * nd/shallow-deepen: (27 commits) fetch, upload-pack: --deepen=N extends shallow boundary by N commits upload-pack: add get_reachable_list() upload-pack: split check_unreachable() in two, prep for get_reachable_list() t5500, t5539: tests for shallow depth excluding a ref clone: define shallow clone boundary with --shallow-exclude fetch: define shallow boundary with --shallow-exclude upload-pack: support define shallow boundary by excluding revisions refs: add expand_ref() t5500, t5539: tests for shallow depth since a specific date clone: define shallow clone boundary based on time with --shallow-since fetch: define shallow boundary with --shallow-since upload-pack: add deepen-since to cut shallow repos based on time shallow.c: implement a generic shallow boundary finder based on rev-list fetch-pack: use a separate flag for fetch in deepening mode fetch-pack.c: mark strings for translating fetch-pack: use a common function for verbose printing fetch-pack: use skip_prefix() instead of starts_with() upload-pack: move rev-list code out of check_non_tip() upload-pack: make check_non_tip() clean things up on error upload-pack: tighten number parsing at "deepen" lines ...

clone: detect errors in normalize_path_copy

2016-10-05T17:44:39Z

When we are copying the alternates from the source repository, if we find a relative path that is too deep for the source (e.g., "../../../objects" from "/repo.git/objects"), then normalize_path_copy will report an error and leave trash in the buffer, which we will add to our new alternates file. Instead, let's detect the error, print a warning, and skip copying that alternate. There's no need to die. The relative path is probably just broken cruft in the source repo. If it turns out to have been important for accessing some objects, we rely on other parts of the clone to detect that, just as they would with a missing object in the source repo itself (though note that clones with "-s" are inherently local, which may do fewer object-quality checks in the first place). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'nd/init-core-worktree-in-multi-worktree-world'

2016-10-03T20:30:35Z

"git init" tried to record core.worktree in the repository's 'config' file when GIT_WORK_TREE environment variable was set and it was different from where GIT_DIR appears as ".git" at its top, but the logic was faulty when .git is a "gitdir:" file that points at the real place, causing trouble in working trees that are managed by "git worktree". This has been corrected. * nd/init-core-worktree-in-multi-worktree-world: init: kill git_link variable init: do not set unnecessary core.worktree init: kill set_git_dir_init() init: call set_git_dir_init() from within init_db() init: correct re-initialization from a linked worktree