This command implements the git archive protocol on the server
side. This command is not intended to be used by the end user.
Underlying git-archive command line options are sent over the
protocol from "git-archive --remote=...", just like upload-tar
currently does with "git-tar-tree=...".
As for "git-archive" command implementation, this new command
does not execute any existing "git-{tar,zip}-tree" but rely
on the archive API defined by "git-archive" patch. Hence we
get 2 good points:
- "git-archive" and "git-upload-archive" share all option
parsing code.
- All kind of git-upload-{tar,zip} can be deprecated.
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-archive is a command to make TAR and ZIP archives of a git tree.
It helps prevent a proliferation of git-{format}-tree commands.
Instead of directly calling git-{tar,zip}-tree command, it defines
a very simple API, that archiver should implement and register in
"git-archive.c". This API is made up by 2 functions whose prototype
is defined in "archive.h" file.
- The first one is used to parse 'extra' parameters which have
signification only for the specific archiver. That would allow
different archive backends to have different kind of options.
- The second one is used to ask to an archive backend to build
the archive given some already resolved parameters.
The main reason for making this API is to avoid using
git-{tar,zip}-tree commands, hence making them useless. Maybe it's
time for them to die ?
It also implements remote operations by defining a very simple
protocol: it first sends the name of the specific uploader followed
the repository name (git-upload-tar git://example.org/repo.git).
Then it sends options. It's done by sending a sequence of one
argument per packet, with prefix "argument ", followed by a flush.
The remote protocol is implemented in "git-archive.c" for client
side and is triggered by "--remote=<repo>" option. For example,
to fetch a TAR archive in a remote repo, you can issue:
$ git archive --format=tar --remote=git://xxx/yyy/zzz.git HEAD
We choose to not make a new command "git-fetch-archive" for example,
avoind one more GIT command which should be nice for users (less
commands to remember, keeps existing --remote option).
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This creates a new git-runstatus which should do roughly the same thing
as the run_status function from git-commit.sh. Except for color support,
the main focus has been to keep the output identical, so that it can be
verified as correct and then used as a C platform for other improvements to
the status printing code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the Windows world ZIP files are better supported than tar files.
Windows even includes built-in support for ZIP files nowadays.
git-zip-tree is similar to git-tar-tree; it creates ZIP files out of
git trees. It stores the commit ID (if available) in a ZIP file comment
which can be extracted by unzip.
There's still quite some room for improvement: this initial version
supports no symlinks, calls write() way too often (three times per file)
and there is no unit test.
[jc: with a minor typefix to avoid void* arithmetic]
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Convert git-verify-pack to a builtin command. Also rename ac to argc
and av to argv for consistancy.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This cleans up the build procedure for built-in commands by:
- generating mostly redundant definition of BUILT_INS from
BUILTIN_OBJS in the Makefile,
- renaming a few files to make the above possible, and
- sorting the built-in command table in git.c.
It might be a good idea to binary search (or perfect hash) the built-in
command table, but that can be done later when somebody feels like.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The cmd_usage() routine was causing warning messages due to a NULL
format parameter being passed in three out of four calls. This is a
problem if you want to compile with -Werror. A simple solution is to
simply remove the GNU __attribute__ format pragma from the cmd_usage()
declaration in the header file. The function interface was somewhat
muddled anyway, so re-write the code to finesse the problem.
[jc: this incidentally revealed that t9100 test assumed that the output
from "git help" to be fixed in stone, but this patch lower-cases
"Usage" to "usage". Update the test not to rely on "git help" output.]
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The header builtin.h was, incorrectly, redefining PATH_MAX which
causes a header order dependency in builtin-write-tree.c. The fix
is to simply include <limits.h> directly to obtain the correct
definition of PATH_MAX.
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merges the new built-in calling convention code into Johannes's
builtin-mv topic in order to resolve their conflicts early on.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the calling convention of built-in commands and
passes the "prefix" (i.e. pathname of $PWD relative to the
project root level) down to them.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This also moves add_file_to_index() to read-cache.c. Oh, and while
touching builtin-add.c, it also removes a duplicate git_config() call.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This actually removes the objects to be pruned, unless you specify "-n"
(at which point it will just tell you which files it would prune).
This doesn't do the pack-file pruning that the shell-script used to do,
but if somebody really wants to, they could add it easily enough. I wonder
how useful it is, though, considering that "git repack -a -d" is just a
lot more efficient and generates a better end result.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By being an internal command git-get-commit-id can make use of
struct ustar_header and other stuff and stops wasting precious
disk space.
Note: I recycled one of the two "tar-tree" entries instead of
splitting that cleanup into a separate patch.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git format-patch" a built-in.
* js/fmt-patch:
git-rebase: use canonical A..B syntax to format-patch
git-format-patch: now built-in.
fmt-patch: Support --attach
fmt-patch: understand old <his> notation
Teach fmt-patch about --keep-subject
Teach fmt-patch about --numbered
fmt-patch: implement -o <dir>
fmt-patch: output file names to stdout
Teach fmt-patch to write individual files.
Use RFC2822 dates from "git fmt-patch".
git-fmt-patch: thinkofix to show [PATCH] properly.
rename internal format-patch wip
Minor tweak on subject line in --pretty=email
Tentative built-in format-patch.
This makes 'git add' and 'git rm' built-ins.
* lt/dirwalk:
Add builtin "git rm" command
Move pathspec matching from builtin-add.c into dir.c
Prevent bogus paths from being added to the index.
builtin-add: fix unmatched pathspec warnings.
Remove old "git-add.sh" remnants
builtin-add: warn on unmatched pathspecs
Do "git add" as a builtin
Clean up git-ls-file directory walking library interface
libify git-ls-files directory traversal
* master: (119 commits)
diff family: add --check option
Document that "git add" only adds non-ignored files.
Add a conversion tool to migrate remote information into the config
fetch, pull: ask config for remote information
Fix build procedure for builtin-init-db
read-tree -m -u: do not overwrite or remove untracked working tree files.
apply --cached: do not check newly added file in the working tree
Implement a --dry-run option to git-quiltimport
Implement git-quiltimport
Revert "builtin-grep: workaround for non GNU grep."
builtin-grep: workaround for non GNU grep.
builtin-grep: workaround for non GNU grep.
git-am: use apply --cached
apply --cached: apply a patch without using working tree.
apply --numstat: show new name, not old name.
Documentation/Makefile: create tarballs for the man pages and html files
Allow pickaxe and diff-filter options to be used by git log.
Libify the index refresh logic
Builtin git-init-db
Remove unnecessary local in get_ref_sha1.
...
This makes tar-tree a built-in. As an added bonus, you can now
say:
git tar-tree --remote=remote-repository <ent> [<base>]
This does not work with git-daemon yet, but should work with
localhost and git over ssh transports.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes semantics very subtly, because it adds a new atomicity
guarantee.
In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.
This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.
So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.
This is only an issue with "-f", of course.
I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).
The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Basically this just renames init-db.c to builtin-init-db.c and makes
some strings const.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was surprisingly easy. The diff is truly minimal: rename "main()" to
"cmd_rev_list()" in rev-list.c, and rename the whole file to reflect its
new built-in status.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
First try. Let's see how well this works.
In many ways, the hard parts of "git commit" are not so different from
this, and a builtin commit would share a lot of the code, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/grep: (22 commits)
Fix silly typo in new builtin grep
builtin-grep: unparse more command line options.
builtin-grep: use external grep when we can take advantage of it
builtin-grep: -F (--fixed-strings)
builtin-grep: -w fix
builtin-grep: typofix
builtin-grep: tighten argument parsing.
builtin-grep: documentation
Teach -f <file> option to builtin-grep.
builtin-grep: -L (--files-without-match).
builtin-grep: binary files -a and -I
builtin-grep: terminate correctly at EOF
builtin-grep: tighten path wildcard vs tree traversal.
builtin-grep: support -w (--word-regexp).
builtin-grep: support -c (--count).
builtin-grep: allow more than one patterns.
builtin-grep: allow -<n> and -[ABC]<n> notation for context lines.
builtin-grep: printf %.*s length is int, not ptrdiff_t.
builtin-grep: do not use setup_revisions()
builtin-grep: support '-l' option.
...
* master: (109 commits)
t1300-repo-config: two new config parsing tests.
Another config file parsing fix.
update-index: plug memory leak from prefix_path()
checkout-index: plug memory leak from prefix_path()
update-index --unresolve: work from a subdirectory.
pack-object: squelch eye-candy on non-tty
core.prefersymlinkrefs: use symlinks for .git/HEAD
repo-config: trim white-space before comment
Fix for config file section parsing.
Clarify git-cherry documentation.
Update git-unpack-objects documentation.
Fix up docs where "--" isn't displayed correctly.
Several trivial documentation touch ups.
git-svn 1.0.0
git-svn: documentation updates
delta: stricter constness
Makefile: do not link rev-list any specially.
builtin-push: --all and --tags _are_ explicit refspecs
builtin-log/whatchanged/show: make them official.
show-branch: omit uninteresting merges.
...
This attempts to set up built-in "git grep" to further reduce
our dependence on the shell, while at the same time optionally
allowing to run grep against object database. You could do
funky things like these:
git grep --cached -e pattern ;# grep from index
git grep -e pattern master ;# or in a rev
git grep -e pattern master next ;# or in multiple revs
git grep -e pattern pu^@ ;# even like this with an
;# extension from another topic ;-)
git grep -e pattern master..next ;# or even from rev ranges
git grep -e pattern master~20:Documentation
;# or an arbitrary tree
git grep -e pattern next:git-commit.sh
;# or an arbitrary blob
Right now, it does not understand and/or obey many options grep
should accept, and the pattern must be given with -e option due
to the way the parameter parser is structured, both of which
obviously need to be fixed for usability.
But this is going in the right direction. The shell script
version is one of the worst Portability offender in the git
barebone Porcelainish; it uses xargs -0 to pass paths around and
shell arrays to sift flags and parameters.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also it learned to do -v (verbose) to report:
- number of loose objects
- disk occupied by loose objects
- number of objects in local packs
- number of loose objects that are also in pack
- unrecognised garbage in .git/objects/??/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
Split up builtin commands into separate files from git.c
git-log produces no output
fix pack-object buffer size
mailinfo: decode underscore used in "Q" encoding properly.
Reintroduce svn pools to solve the memory leak.
pack-objects: do not stop at object that is "too small"
git-commit --amend: two fixes.
get_tree_entry(): make it available from tree-walk
sha1_name.c: no need to include diff.h; tree-walk.h will do.
sha1_name.c: prepare to make get_tree_entry() reusable from others.
get_sha1() shorthands for blob/tree objects
pre-commit hook: complain about conflict markers.
git-merge: a bit more readable user guidance.
diff: move diff.c to diff-lib.c to make room.
git log: don't do merge diffs by default
Allow "git repack" users to specify repacking window/depth
Document git-clone --reference
Fix filename scaling for binary files
Fix uninteresting tags in new revision parsing
Conflicts:
Adjusted the addition of fmt-patch to match the recent split
from git.c to builtin.log.c.
Right now it split it into "builtin-log.c" for log-related commands
("log", "show" and "whatchanged"), and "builtin-help.c" for the
informational commands (usage printing and "help" and "version").
This just makes things easier to read, I find.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
