Linus Torvalds:
make checkout-index '-a' flag saner.
Junio C Hamano:
whatchanged: document -m option from git-diff-tree.
Functions to quote and unquote pathnames in C-style.
Update git-apply to use C-style quoting for funny pathnames.
Do not quote SP.
git-checkout-index: documentation updates.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Contains the following changes since v0.99.8c.
Johannes Schindelin:
Teach git-status about spaces in file names also on MacOSX
t5400-send-pack relies on a working cpio
Jonas Fonseca:
git.sh: quote all paths
Junio C Hamano:
Also force LC_ALL in test scripts.
OpenBSD needs the strcasestr replacement.
git-check-ref-format: reject funny ref names.
Refuse to create funny refs in clone-pack, git-fetch and receive-pack.
Ignore funny refname sent from remote
Introduce notation "ref^{type}".
Martin Langhoff:
cvsimport: don't pass --cvs-direct if user options contradict us
Ralf Baechle:
rsh.c: typo fix
Note that "funny ref" bits are not strictly fixes but rather
backport from the "master" branch. They will prevent refs and
heads with funny names from being created. In addition, what is
in the master branch will start feeding the clients unwrapped
tag information to help Martin's findtags and possibly later
Cogito. These backported "funny ref" changes are to prevent
clients on the "maint" branch from getting confused when talking
with newer git-upload-pack and when reading from info/refs file
prepared with newer git-update-server-info.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do our own ctype.h, just to get the sane semantics: we want
locale-independence, _and_ we want the right signed behaviour. Plus we
only use a very small subset of ctype.h anyway (isspace, isalpha,
isdigit and isalnum).
Signed-off-by: Junio C Hamano <junkio@cox.net>
A short perl script that will walk the tag refs, tag objects, and even commit
objects in its quest to figure out whether the given SHA1 (for a commit or
tree) was ever tagged.
This version is reworked incorporating sanity, feature and style fixes from
Junio.
Usage: git-findtags.perl [ -t ] <commit-or-tree-sha1>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-index-pack builds a pack index file for an existing packed
archive. With this utility a packed archive which was transferred
without the corresponding pack index can be added to objects/pack/
without repacking.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This starts using the "user.name" and "user.email" config variables if
they exist as the default name and email when committing. This means
that you don't have to use the GIT_COMMITTER_EMAIL environment variable
to override your email - you can just edit the config file instead.
The patch looks bigger than it is because it makes the default name and
email information non-static and renames it appropriately. And it moves
the common git environment variables into a new library file, so that
you can link against libgit.a and get the git environment without having
to link in zlib and libcrypt.
In short, most of it is renaming and moving, the real change core is
just a few new lines in "git_default_config()" that copies the user
config values to the new base.
It also changes "git-var -l" to list the config variables.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If somebody set template_dir in config.mak. Then git-init-db would be
compiled with the correct location but the templates would be installed
in the default location. Fix it.
Signed-off-by: Tom Prince <tom.prince@ualberta.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, it is possible to store configuration options like
NO_CURL=YesPlease or NO_OPENSSL=YesPlease into a file named
config.mak, which will be included in the Makefile.
[jc: redone with suggestion from Daniel Barkalow to just use -include]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a first cut at a very simple parser for a git config file.
The format of the file is a simple ini-file like thing, with simple
variable/value pairs. You can (and should) make the variables have a
simple single-level scope, ie a valid file looks something like this:
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = "/usr/local/bin/gnu-diff -u"
renames = true
which parses into three variables: "core.filemode" is associated with the
string "false", and "diff.external" gets the appropriate quoted value.
Right now we only react to one variable: "core.filemode" is a boolean that
decides if we should care about the 0100 (user-execute) bit of the stat
information. Even that is just a parsing demonstration - this doesn't
actually implement that st_mode compare logic itself.
Different programs can react to different config options, although they
should always fall back to calling "git_default_config()" on any config
option name that they don't recognize.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As the name suggests, this script imports from SVN.
Only "normal" SVN repositories (with single trunk/, branches/, and tags/
subdrectories) are supported. Incremental imports require preserving
the file .git/svn2git.
Signed-Off-by: Matthias Urlichs <smurf@smurf.noris.de>
The platform specific tweaking part was using 'uname -o' which
is not always available. Squelch error message from it.
It was suggested to chain the if..else, but I chose not to, because
maintaining the nested if..else if..else..endif endif to match is a
pain. If we had "elif", things would have been different, though.
While we are at it, try not to invoke 'uname -s' for each platform
candidate.
Signed-off-by: Junio C Hamano <junkio@cox.net>
exports $prefix and makes Documentation/Makefile following it also.
Signed-off-by: Kai Ruemmler <kai.ruemmler@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since some platforms do not support mmap() at all, and others do only just
so, this patch introduces the option to fake mmap() and munmap() by
malloc()ing and read()ing explicitely.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Borrow from NO_MMAP patch by Johannes, squelch compiler warnings by
declaring gitstrcasestr() when we use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It reorganizes the code and also has saner command line options
syntax. Unlike git-applymbox, it can take more than one mailbox
file from the command line, as well as reading from the standard
input when '-' is specified.
Signed-off-by: Junio C Hamano <junkio@cox.net>
H. Peter Anvin says that Samba "promotes" symlinks to hardlinks while
Cygwin itself uses .lnk files to emulate symlinks. Avoid using symbolic
link for .git/HEAD on Cygwin.
This does not help the symlinks recorded in trees as user data, but
at least we do not use them for our own bookkeeping.
Signed-off-by: Junio C Hamano <junkio@cox.net>
GIT already did everything I wanted it to do since mid 0.99.7,
and it has almost everything I want it to have now, except a
couple of minor tweaks and enhancements.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the platform lacks certain git subcommands, omit them from the
list of subcommands that are available from "git" wrapper.
Noticed by Geert Bosch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
- The location of openssl development files got customizable.
- The location of iconv development files got customizable.
- Pass $TAR down to t5000 test so that the user can override with
'gmake TAR=gtar'.
- Solaris 'bc' does not seem to grok "define abs()". There is no
reason to use bc there -- expr would do.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs". By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.
The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
After seeing Jeff's guide, I changed my mind about the
big-rename transition plan. Even if Porcelains are kept up to
date, those web documents that describes older world order would
live longer and people will stumble across them via google
searches. And who knows how many mirrored copies there are.
The backward compatible symbolic links *will* be removed before
1.0. But that will not happen in 0.99.8.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a careful version of the script stuff that currently just
blindly writes HEAD with a new value.
You can use
git-update-ref HEAD <newhead>
or
git-update-ref HEAD <newhead> <oldhead>
where the latter version verifies that the old value of HEAD matches
oldhead.
It basically allows a "ref" file to be a symbolic pointer to another ref
file by starting with the four-byte header sequence of "ref:".
More importantly, it allows the update of a ref file to follow these
symbolic pointers, whether they are symlinks or these "regular file
symbolic refs".
NOTE! It follows _real_ symlinks only if they start with "refs/":
otherwise it will just try to read them and update them as a regular file
(ie it will allow the filesystem to follow them, but will overwrite such a
symlink to somewhere else with a regular filename).
In general, using
git-update-ref HEAD "$head"
should be a _lot_ safer than doing
echo "$head" > "$GIT_DIR/HEAD"
both from a symlink following standpoint _and_ an error checking
standpoint. The "refs/" rule for symlinks means that symlinks that point
to "outside" the tree are safe: they'll be followed for reading but not
for writing (so we'll never write through a ref symlink to some other
tree, if you have copied a whole archive by creating a symlink tree).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we conditionally compile things in compat/, so we should remove
object files there. Python execution can leave *.pyc and *.pyo, which
need to be cleaned as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also cmd-renames.sh can now be used to remove the backward compatible
symlinks -- this is not used by default in any way.
As discussed on the list with Pasky, git-ssh-push and git-ssh-pull will
keep calling each other for a while longer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pasky taught me how he does his versioning for ELinks. This will sort
after 0.99.7 and interim fixes 0.99.7a, and before 0.99.8.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Contains the following post-0.99.7b fixes:
- rsh.c string termination fix by H. Peter Anvin
- further fetch fixes by Sergey Vlasov
- diff-tree documentation by Robert Watson.
- 'git diff --cached' synonymous to 'git diff --cached HEAD'.
- subprocess.py licensing status clarification.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Taking the make command line Peter Eriksen uses, give defaults
to SHELL_PATH, TAR, CURLDIR, NO_STRCASESTR, and INSTALL.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Support systems that do not install curl headers and libraries
in /usr/{include,lib}.
Signed-off-by: Patrick Mauritz <oxygene@studentenbude.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Including the current branch in the list of heads being merged
was not a good idea, so drop it. And shorten the message by
grouping branches and tags together to form a single line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The textual diff generation with built-in '-p' in diff-* brothers has
proven to be useful enough that git-diff-helper outlived its usefulness.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some old scripts might still use git-rev-tree, but it really is
clearly inferior in every way to git-rev-list that such scripts should
be fixed anyway. Fixing them should be pretty easy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-export was done as a concept example on how easy it is to export
the git data to something else. It's much less powerful than any
number of trivial one-liner scripts now, and real exporters would not
ever use git-export.
It's obviously much less powerful than "git-whatchanged", or just
about any combination of git-rev-list + git-diff-tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is my ARM assembly SHA1 implementation for GIT. It is approximately
50% faster than the generic C version. On an XScale processor running at
400MHz:
generic C version: 9.8 MB/s
my version: 14.5 MB/s
It's not that I expect a lot of big GIT users on ARM, but I stillknow
about one important ARM user that might benefit from it, and writing
that code was fun.
I also reworked the makefile a bit so any optimized SHA1 implementations
is used regardless of whether NO_OPENSSL is defined or not.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some C libraries lack strcasestr(); add a stupid replacement
to help folks with such.
[jc: original Linus posting, updated with his "also need <ctype.h>",
updated further with a fix from Joachim B Haga <cjhaga@fys.uio.no>"]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Jason Riedy suggests that we should be able to use getdomainname
if we properly specify which libraries to link.
Signed-off-by: Junio C Hamano <junkio@cox.net>
HPA reminded me that these programs knows about the name of the
counterpart on the other end and simply symlinking the old name to
new name locally would not be enough.
Signed-off-by: Junio C Hamano <junkio@cox.net>
... in order to please Solaris 'install'. GNU install is not harmed
with this.
[jc: Documentation/Makefile also fixed.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise we would regret when Fredrik comes up with another merge
algorithm with different pros-and-cons with the current one.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Very convenient shorthand for
git-ls-files [file-patterns] | xargs grep <pattern>
which I tend to do all the time.
Yes, it's trivial, but it's really nice. I can do
git grep '\<some_variable\>' arch/i386 include/asm-i386
and it does exactly what you'd think it does. And since it just uses the
normal git-ls-files file patterns, you can do things like
git grep something 'include/*.h'
and it will search all header files under the include/ subdirectory.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I really wanted to try this out, instead of asking for an adjustment
to the 'git merge' driver and waiting. For now the new strategy is
called 'fredrik' and not in the list of default strategies to be tried.
The script wants Python 2.4 so this commit also adjusts Debian and RPM
build procecure files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new command 'git merge' takes the current head and one or more
remote heads, with the commit log message for the automated case.
If the heads being merged are simple fast-forwards, it acts the
same way as the current 'git resolve'. Otherwise, it tries
different merge strategies and takes the result from the one that
succeeded auto-merging, if there is any.
If no merge strategy succeeds auto-merging, their results are
evaluated for number of paths needed for hand resolving, and the
one with the least number of such paths is left in the working
tree. The user is asked to resolve them by hand and make a
commit manually.
The calling convention from the 'git merge' driver to merge
strategy programs is very simple:
- A strategy program is to be called 'git-merge-<strategy>'.
- They take input of this form:
<common1> <common2> ... '--' <head> <remote1> <remote2>...
That is, one or more the common ancestors, double dash, the
current head, and one or more remote heads being merged into
the current branch.
- Before a strategy program is called, the working tree is
matched to the current <head>.
- The strategy program exits with status code 0 when it
successfully auto-merges the given heads. It should do
update-cache for all the merged paths when it does so -- the
index file will be used to record the merge result as a
commit by the driver.
- The strategy program exits with status code 1 when it leaves
conflicts behind. It should do update-cache for all the
merged paths that it successfully auto-merged, and leave the
cache entry in the index file as the same as <head> for paths
it could not auto-merge, and leave its best-effort result
with conflict markers in the working tree when it does so.
- The strategy program exists with status code other than 0 or
1 if it does not handle the given merge at all.
As examples, this commit comes with merge strategies based on
'git resolve' and 'git octopus'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have deprecated the old environment variable names for quite a
while and now it's time to remove them. Gone are:
SHA1_FILE_DIRECTORIES AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME
COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove duplicate git-send-email-perl target in Makefile.
When WITH_SEND_EMAIL was defined, as in the Debian 'deb' target,
git-send-email-perl was added twice to SCRIPT_PERL, leading to a
duplicate definition in the Makefile. Creating a ".deb" then failed.
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we renamed git-foo.sh to git-foo while installing, which
was mostly done by inertia than anything else. This however
made writing tests to use scripts harder.
This patch builds the scripts the same way as we build binaries
from their sources. As a side effect, you can now specify
non-standard paths you have your Perl binary is in when running
the make.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* getdomainname unavailable there.
* needs -lsocket for linkage.
* needs __EXTENSIONS__ at the beginning of convert-objects.c
[JC: I've done this slightly differently from what Patrick originally
sent to the list and dropped the bit that deals with installations
that has curl header and library at non-default location. I am
resisting the slipperly slope called autoconf.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
As promised, this is the "big tool rename" patch. The primary differences
since 0.99.6 are:
(1) git-*-script are no more. The commands installed do not
have any such suffix so users do not have to remember if
something is implemented as a shell script or not.
(2) Many command names with 'cache' in them are renamed with
'index' if that is what they mean.
There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support is expected to be removed in the near
future.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also make platform specific part more isolated. Currently we only
have Darwin defined, but I've taken a look at SunOS specific patch
(which I dropped on the floor for now) as well. Doing things this way
would make adding it easier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now the rebase is rewritten to use git cherry-pick, there is no user
for that ancient script. I've checked Cogito and StGIT to make sure
they do not use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reverse patch application using "git apply" sometimes is too
rigid. Since the user would get used to resolving conflicting merges
by hand during the normal merge experience, using the same machinery
would be more helpful rather than just giving up.
Cherry-picking and reverting are essentially the same operation.
You pick one commit, and apply the difference that commit introduces
to its own commit ancestry chain to the current tree. Revert applies
the diff in reverse while cherry-pick applies it forward. They share
the same logic, just different messages and merge direction.
Rewrite "git rebase" using "git cherry-pick".
Signed-off-by: Junio C Hamano <junkio@cox.net>
You can define WITH_SEND_EMAIL to include the send-email command as
part of the installation. Since Debian, unlike RPM/Fedora, has the
two necessary Perl modules available as part of the mainline
distribution, there is no reason for us to shy away from shipping
send-email.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script uses the list of heads and their origin multi-head "git
fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
merge on top of the current HEAD using them.
The implementation tries to be strict for the sake of safety. It
insists that your working tree is clean (no local changes) and matches
the HEAD, and when any of the merged heads does not automerge, the
whole process is aborted and tries to rewind your working tree is to
the original state.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update git-pull to match updated git-fetch and allow pull to
fetch from multiple remote references. There is no support for
resolving more than two heads, which will be done with "git
octopus".
Update "git ls-remote" to use git-parse-remote-script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When showing only one branch a lot of default output becomes redundant,
so clean it up a bit, and document what is shown. Retire the earlier
implementation "git-show-branches-script".
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'git show-branches' command turns out to be reasonably useful,
but painfully slow. So rewrite it in C, using ideas from merge-base
while enhancing it a bit more.
- Unlike show-branches, it can take --heads (show me all my
heads), --tags (show me all my tags), or --all (both).
- It can take --more=<number> to show beyond the merge-base.
- It shows the short name for each commit in the extended SHA1
syntax.
- It can find merge-base for more than two heads.
Examples:
$ git show-branch --more=6 HEAD
is almost the same as "git log --pretty=oneline --max-count=6".
$ git show-branch --merge-base master mhf misc
finds the merge base of the three given heads.
$ git show-branch master mhf misc
shows logs from the top of these three branch heads, up to their
common ancestor commit is shown.
$ git show-branch --all --more=10
is poor-man's gitk, showing all the tags and heads, and
going back 10 commits beyond the merge base of those refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We always show the diff as an absolute path, but pathnames to diff are
taken relative to the current working directory (and if no pathnames are
given, the default ends up being all of the current working directory).
Note that "../xyz" also works, so you can do
cd linux/drivers/char
git diff ../block
and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Often I find myself wanting to do quick branches check when I am
not in the windowing environment and cannot run gitk.
This stupid script shows commits leading to the heads of
interesting branches with indication which ones belong to which
branches, so that fork point is somewhat discernible without
using gitk.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tools directory being separate is just a historical
coincidence. Build and install together with the main
directory, just like the clean target does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use <tab> instead of two spaces uniformly in the Makefile, even in the
ifdefs. Gives it a nice consistent look.
[jc: At the same time I indented the nested ifdefs to make them
slightly easier to read.]
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$DESTDIR is more usual during the build than $dest and is what
is usually used in the makefiles, so let's use it too.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch renames COPTS to CFLAGS, because it's COPTS that was user
overridable. Also, -Wall is moved there because it's optional. What
was CFLAGS is now ALL_CFLAGS, which users should not override.
Defines are added to DEFINES. Since ALL_CFLAGS is recursively expanded,
it uses the final value of DEFINES.
Implicit rules are made explicit since the implicit rules use CFLAGS
rather than ALL_CFLAGS. I believe that serious projects should not rely
on implicit rules anyway. Percent rules are used because they are used
already and because they don't need the .SUFFIXES target.
[jc: in addition to updating the patch for 0.99.4, I fixed up a
glitch in Pavel's original patch which compiled sha1.o out of
mozilla-sha1/sha1.c, where it should have left the resulting
object file in mozilla-sha1 directory for later "ar".]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given one existing commit, revert the change the patch
introduces, and record a new commit that records it. This
requires your working tree to be clean (no modifications from
the HEAD commit).
This is based on what Linus posted to the list, with
enhancements he suggested, including the use of -M to attempt
reverting renames.
Signed-off-by: Junio C Hamano <junkio@cox.net>
RPM folks have problem installing the package otherwise. Since
its usefulness does have much to do with GIT, downgrade it to
"contrib" status for now. We may want to move it to contrib/
subdirectory after auditing other programs when we reorganize
the source tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Run install-tools target to install the tools to accept e-mail
patches. Also clean up the main Makefile a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is my first attempt to adjust Debian and RPM to pass
prefix, to prepare the 0.99.4 release.
It updates debian/rules and git-core.spec.in to properly pass
prefix when building binary packages. It also updates
debian/changelog to make the resulting binary package name
0.99.4; this is not needed on the RPM side (it takes the version
number from the main Makefile).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Per discussion with people interested in binary packaging,
change the default template location from /etc/git-core to
/usr/share/git-core hierarchy. If a user wants to run git
before installing for whatever reason, in addition to adding
$src to the PATH environment variable, git-init-db can be run
with --template=$src/templates/blt/ parameter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody envies rev-parse, who is the only one that can grok
the extended sha1 format. Move the get_extended_sha1() out of
rev-parse, rename it to get_sha1() and make it available to
everybody else.
The one I posted earlier to the list had one bug where it did
not handle a name that ends with a digit correctly (it
incorrectly tried the "Nth parent" path). This commit fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The king penguin said:
It has no point any more, all the tools check the file
status on their own, and yes, the thing should probably be
removed.
and the faithful servant makes it so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A template mechanism to populate newly initialized repository
with default set of files is introduced. Use it to ship example
hooks that can be used for update and post update checks, as
Josef Weidendorfer suggests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
all the nice things a good subsystem maintainer does when forwarding a patch or
50 upstream:
All the prior handlers of the patch, as determined by the
Signed-off-by: lines, and/or the author of the commit, are cc:ed on the
email.
All emails are sent as a reply to the previous email, making it easy to
skip a collection of emails that are uninteresting.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Things have slowly but surely started to settle down, and the
http transport finally can natively grok packed repositories.
To give Pasky a good anchor point, hoping that he can start
split off the core part from Cogito, here is the 0.99.3, which
will be accompanied with its own tag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just before updating a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha1
is called if executable. The hook can decline the ref to be
updated by exiting with a non-zero status, or allow it to be
updated by exiting with a zero status. The mechanism also
allows e.g sending of a mail with pushed commits on the remote
repository.
Documentation update with an example hook is included.
jc: The credits of the basic idea and initial implementation go
to Josef, but I ended up rewriting major parts of his patch, so
bugs are all mine. Also I changed the semantics for the hook
from his original version (which were post-update hook) so that
the hook can optionally decline to update the ref, and also can
be used to implement the overall cleanups. The latter was
primarily to implement a suggestion from Linus that calling
update-server-info should be made optional.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This counts the number of unpacked object files and disk space
consumed by them, to help you decide when it is a good time to
repack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Implement fetching from a packed repository over http/https
using the dumb server support files.
I consider some parts of the logic should be in a separate C
program, but it appears to work with my simple tests. I have
backburnered it for a bit too long for my liking, so let's throw
it out in the open and see what happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch implements Linus' idea that if you are not interested in
pulling by HTTP, you can now say
NO_CURL=1 make
to compile everything except git-http-pull (thus not needing curl at all).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a new "git bisect" command.
- "git bisect start"
start bisection search.
- "git bisect bad <rev>"
mark some version known-bad (if no arguments, then current HEAD)
- "git bisect good <revs>..."
mark some versions known-good (if no arguments, then current HEAD)
- "git bisect reset <branch>"
done with bisection search and go back to your work (if
no arguments, then "master").
The way you use it is:
git bisect start
git bisect bad # Current version is bad
git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
# tested that was good
When you give at least one bad and one good versions, it will
bisect the revision tree and say something like:
Bisecting: 675 revisions left to test after this
and check out the state in the middle. Now, compile that kernel, and boot
it. Now, let's say that this booted kernel works fine, then just do
git bisect good # this one is good
which will now say
Bisecting: 337 revisions left to test after this
and you continue along, compiling that one, testing it, and depending on
whether it is good or bad, you say "git bisect good" or "git bisect bad",
and ask for the next bisection.
Until you have no more left, and you'll have been left with the first bad
kernel rev in "refs/bisect/bad".
Oh, and then after you want to reset to the original head, do a
git bisect reset
to get back to the master branch, instead of being in one of the bisection
branches ("git bisect start" will do that for you too, actually: it will
reset the bisection state, and before it does that it checks that you're
not using some old bisection branch).
Not really any harder than doing series of "quilt push" and "quilt pop",
now is it?
[jc: This patch is a rework based on what Linus posted to the
list. The changes are:
- The original introduced four separate commands, which was
three too many, so I merged them into one with subcommands.
- Since the next thing you would want to do after telling it
"bad" and "good" is always to bisect, this version does it
automatically for you.
- I think the termination condition was wrong. The original
version checked if the set of revisions reachable from next
bisection but not rechable from any of the known good ones
is empty, but if the current bisection was a bad one, this
would not terminate, so I changed it to terminate it when
the set becomes a singleton or empty.
- Removed the use of shell array variable.
]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Separate the process of building the commands to compilation and
linkage. This makes it more consistent with the library objects, is the
traditional thing to do, and significantly speeds up the subsequent
rebuilds, especially for us the people who develop git on 300MHz
notebooks.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Support for completely OpenSSL-less builds. FSF considers distributing GPL
binaries with OpenSSL linked in as a legal problem so this is trouble
e.g. for Debian, or some people might not want to install OpenSSL
anyway. If you
make NO_OPENSSL=1
you get completely OpenSSL-less build, disabling --merge-order and using
Mozilla's SHA1 implementation.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The Makefile rules were massively reordered so that they are actually
logically grouped now. Captions were added to separate the sections. No
rule contents was touched during the process.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove about one gazillion of explicit dependency rules with few lines
describing the general dependency pattern and then the exceptions. This
noticably shortens the Makefile and makes it easier to touch it.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Describe variables which make itself takes and adjusts compilation
accordingly (MOZILLA_SHA1, NO_OPENSSL, PPC_SHA1), and make adding
defines more convenient through the $DEFINES variable. $COPTS includes
-g as well now and is not overriden if it was already declared in the
environment. Also, $CFLAGS is appended to rather than reset, so that if
there was already a $CFLAGS environment variable, it's appended to. Some
more variables are also made overridable through the environment. Renamed
$bin to $bindir which is the name commonly used for this.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On older Mac OS X (10.2.8), no socklen_t is defined, and therefore
daemon.c does not compile. However, Mac OS X 10.4 seems to define
socklen_t differently.
Also, linking fails due to some symbols defined in libssl (not just
libcrypto).
[jc: I am tentatively dropping the socklen_t part of the patch
because I am waiting for confirmation on the server side IPV6
patch from Yoshifuji-san]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A short message requesting a pull from the repository is also included.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It's stupid. We'd want to rename directories too, but this doesn't do
that yet - easy enough to do per se, we just need to carefully list all
the pathnames that got moved (and remember to ignore the files that
weren't tracked but are in the subdirectory that got moved).
Doing the directory case will require a bit more scripting.. Something like
oldfiles=($(git-ls-files | grep '^$src'))
newfiles=($(git-ls-files | sed ':^$src: s:^$src:$dst:'))
mv $src $dst && git-update-cache --add --remove -- "${oldfiles[@]}" "${newfiles[@]}"
might do it, except it needs to be done right, and carefully. Methinks
perl is probably better at this. Hint hint..
Using the information prepared with update-server-info, a truly
dumb http server can allow cloning with this client side
support.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The git-update-server-info command prepares informational files
to help clients discover the contents of a repository, and pull
from it via a dumb transport protocols. Currently, the
following files are produced.
- The $repo/info/refs file lists the name of heads and tags
available in the $repo/refs/ directory, along with their
SHA1. This can be used by git-ls-remote command running on
the client side.
- The $repo/info/rev-cache file describes the commit ancestry
reachable from references in the $repo/refs/ directory. This
file is in an append-only binary format to make the server
side friendly to rsync mirroring scheme, and can be read by
git-show-rev-cache command.
- The $repo/objects/info/pack file lists the name of the packs
available, the interdependencies among them, and the head
commits and tags contained in them. Along with the other two
files, this is designed to help clients to make smart pull
decisions.
The git-receive-pack command is changed to invoke it at the end,
so just after a push to a public repository finishes via "git
push", the server info is automatically updated.
In addition, building of the rev-cache file can be done by a
standalone git-build-rev-cache command separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Retrieve and list the remote refs from git, http, and rsync
repositories, and optionally stores the retrieved refs in the
local repository under the same name.
To access a git URL, git-peek-remote command is used. An http
URL needs to have an up-to-date info/refs file for discovery,
which will be introduced by a later update-server-info patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add a git-peek-remote command that talks with upload-pack the
same way git-fetch-pack and git-clone-pack do, to show the
references the remote side has on the standard output.
A later patch introduces git-ls-remote that implements a UI to
store tag values retrieved using this command.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
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.
