The *_usage strings should not start with "usage: ", since the
usage() function gives its own.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When no usable head/tag is specified, git log barfed with
underlying error message from rev-list, which was not helpful.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

 - use --verify to make sure rev param is a rev, and barf otherwise.
 - make it always output to stdout; no funny business with tee.
 - take optional branch head name to specify which branch to summarize.
 - show baserev in a human readable way.
 - do not depend on diffstat; use git-apply --stat instead.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A short message requesting a pull from the repository is also included.
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-status-script was missed during the conversion from "N" to "A" as
the new-file marker flag.
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch includes two fixes to the git-core Debian package:

    * Conflict with the GNU Interactive Tools package, which _also_
      wants to install /usr/bin/git.

    * Compile against the unencumbered Mozilla SHA1 code, instead of
      the iffy OpenSSL code, as much as possible.  This makes it easier to get
      the package included for distribution with Debian.

This has been based upon the original patch by Sebastian Kuzminsky
<seb@highlab.com>, but has been fixed up based upon feedback.
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The check that the source is ahead of the destination incorrectly expects 
pop_most_recent_commit() to gracefully handle an empty list. 

Fix by just checking the list itself, rather than the return value of the 
pop function.

[jc: I did the test script that demonstrated the problem]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

We use 'A' for added files instead of 'N' to make the it
visually easier to distinguish from 'M' now.

While we are at it, make the test scripts executable.  Yes, I
know it does not matter because t/Makefile runs them explicitly
with "sh tXXXX-blah.sh", but being consistent is always better.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This actually changes the diff-raw status letter from N to A
for added files.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Both Cogito and StGIT prefer to see 'A' for new files.  The
current 'N' is visually harder to distinguish from 'M', which is
used for modified files.  Prepare the internals to use symbolic
constants to make the change easier.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Add --exclude-per-directory=<name> option that specifies a file
to contain exclude patterns local to that directory and its
subdirectories.  Update the exclusion logic to be able to say
"include files that match this more specific pattern, even
though later exclude patterns may match them".  Also enhances
that a pattern can contain '/' in which case fnmatch is called
with FNM_PATHNAME flag to match the entire path. 
Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: I updated Ryan's patch to mention -a to create an unsigned
tag.]
Signed-off-by: NRyan Anderson <ryan@michonline.com>

This adds -a (annotate only but not sign) option "A Large Angry
SCM" <gitzilla@gmail.com> sent to the list, after fixing up the
whitespace corruption in the patch, with some of my own fixes.
Namely:

 * A new flag '-a' can be used to create an unsigned tag
   object;

 * The '-f' flag logic did not do the right thing;

 * When creating a signed tag, we did not check for GPG failure
   as we should;

 * Try to use the key for the tagger identity when signing the
   tag.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Ehh, it works much better that way ;)

Instead of finding old/new pair that one side has and the
other side does not have the specified string, find old/new pair
that contains the specified string as a substring different
number of times.  This would still not catch a case where you
introduce two static variable declarations and remove two static
function definitions from a file with -S"static", but would make
it behave a bit more intuitively.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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..

Hey, people are using them, and we have an install target for them, so
make sure that we can actually install them sanely without disturbing
the namespace.

Using the information prepared with update-server-info, a truly
dumb http server can allow cloning with this client side
support.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This adds a minimum documentation to the new command.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus 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: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus 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: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add documentation for the git-peek-remote and link it from the
main index.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus 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: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Teach people to use "git tag <tag-name>" instead of writing the current
HEAD by hand into the .git/refs/tags/<tag-name> file.  Most people
probably don't really want to know about how git does things internally.

A simple tag is just a direct pointer to the object, while a signed tag
is a pointer to a "tag object" that has a pgp signature and points to
the object we tagged.

Use "git tag -s tagname" to create a signed tag.

The "-f" flag overwrites any previous tag of that name (useful if you
update a tag to point to a newer version for things like "latest" etc
tags that aren't necessarily static versions).

Some people split their long E-mail address over two lines
using the RFC2822 header "folding".  We can lose authorship
information this way, so make a minimum effort to deal with it,
instead of special casing only the "Subject:" field.

We could teach mailsplit to unfold the folded header, but
teaching mailinfo about folding would make more sense; a single
message can be fed to mailinfo without going through mailsplit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It was broken by the IPv6 patches - we need to remove the ":" part from
the hostname for a successful name lookup.

Try all addresses for given remote name until it succeeds.  Also
supports IPv6.
Signed-off-by: NHideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The deb package building needs these two new files to work correctly.

debian/compat sets the rules under which the debhelper scripts (dh_*)
operate.

debian/git-core.install tells dh_install what files to install in each
package that is generated.  There is only one package being generated,
so all files go into it.

(I missed these in the last patch, mostly because I needed to do this to
find stuff I had missed:
	find . -name .git -type d -prune -o -type f -print \
		| grep -v -e .tree1 -e .tree2 \
		| sed -e "s/^\.\///" \
		| sort >.tree1
	git-ls-files | grep -v -e .tree1 -e .tree2 \
		| sort >.tree2
	diff -u .tree1 .tree2
)
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The Deb packages were missing a dependency on "build install" from the
binary target - this fixes that, and cleans up some inconsistencies
elsewhere in the rulesets.

Traditionally, Debian packaging uses a file called "build-stamp" (or
"install-stamp", etc) in the main source tree.  The initial deb package
support for Git tried to move this "build-stamp" file into the debian/
directory, but some instances were missed.  That problem, however, was
incidental - the real fix is the missing dependency mentioned above.
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We'll mark all the trees at the edges (as deep as we had to go to
realize that we have all the commits needed) as uninteresting.
Otherwise we'll occasionally list a lot of objects that were actually
available at the edge in a commit that we just never ended up parsing
because we could determine early that we had all relevant commits.

NOTE! The object listing is still just a _heuristic_.  It's guaranteed
to list a superset of the actual new objects, but there might be the
occasional old object in the list, just because the commit that
referenced it was much further back in the history.

For example, let's say that a recent commit is a revert of part of the
tree to much older state: since we didn't walk _that_ far back in the
commit history tree to list the commits necessary, git-rev-tree will
never have marked the old objects uninteresting, and we'll end up
listing them as "new".

That's ok.

Update the recommended workflow for individual developers.
While they are tracking the origin, refs/heads/origin is updated
by "git fetch", so there is no need to manually copy FETCH_HEAD
to refs/heads/ anywhere.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A bit more usability enhancement, while retaining Cogito
compatibility (and fixing the "-u" flag).
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The output from a failure case had the test description message
and the first line of the actual test script concatenated on the
same line, which was ugly.  Correct the output routine a bit to
make it more readable.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch changes rev-parse users that pass a single argument
that is supposed to be a rev parameter to use "--verify".
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When not specifying the start point explicitly, we ended up
emitting ^0 in addition to the default HEAD.  Be careful to see
if we have "$2" before finding out which commit to base the new
branch on.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The git-rev-parse command uses LF to separate each argument it
parses, so its users at least need to set IFS to LF to be able
to handle filenames with embedded SPs and TABs.  Some commands,
however, can take and do expect arguments with embedded LF,
notably, "-S" (pickaxe) of diff family, so even this workaround
does not work for them.

When --sq flag to git-rev-parse is given, instead of showing one
argument per line, it outputs arguments quoted for consumption
with "eval" by the caller, to remedy this situation.

As an example, this patch converts git-whatchanged to use this
new feature.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>