Even though --all and --tags can be used to include non
annotated tags in the reference point candidates, prefer to use
annotated tags if there are more than one refs that name the
same commit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With --tags, not just annontated tags, but also any ref under
refs/tags/ are used to name the revision.

The number of digits is configurable with the --abbrev=<n> option.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Just in case 8 hexadecimal digits are not enough.  We could use
shorter default if we wanted to.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Often there are references other than annotated tags under
refs/tags hierarchy that are used to "keep things just in case".
default to use annotated tags only, still leaving the option to
use any ref with --all flag.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It shows you the most recent tag that is reachable from a particular
commit is.

Maybe this is something that "git-name-rev" should be taught to do,
instead of having a separate command for it. Regardless, I find it useful.

What it does is to take any random commit, and "name" it by looking up the
most recent commit that is tagged and reachable from that commit. If the
match is exact, it will just print out that ref-name directly. Otherwise
it will print out the ref-name, followed by the 8-character "short SHA".

IOW, with something like Junios current tree, I get:

	[torvalds@g5 git]$ git-describe parent
	refs/tags/v1.0.4-g2414721b

ie the current head of my "parent" branch (ie Junio) is based on v1.0.4,
but since it has a few commits on top of that, it has added the git hash
of the thing to the end: "-g" + 8-char shorthand for the commit
2414721b.

Doing a "git-describe" on a tag-name will just show the full tag path:

	[torvalds@g5 git]$ git-describe v1.0.4
	refs/tags/v1.0.4

unless there are _other_ tags pointing to that commit, in which case it
will just choose one at random.

This is useful for two things:

 - automatic version naming in Makefiles, for example. We could use it in
   git itself: when doing "git --version", we could use this to give a
   much more useful description of exactly what version was installed.

 - for any random commit (say, you use "gitk <pathname>" or
   "git-whatchanged" to look at what has changed in some file), you can
   figure out what the last version of the repo was. Ie, say I find a bug
   in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do:

	[torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6
	refs/tags/v2.6.14-rc4-g39ca371c

   and I now know that it was _not_ in v2.6.14-rc4, but was presumably in
   v2.6.14-rc5.

The latter is useful when you want to see what "version timeframe" a
commit happened in.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Minor fixes.

Starting from this one I won't be touching debian/ directory
since the official maintainer seems to be reasonably quick to
package up things.  The packaging procedure used there seems to
be quite different from what I have, so I'd like to avoid
potential confusion and reduce work by the official maintainer
and myself.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch converts a stat() to an lstat() call, thereby fixing the case
when the date of a symlink was not the same as the one recorded in the
index. The included test case demonstrates this.

This is for the case that the symlink points to a non-existing file. If
the file exists, worse things than just an error message happen.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Johannes found that the test has 1/256 chance of falsely
producing an uncorrupted idx file, causing the check to detect
corruption fail.  Now we have 1/2^160 chance of false failure
;-).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Avoid asking for zero bytes when that change simplifies overall
logic.  Later we would change the wrapper to ask for 1 byte on
platforms that return NULL for zero byte request.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

dietlibc versions of malloc, calloc and realloc all return NULL if
they're told to allocate 0 bytes, causes the x* wrappers to die().

There are several more places where these calls could end up asking
for 0 bytes, too...

Maybe simply not die()-ing in the x* wrappers if 0/NULL is returned
when the requested size is zero is a safer and easier way to go.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Now you can say

	git-init-db --shared

if you want other users to be able to push into that repository.

