clone: forbid --bare --separate-git-dir <dir>

The --separate-git-dir option was introduced to make it simple to put
the git directory somewhere outside the worktree, for example when
cloning a repository for use as a submodule.

It was not intended for use when creating a bare repository. In that
case there is no worktree and it is more natural to directly clone the
repository and create a .git file as separate steps:

        git clone --bare /path/to/repo.git bar.git
        printf 'gitdir: bar.git\n' >foo.git

Forbid the combination, making the command easier to explain.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsimport: rewrite to use cvsps 3.x to fix major bugs

The combination of git-cvsimport and cvsps had serious problems.

Among these were:

 (1) Analysis of branchy repos was buggy in multiple ways in both
     programs, leading to incorrect repo translations.

 (2) Even after a correct branch analysis, extra (redundant) fileops
     would often be generated on the new-branch side.

 (3) Inability to report more than one tag pointing to the same revision.

 (4) Failure in certain cases of clock-skew reported by the t9603 test.

 (5) Failure to use commitids for changeset ordering in cases were this
     would have prevented clock skew from causing incorrect grouping.

Problems 2-5 and portions of problem 1 have been solved by a major
rewrite of cvsps (the 3.x release series); it now emits a git
fast-import stream.  Also, the buggy attempt at ancestry-branch
tracking previously invoked by -A has been replaced with a simpler and
better topo analysis.  cvsps is now about 20% smaller than formerly.

All this changed cvsps's interface enough to require a complete
rewrite of git-cvsimport (hence this patch). In the process the code
size of the wrapper script dropped by about x3 and it can now support
alternate conversion engines; the first new engine is cvs2git, with
parsecvs expected to follow shortly.

The old Perl git-cvsimport is moved to git-cvsimport-fallback; new
git-cvsimport will hand off to the fallback script when it detects
that the user has a pre-3.x cvsps.  The fallback is only there so that
people with simple enough repositories that can be correctly handled
by cvsps-2.x but without the bleeding-edge cvsps 3.x installed does
not have to be left without any cvsimport that works for them (with
the same bugs and all).  The fallback support will be removed after
cvsps 3.x and the rewritten cvsimport matures and gets widely
available.

This patch also removes Michael Haggerty's git-cvsimport tests
(t960[123]) from the git tree.  These are actually conversion-engine
tests and have been merged into a larger cvsps test suite, which I
intend to spin out into a general CVS-lifting test that can also be
applied to utilities such as cvs2git and parsecvs.  The t9604 test
will move in a future patch, when I likewise have it integrated
into the general test suite.

The following known bug has not been fixed: "If any files were ever
"cvs import"ed more than once (e.g., import of more than one vendor
release) the HEAD contains the wrong content." However, cvsps now
emits a warning in this case. There is also one pathological tagging
case that was successful in the former t9602 test that now fails
(with a warning).

I plan to address these problems. This patch at least gets the
cvsps-3.x/git-cvsimport combination to a state that is not too
broken to ship - that is, in all failure cases known to me it
now emits useful warnings rather than silently botching the
import.

Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.bash: silence "not a valid object" errors

Trying to complete the command

  git show master:./file

would cause a "Not a valid object name" error to be output on standard
error. Silence the error so it won't appear on the command line.

Signed-off-by: Dylan Smith <dylan.ah.smith@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: add --unshallow for turning shallow repo into complete one

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>
upload-pack: fix off-by-one depth calculation in shallow clone

get_shallow_commits() is used to determine the cut points at a given
depth (i.e. the number of commits in a chain that the user likes to
get). However we count current depth up to the commit "commit" but we
do the cutting at its parents (i.e. current depth + 1). This makes
upload-pack always return one commit more than requested. This patch
fixes it.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: elaborate --depth action

--depth is explained as deepen, but the way it's applied, it can
shorten the history as well. Keen users may have noticed the
implication by the phrase "the specified number of commits from the
tip of each remote branch". Put "shorten" in the description to make
it clearer.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/lib-cvs.sh: allow cvsps version 3.x.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9600: fixup for new cvsimport

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9604: fixup for new cvsimport

Signed-off-by: Junio C Hamano <gitster@pobox.com>
pathspec: save the non-wildcard length part

We mark pathspec with wildcards with the field use_wildcard. We
could do better by saving the length of the non-wildcard part, which
can be used for optimizations such as f9f6e2c (exclude: do strcmp as
much as possible before fnmatch - 2012-06-07).

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add parse_pathspec() that converts cmdline args to struct pathspec

Currently to fill a struct pathspec, we do:

   const char **paths;
   paths = get_pathspec(prefix, argv);
   ...
   init_pathspec(&pathspec, paths);

"paths" can only carry bare strings, which loses information from
command line arguments such as pathspec magic or the prefix part's
length for each argument.

parse_pathspec() is introduced to combine the two calls into one. The
plan is gradually replace all get_pathspec() and init_pathspec() with
parse_pathspec(). get_pathspec() now becomes a thin wrapper of
parse_pathspec().

parse_pathspec() allows the caller to reject the pathspec magics that
it does not support. When a new pathspec magic is introduced, we can
enable it per command after making sure that all underlying code has no
problem with the new magic.

"flags" parameter is currently unused. But it would allow callers to
pass certain instructions to parse_pathspec, for example forcing
literal pathspec when no magic is used.

With the introduction of parse_pathspec, there are now two functions
that can initialize struct pathspec: init_pathspec and
parse_pathspec. Any semantic changes in struct pathspec must be
reflected in both functions. init_pathspec() will be phased out in
favor of parse_pathspec().

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Export parse_pathspec() and convert some get_pathspec() calls

These call sites follow the pattern:

   paths = get_pathspec(prefix, argv);
   init_pathspec(&pathspec, paths);

which can be converted into a single parse_pathspec() call.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clean: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rm: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ls-files: convert to use parse_pathspec

strip_trailing_slash_from_submodules() modifies pathspec and is moved
to dir.c, close to other pathspec code. It'll be removed later when
parse_pathspec() learns to take over its job.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
archive: convert to use parse_pathspec

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>