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

Merge branch 'jk/clone-dissociate' into maint

2015-06-16T21:33:52Z

Code clean-up. * jk/clone-dissociate: clone: reorder --dissociate and --reference options clone: use OPT_STRING_LIST for --reference

Merge branch 'mh/clone-verbosity-fix' into maint

2015-06-05T19:00:08Z

Git 2.4 broke setting verbosity and progress levels on "git clone" with native transports. * mh/clone-verbosity-fix: clone: call transport_set_verbosity before anything else on the newly created transport

clone: reorder --dissociate and --reference options

2015-05-27T19:37:39Z

These options are intimately related, so it makes sense to list them nearby in the "-h" output (they are already adjacent in the manpage). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

clone: use OPT_STRING_LIST for --reference

2015-05-27T19:37:28Z

Not only does this save us having to implement a custom callback, but it handles "--no-reference" in the usual way (to clear the list). The generic callback does copy the string, which we don't technically need, but that should not hurt anything. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

clone: call transport_set_verbosity before anything else on the newly created transport

2015-05-19T16:05:55Z

Commit 2879bc3 made the progress and verbosity options sent to remote helper earlier than they previously were. But nothing else after that would send updates if the value is changed later on with transport_set_verbosity. While for fetch and push, transport_set_verbosity is the first thing that is done after creating the transport, it was not the case for clone. So commit 2879bc3 broke changing progress and verbosity for clone, for urls requiring a remote helper only (so, not git:// urls, for instance). Moving transport_set_verbosity to just after the transport is created works around the issue. Signed-off-by: Mike Hommey Signed-off-by: Junio C Hamano

Merge branch 'jk/cleanup-failed-clone' into maint

2015-03-28T16:33:09Z

An failure early in the "git clone" that started creating the working tree and repository could have resulted in some directories and files left without getting cleaned up. * jk/cleanup-failed-clone: clone: drop period from end of die_errno message clone: initialize atexit cleanup handler earlier

Merge branch 'jk/cleanup-failed-clone'

2015-03-25T19:54:24Z

clone: drop period from end of die_errno message

2015-03-19T20:38:36Z

We do not usually end our errors with a full stop, but it looks especially bad when you use die_errno, which adds a colon, like: fatal: could not create work tree dir 'foo'.: No such file or directory Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

clone: initialize atexit cleanup handler earlier

2015-03-19T20:38:07Z

If clone fails, we generally try to clean up any directories we've created. We do this by installing an atexit handler, so that we don't have to manually trigger cleanup. However, since we install this after touching the filesystem, any errors between our initial mkdir() and our atexit() call will result in us leaving a crufty directory around. We can fix this by moving our atexit() call earlier. It's OK to do it before the junk_work_tree variable is set, because remove_junk makes sure the variable is initialized. This means we "activate" the handler by assigning to the junk_work_tree variable, which we now bump down to just after we call mkdir(). We probably do not want to do it before, because a plausible reason for mkdir() to fail is EEXIST (i.e., we are racing with another "git init"), and we would not want to remove their work. OTOH, this is probably not that big a deal; we will allow cloning into an empty directory (and skip the mkdir), which is already racy (i.e., one clone may see the other's empty dir and start writing into it). Still, it does not hurt to err on the side of caution here. Note that writing into junk_work_tree and junk_git_dir after installing the handler is also technically racy, as we call our handler on an async signal. Depending on the platform, we could see a sheared write to the variables. Traditionally we have not worried about this, and indeed we already do this later in the function. If we want to address that, it can come as a separate topic. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

standardize usage info string format

2015-01-14T17:32:04Z

This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing * with [...] Signed-off-by: Alex Henrie Reviewed-by: Matthieu Moy Signed-off-by: Junio C Hamano