When doing something like

	git fetch --tags origin

the excessively verbose output of git fetch makes the result totally
unreadable. It's impossible to tell if it actually fetched anything new or
not, since the screen will fill up with an endless supply of

   ...
   * committish: 9165ec17fde255a1770886189359897dbb541012
     tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git
   * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git
   ...

and any new tags that got fetched will be totally hidden.

So add a new "--verbose" flag to "git fetch" to enable this verbose mode,
but make the default be quiet.

NOTE! The quiet mode will still report about new or changed heads, so if
you are really fetching a new head, you'll see something like this:

   [torvalds@g5 git]$ git fetch --tags parent
   Packing 6 objects
   Unpacking 6 objects
    100% (6/6) done
   * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git
   * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git
   * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git

which actually tells you something useful that isn't hidden by all the
useless crud that you already had.

Extensively tested (hey, for me, this _is_ extensive) by doing a

   rm .git/refs/tags/v1.0rc*

and re-fetching with both --verbose and without.

NOTE! This means that if the fetch didn't actually fetch anything at all,
git fetch will be totally quiet. I think that's much better than being so
verbose that you can't even tell whether something was fetched or not, but
some people might prefer to get a "nothing to fetch" message in that case.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I forgot to initialize part of the pll struct when copying it.
Found by valgrind.
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Now git-apply can grok binary replacement patches, give --binary
flag to git-am.  As a safety measure, this is not by default
enabled, so that you do not let malicious e-mailed patch to
replace an arbitrary path with just a couple of lines (diff
index lines, the filename and string "Binary files "...) by
accident.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This allows people to use syntax like "last thursday" for the approxidate.

(Or, indeed, more complex "three thursdays ago", but I suspect that would
be pretty unusual).

NOTE! The parsing is strictly sequential, so if you do

	"one day before last thursday"

it will _not_ do what you think it does. It will take the current time,
subtract one day, and then go back to the thursday before that. So to get
what you want, you'd have to write it the other way around:

	"last thursday and one day before"

which is insane (it's usually the same as "last wednesday" _except_ if
today is Thursday, in which case "last wednesday" is yesterday, and "last
thursday and one day before" is eight days ago).

Similarly,

	"last thursday one month ago"

will first go back to last thursday, and then go back one month from
there, not the other way around.

I doubt anybody would ever use insane dates like that, but I thought I'd
point out that the approxidate parsing is not exactly "standard English".

Side note 2: if you want to avoid spaces (because of quoting issues), you
can use any non-alphanumberic character instead. So

	git log --since=2.days.ago

works without any quotes.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Change the smallest-set detection algortithm so that when
we have found a good set, we don't check any larger sets.
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Three times remove_redandant -> remove_redundant.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Some vintage of diff says just "Files X and Y differ\n", instead
of "Binary files X and Y differ\n", so catch both patterns.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch adds the -o switch, which lets old trees tracked by
git-archmirror continue working with their old branch and tag names
to make life easier for people tracking your tree.

Private tags that are only used internally by git-archimport continue to be
new-style, and automatically converted upon first run.

[ ml: rebased to skip import overhaul ]
Signed-off-by: N: Eric Wong <normalperson@yhbt.net>
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>

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

Ok. This is the insane patch to do this.

It really isn't very careful, and the reason I call it "approxidate()"
will become obvious when you look at the code. It is very liberal in what
it accepts, to the point where sometimes the results may not make a whole
lot of sense.

It accepts "last week" as a date string, by virtue of "last" parsing as
the number 1, and it totally ignoring superfluous fluff like "ago", so
"last week" ends up being exactly the same thing as "1 week ago". Fine so
far.

It has strange side effects: "last december" will actually parse as "Dec
1", which actually _does_ turn out right, because it will then notice that
it's not December yet, so it will decide that you must be talking about a
date last year. So it actually gets it right, but it's kind of for the
"wrong" reasons.

It also accepts the numbers 1..10 in string format ("one" .. "ten"), so
you can do "ten weeks ago" or "ten hours ago" and it will do the right
thing.

But it will do some really strange thigns too: the string "this will last
forever", will not recognize anyting but "last", which is recognized as
"1", which since it doesn't understand anything else it will think is the
day of the month. So if you do

	gitk --since="this will last forever"

the date will actually parse as the first day of the current month.

And it will parse the string "now" as "now", but only because it doesn't
understand it at all, and it makes everything relative to "now".

Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks
ago" is exactly the same as "2 weeks from now". It's the current date
minus 14 days.

But hey, it's probably better (and certainly faster) than depending on GNU
date. So now you can portably do things like

	gitk --since="two weeks and three days ago"
	git log --since="July 5"
	git-whatchanged --since="10 hours ago"
	git log --since="last october"

and it will actually do exactly what you thought it would do (I think). It
will count 17 days backwards, and it will do so even if you don't have GNU
date installed.

(I don't do "last monday" or similar yet, but I can extend it to that too
if people want).

It was kind of fun trying to write code that uses such totally relaxed
"understanding" of dates yet tries to get it right for the trivial cases.
The result should be mixed with a few strange preprocessor tricks, and be
submitted for the IOCCC ;)

Feel free to try it out, and see how many strange dates it gets right. Or
wrong.

And if you find some interesting (and valid - not "interesting" as in
"strange", but "interesting" as in "I'd be interested in actually doing
this) thing it gets wrong - usually by not understanding it and silently
just doing some strange things - please holler.

Now, as usual this certainly hasn't been getting a lot of testing. But my
code always works, no?

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

Disambiguate the term 'branch' in Arch vs git,
and start using fully-qualified names.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>

Don't die if we can't find a merge base, Arch allows arbitrary
cherry-picks between unrelated branches and we should not
die when that happens
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>