[jc: info/ and objects/info/ need to be group writable if the
 repository is shared --- otherwise packs and refs files cannot
 be updated.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If the config variable 'core.sharedrepository' is set, the directories

	$GIT_DIR/objects/
	$GIT_DIR/objects/??
	$GIT_DIR/objects/pack
	$GIT_DIR/refs
	$GIT_DIR/refs/heads
	$GIT_DIR/refs/heads/tags

are set group writable (and g+s, since the git group may be not the primary
group of all users).

Since all files are written as lock files first, and then moved to
their destination, they do not have to be group writable.  Indeed, if
this leads to problems you found a bug.

Note that -- as in my first attempt -- the config variable is set in the
function which checks the repository format. If this were done in
git_default_config instead, a lot of programs would need to be modified
to call git_config(git_default_config) first.

[jc: git variables should be in environment.c unless there is a
 compelling reason to do otherwise.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

This was a stupid typo that did not follow

	http://www.iana.org/assignments/character-sets

Long noticed but neglected by JC, but finally reported by
Marco.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Somehow this option was not mentioned anywhere in the
documentation nor the usage string.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We did not distinguish the case the user asked not to make a
commit with --no-commit flag and the automerge failed.  Tell
these cases apart and phrase dying message differently.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Underlying http-fetch is supposed to be capable of handling
packed repositories just fine, so no need to special case it in
the wrapper script.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This does three things:

 . It simplifies the logic to handle the case in which no
   refs are given on the command line, and fixes the bug
   when only "--heads" is specified.  Earlier we showed
   them twice.

 . It avoids to add the same ref twice.

 . It sorts the glob result (e.g. "git show-branch
   'tags/v1.0*'") according to a more version friendly
   sort order.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Although pack-check.c had routine to verify the checksum for the
pack index file itself, the core did not check it before using
it.

This is stolen from the patch to tighten packname requirements.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
(cherry picked from 797bd6f4 commit)

A proposed change to show cwd relative paths by default from
ls-tree when run from a subdirectory means we would need to
give --full-name option to it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When run from a subdirectory, even though we filtered the output
based on where we were using pathspec, we wrote out the
repository relative paths, not subtree relative paths.  This
changes things so that it shows only the current subdirectory
relative paths.

For example, in Documentation subdirectory of git itself, this
used to be the case:

    $ git-ls-tree --name-only HEAD | grep how
    Documentation/git-show-branch.txt
    Documentation/git-show-index.txt
    Documentation/howto-index.sh
    Documentation/howto

But now it does this instead:

    $ git-ls-tree --name-only HEAD | grep how
    git-show-branch.txt
    git-show-index.txt
    howto-index.sh
    howto

There are two things to keep in mind.

1. This shows nothing.

   $ git-ls-tree --name-only HEAD ../ppc/

   This is to make things consistent with ls-files, which
   refuses relative path that goes uplevel.

2. These show things in full repository relative paths.  In this
   case, paths outside the current subdirectory are also shown.

   $ git-ls-tree --name-only --full-name HEAD | grep how
   Documentation/git-show-branch.txt
   Documentation/git-show-index.txt
   Documentation/howto-index.sh
   Documentation/howto

   $ git-ls-tree --name-only --full-name HEAD ../ppc/
   ppc/sha1.c
   ppc/sha1.h
   ppc/sha1ppc.S

The flag --full-name gives the same behaviour as 1.0, so it
ought to be the default if we really care about the backward
compatibility, but in practice no Porcelain runs ls-tree from a
subdirectory yet, and without --full-name is more human
friendly, so hopefully the default being not --full-name would
be acceptable.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-checkout does two very different things, and what they
should do when run from subdirectory are quite different.

It does not make any sense to run the one that switches the
current head from anywhere other than the toplevel:

	git-checkout [-f] <branch>
        git-checkout [-b <branch>] <committish>

We could of course chdir to top and do the whole-tree checkout
in git-checkout, but the point is the operation does not make
sense on a partial tree.  The whole tree is checked out.

The other form is to update the index file and working tree file
selectively:

	git-checkout <treeish> <file>... ;# out of tree to index and file
        git-checkout -- <file>...	 ;# out of index to file

This form _does_ make sense to run from subdirectory; and I
myself often wish we supported this.

So here is a patch to do both.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Although pack-check.c had routine to verify the checksum for the
pack index file itself, the core did not check it before using
it.

This is stolen from the patch to tighten packname requirements.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When --show-prefix is useful, sometimes it is easier to cd up to
the toplevel of the tree.  This is equivalent to:

    git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g'

but we do not have to invoke sed for that.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

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

Earlier, git-clone stored upstream's master in the branch named 'origin',
possibly overwriting an existing such branch.

Now you can change it by calling git-clone with '-o <other_name>'.

[jc: added ref format check, subdirectory safety, documentation
 and usage string.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

sha1_to_hex() returns a pointer to a static buffer. Some of its users
modify that buffer by appending a newline character. Other users rely
on the fact that you can call

	printf("%s", sha1_to_hex(sha1));

Just to be on the safe side, terminate the SHA1 in sha1_to_hex().
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Recognize missing files when using http-fetch with file:// URLs
Signed-off-by: NNick Hengeveld <nickh@reactrix.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We want to record the version of the tools the patch was generated with.
While these tools could be rebuilt, git-format-patch stayed the same and
report the wrong version.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Wnen refusing to push a head, we said cryptic "remote 'branch'
object X does not exist on local" or "remote ref 'branch' is not
a strict subset of local ref 'branch'".  That was gittish.

Since the most likely reason this happens is because the pushed
head was not up-to-date, clarify the error message to say that
straight, and suggest pulling first.

First noticed by Johannes and seconded by Andreas.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Allow IPv6address/IPvFuture enclosed by [] in URLs, like:
   git push '[3ffe:ffff:...:1]:GIT/git'
or
   git push 'ssh://[3ffe:ffff:...:1]/GIT/git'
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This allows the configuration item whatchanged.difftree to
control the output from git-whatchanged command.  For example:

	[whatchanged]
        	difftree = --pretty=fuller --name-status -M

does rename detection, shows the commit header in "fuller"
format and lists affected pathnames and the kind of changes to
them.

When no such configuration item exists, the output format
defaults to "--pretty -M --abbrev".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

fprintf and die sometimes have missing/excessive "\n" in their arguments,
correct the strings where I think it would be appropriate.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Slab allocation of llist entries gives some speed improvements.

Not computing the pack_list permutaions all at once reduces memory
usage greatly on repositories with many packs.
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>