Match the main Makefile by separating COPTS from CFLAGS,
defining INSTALL, prefix, and bin. Add a new target 'install-tools'
to the main Makefile to install them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Rename into a "tools" subdirectory, and change name of "dotest" to "applymbox".
Remove stripspace (which was already copied into git) and cvs2git (which
was likewise already copied into git, and then replaced by a much better
perl version).
All of this was brought on by Ryan Anderson shaming me into it. Thanks.
I guess.
Since pull and fetch are done often against the same remote
repository repeatedly, keeping the URL to pull from along with
the name of the head to use in $GIT_DIR/branches/$name makes a
lot of sense. Adopt that convention from Cogito, and try to be
compatible when possible; storing a partial URL and completing
it with a trailing path may not be understood by Cogito.
While we are at it, fix pulling a tag. Earlier, we updated only
refs/tags/$tag without updating FETCH_HEAD, and called
resolve-script using a stale (or absent) FETCH_HEAD.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Now, not all projects can be as refined as Linux. Before the final 1.0
release, we went through fifteen 0.99 patchfiles, and pl14 alone went
through subreleases 'a' through 'z'. Now _that_ is a release process.
Not to mention the odd-ball releases, like 0.96c+
Sadly, in this day and age of RPM's etc, we have silly limitations, and
I cannot call this release '0.99pl5a or some such awe-inspiring name
just because "rpmbuild" is such a party pooper. So it's just 0.99.1.
Oh well. Aspiring to such greatness as the Linux release numbering is
hubris anyway. You can attain such perfection only once in your life.
This makes it straightforward for people wanting to build and install
the git man pages and the rest of the documentation to do so.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This allows rebuilding the tarball when it is already present
without having to answer annoying questions from gzip
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This allows RPMBUILD to be overridden for people with
old versions of rpm or people who want to pass rpmbuild extra options.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Sharing code between shell scripts and C is a challenge. The program
git-var allows us to have a set of named values that a shell script can
interrogate and a normal C program can simply call the functions that
compute them. Allowing sharing when computing plain test values.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
That way we avoid any confusion with "GNU Interactive Tools", and it's
more descriptive anyway (the rpm documentation talks about how git is
split into a "core" part and an "SCM" part, this makes it clear that
this is the core one).
You can use it as
git branch <branchname> [start-point]
and it creates a new branch of name <branchname>. If a starting point
is specified, that will be where the branch is created, otherwise it
will be created at the current HEAD.
The sequence
git branch xyz abc
git checkout xyz
can also be written as
git checkout -b xyz abc
as per the previous commit.
Use git-tar-tree directly from git source during make dist. This
handles bootstrap issue with git not being installed.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch makes the first half of write_sha1_file() and
index_fd() externally visible, to allow callers to compute the
object ID without actually storing it in the object database.
[JC demangled the whitespaces himself because he liked the patch
so much, and reworked the interface to index_fd() slightly,
taking suggestion from Linus and of his own.]
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A useful shell safety helper sq_expand() was hidden as a static
function in diff.c. Extract it out and make it available as
sq_quote().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It sets up the normal git environment variables and a few helper
functions (currently just "die()"), and returns ok if it all looks like
a git archive. So use it something like
. git-sh-setup-script || die "Not a git archive"
to make the rest of the git scripts more careful and readable.
This is the script I use to prepare patches for e-mail submission.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
targets: git.spec, dist, and rpm. A simple 'make rpm' will build the rpm.
Also adds git.spec.in which is used to generate git.spec.
Signed-off-by: Chris Wright <chrisw@osdl.org>
This was invaluable for debugging the zero-sized compression issue, and
might be useful for scripting too, if people want to see the contents of
a pack.
It's meant to be used by "git fetch" for the local and ssh case.
It doesn't actually do the fetching now, but it does discover the common
commit point.
Nico pointed out that having verify_pack.c and verify-pack.c was
confusing. Rename verify_pack.c to pack-check.c as suggested,
and enhances the verification done quite a bit.
- Built-in sha1_file unpacking knows that a base object of a
deltified object _must_ be in the same pack, and takes
advantage of that fact.
- Earlier verify-pack command only checked the SHA1 sum for the
entire pack file and did not look into its contents. It now
checks everything idx file claims to have unpacks correctly.
- It now has a hook to give more detailed information for
objects contained in the pack under -v flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It's not working yet, but it's at the point where I want to be able to
track my changes. The theory of operation is that this is the "remote"
side of a "git push". It can tell us what references the remote side
has, receives out reference update commands and a pack-file, and can
execute the unpacking command.
Given a list of <pack>.idx files, this command validates the
index file and the corresponding .pack file for consistency.
This patch also uses the same validation mechanism in fsck-cache
when the --full flag is used.
During normal operation, sha1_file.c verifies that a given .idx
file matches the .pack file by comparing the SHA1 checksum
stored in .idx file and .pack file as a minimum sanity check.
We may further want to check the pack signature and version when
we map the pack, but that would be a separate patch.
Earlier, errors to map a pack file was not flagged fatal but led
to a random fatal error later. This version explicitly die()s
when such an error is detected.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This makes it match the new delta encoding, and admittedly makes the
code easier to follow.
This also updates the PACK file version to 2, since this (and the delta
encoding change in the previous commit) are incompatible with the old
format.
Packed delta files created by git-pack-objects seems to be the
way to go, and existing "delta" object handling code has exposed
the object representation details to too many places. Remove it
while we refactor code to come up with a proper interface in
sha1_file.c.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We want to be able to check their integrity later, and putting the
sha1-sum of the contents at the end is a good thing. The writing
routines are generic, so we could try to re-use them for the index file,
instead of having the same logic duplicated.
Update unpack-objects to know about the extra 20 bytes at the end
of the index.
This will scan 2 or more object repositories and look for common objects, check
if they are hardlinked, and replace one with a hardlink to the other if not.
This version warns when skipping files because of size differences, and
handle more than 2 repositories automatically.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Cheered-on-by: Jeff Garzik <jgarzik@pobox.com>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Using git-cherry, forward port local commits missing from the
new upstream head. This also depends on "-m" flag support in
git-commit-script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The git-cherry command helps the git-rebase script by finding
commits that have not been merged upstream. Commits already
included in upstream are prefixed with '-' (meaning "drop from
my local pull"), while commits missing from upstream are
prefixed with '+' (meaning "add to the updated upstream").
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
So far it just reads the header and generates the list of objects.
It also sorts them by the order they are written in the pack file,
since that ends up being the same order we got them originally, and
is thus "most recent first".
This is kind of like a tar-ball for a set of objects, ready to be
shipped off to another end. Alternatively, you could use is as a packed
representation of the object database directly, if you changed
"read_sha1_file()" to read these kinds of packs.
The latter is partiularly useful to generate a "packed history", ie you
could pack up your old history efficiently, but still have it available
(at a performance hit, of course).
I haven't actually written an unpacker yet, so the end result has not
been verified in any way yet. I obviously always write bug-free code,
so it just has to work, no?
A "patch ID" is nothing but a SHA1 of the diff associated with a patch,
with whitespace and line numbers ignored. As such, it's "reasonably
stable", but at the same time also reasonably unique, ie two patches
that have the same "patch ID" are almost guaranteed to be the same
thing.
IOW, you can use this thing to look for likely duplicate commits.
It is careful by default and refuses to overwrite old info, but if you
want to force everything to be re-read, use the "-f" flag.
Some day I'll make it take individual filenames too. Right now
it's all-or-nothing.
Fix permissions, and add trivial "reset" and "add" scripts.
The "reset" script just resets the index back to head, while the "add"
script is just a crutch for people used to do "cvs add".
Junio C Hamano