use ',' to encode '/' in "archivename/foo--bar--0.0" so we can allow
"--branch"-less trees which are valid in Arch ("archivename/foo--0.0")
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>

Allow --init-timeout and --timeout to be specified without falling
through to usage().

Make sure openlog() is called even if implied by --inetd, or messages
will be sent to wherever LOG_USER ends up.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds more tests to cover cases where binary diff
application succeeds.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A new option, --full-index, is introduced to diff family.  This
causes the full object name of pre- and post-images to appear on
the index line of patch formatted output, to be used in
conjunction with --allow-binary-replacement option of git-apply.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A new option, --allow-binary-replacement, is introduced.

When you feed a diff that records full SHA1 name of pre- and
post-image blob on its index line to git-apply with this option,
the post-image blob replaces the path if what you have in the
working tree matches the pre-image _and_ post-image blob is
already available in the object directory.

Later we _might_ want to enhance the diff output to also include
the full binary data of the post-image, to make this more
useful, but this is good enough for local rebasing application.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

After failed patch application, you can manually apply the patch
(this includes resolving the conflicted merge after git-am falls
back to 3-way merge) and run git-update-index on necessary paths
to prepare the index file in a shape a successful patch
application should have produced.  Then re-running git-am --resolved
would record the resulting index file along with the commit log
information taken from the patch e-mail.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Recently we fixed 'git-apply --stat' not to barf on a binary
differences.  But it accidentally broke the error detection when
we actually attempt to apply them.

This commit fixes the problem and adds test cases.
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>

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

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

Signed-off-by: NAlecs King <alecsk@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fix git import script not to assume that .git/HEAD is a symlink.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For some reason I've done a "git grep" twice with no pattern, which is
really irritating, since it just grep everything. If I actually wanted
that, I could do "git grep ^" or something.

So add a "usage" message if the pattern is empty.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Updates to fix the nits found during the list discussion.

 - Lose PATH_TO_MAN; just rely on execlp() to find whereever the
   "man" command is installed.

 - Do not randomly chdir(), but concatenate to the current
   working directory only if the given path is not absolute.

 - Lose use of glob(); read from exec_path and do sorting
   ourselves -- it is not that much more work.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

python 2.2.1 is perfectly capable of executing git-merge-recursive,
provided that it finds heapq and sets. All you have to do is to steal
heapq.py and sets.py from python 2.3 or newer, and drop them in your
GIT_PYTHON_PATH.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

GIT_EXEC_PATH *has* to be set.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Simplify and actually make llist_sorted_difference_inplace work
by using llist_sorted_remove instead of duplicating parts of the
code.
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It's by design a bit stupid (matching ^git rather than ^git-), so as
to work with 'gitk' and 'git' as well.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The program 'git' now has --exec-path which needs explaining.

Renamed old "DESCRIPTION" to "CORE GIT COMMANDS" to make room for
"OPTIONS" while following follow some sort of convention.

Also updated AUTHORS section to pat my own back a bit.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch provides a C implementation of the 'git' program and
introduces support for putting the git-* commands in a directory
of their own. It also saves some time on executing those commands
in a tight loop and it prints the currently available git commands
in a nicely formatted list.

The location of the GIT_EXEC_PATH (name discussion's closed, thank gods)
can be obtained by running

	git --exec-path

which will hopefully give porcelainistas ample time to adapt their
heavy-duty loops to call the core programs directly and thus save
the extra fork() / execve() overhead, although that's not really
necessary any more.

The --exec-path value is prepended to $PATH, so the git-* programs
should Just Work without ever requiring any changes to how they call
other programs in the suite.

Some timing values for 10000 invocations of git-var >&/dev/null:
	git.sh: 24.194s
	git.c:   9.044s
	git-var: 7.377s

The git-<tab><tab> behaviour can, along with the someday-to-be-deprecated
git-<command> form of invocation, be indefinitely retained by adding
the following line to one's .bash_profile or equivalent:

	PATH=$PATH:$(git --exec-path)

Experimental libraries can be used by either setting the environment variable
GIT_EXEC_PATH, or by using

	git --exec-path=/some/experimental/exec-path

Relative paths are properly grok'ed as exec-path values.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

An object name is 20-byte 'unsigned char', not 'char'.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A while ago, a rename-detection limit logic was implemented as a
response to this thread:

	http://marc.theaimsgroup.com/?l=git&m=112413080630175

where gitweb was found to be using a lot of time and memory to
detect renames on huge commits.  git-diff family takes -l<num>
flag, and if the number of paths that are rename destination
candidates (i.e. new paths with -M, or modified paths with -C)
are larger than that number, skips rename/copy detection even
when -M or -C is specified on the command line.

This commit makes the rename detection limit easier to use.  You
can have:

	[diff]
		renamelimit = 30

in your .git/config file to specify the default rename detection
limit.  You can override this from the command line; giving 0
means 'unlimited':

	git diff -M -l0

We might want to change the default behaviour, when you do not
have the configuration, to limit it to say 20 paths or so.  This
would also help the diffstat generation after a big 'git pull'.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This allows you to force git to avoid symlinks for refs. Just add
something like

	[core]
		symrefsonly = true

to .git/config.

Don´t forget to "git checkout your_branch", or it does not do anything...
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Store pointers to referenced objects in a variable sized array instead
of linked list.  This cuts down memory usage of utilities which use
object references; e.g., git-fsck-objects --full on the git.git
repository consumes about 2 MB of memory tracked by Massif instead of
7 MB before the change.  Object refs are still the biggest consumer of
memory (57%), but the malloc overhead for a single block instead of a
linked list is substantially smaller.
Signed-off-by: NSergey Vlasov <vsu@altlinux.ru>
Signed-off-by: NJunio C Hamano <junkio@cox.net>