SVN is not entirely consistent in returning log information and
sometimes returns file information when adding subdirectories,
and sometimes it does not (only returning information about the
directory that was added).  This caused git-svn to occasionally
add a file to the list of files to be fetched twice.  Now we
change the data structure to be hash to avoid repeated fetches.

As of now (in master), this only affects repositories fetched
without deltas enabled (file://, and when manually overriden
with GIT_SVN_DELTA_FETCH=0); so this bug mainly affects users of
1.4.4.1 and maint.

Thanks to Florian Weimer for reporting this bug.

[jc: backported for maint]
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Introducing yourself to git early would be a good idea; otherwise
the user may not find the mistake until much later when "git log"
is learned.

Teaching "commit -a" without saying that it is a shortcut for
listing the paths to commit leaves the user puzzled.  Teach the
form with explicit paths first.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We lacked "--" termination in the underlying init_revisions() call
which made it impossible to specify a revision that happens to
have the same name as an existing file.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We used to get the case that more than two paths came from the
same commit wrong when computing the output width and deciding
to turn on --show-name option automatically.  When we find that
lines that came from a path that is different from what we
started digging from, we should always turn --show-name on, and
we should count the name length for all files involved.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In xemit.c:xdl_emit_diff() a buffer for showing the function name as
commentary is allocated; this buffer was 40 characters.  This is a bit
small; particularly for C++ function names where there is often an
identical prefix (like void LongNamespace::LongClassName) on multiple
functions, which makes the context the same everywhere.  In other words
the context is useless.  This patch increases that buffer to 80
characters - which may still not be enough, but is better
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Using dcommit could cause the user to lose uncommitted changes
during the reset --hard operation, so change it to reset --mixed.

If dcommit chooses the rebase path, then git-rebase will already
error out when local changes are made.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

some SVN repositories have a revision 0 (committed by no author
and no date) when created; so when we need to ensure that we
check any revision variables are defined, and not just
non-zero.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

dcommit would unconditionally append "~1" to a commit in order
to generate a diff.  Now we generate a meaningful error message
if we try to generate an impossible diff.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We can't rely on sizeof(struct zip_*) returning the sum of
all struct members.  At least on ARM padding is added at the
end, as Gerrit Pape reported.  This fixes the problem but
still lets the compiler do the summing by introducing
explicit padding at the end of the structs and then taking
its offset as the combined size of the preceding members.

As Junio correctly notes, the _end[] marker array's size
must be greater than zero for compatibility with compilers
other than gcc.  The space wasted by the markers can safely
be neglected because we only have one instance of each
struct, i.e. in sum 3 wasted bytes on i386, and 0 on ARM. :)

We still rely on the compiler to not add padding between the
struct members, but that's reasonable given that all of them
are unsigned char arrays.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

An earlier commit f28b34a broke symlinks when trust-executable-bit
is not set because it incorrectly assumed that everything was a
regular file.

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

Asciidoc-include it into the manuals for programs that use the
--pretty command-line option, for consistency among the docs.

This describes all the pretty-formats currently listed in the cmit_fmt
enum in commit.h, and also briefly describes the presence and format
of the 'Merge: ' line in some pretty formats.

There's a hedge that limiting your view of history can affect what
goes in the Merge: line, and that --abbrev/--no-abbrev do nothing to
the 'raw' format.
Signed-off-by: NChris Riddoch <chris@syntacticsugar.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Rephrased a sentence in order to make more clear the concept of
pull . branch
Signed-off-by: NPaolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This tiny patch makes GIT compile again on HP-UX 11i.

[jc: The setlinebuf() is described as unportable to BSD before
 4.2; it's not even in POSIX, while setvbuf() is in ISO C.]
Signed-off-by: NMichal Rokos <michal.rokos@nextsoft.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

As discussed on git mailing list let's teach the reader about
the possiblity to have automatically signed off the commit running
the git-commit -s command
Signed-off-by: NPaolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

An earlier commit b37a562a added a check to see if the ref
points at a valid object (as a part of 'negative ref' support
which we currently do not use), but did so only while iterating
over both packed and loose refs, and forgot to apply the same
check while iterating over the remaining ones.

We might want to replace the "if null then omit it" check with
"eh --- what business does a 0{40} value have here?" complaint
later since we currently do not use negative refs, but that is
a separate issue.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This side-ports commit fd19f620 from Cogito, in which I fixed
exactly the same bug.  Somehow nobody noticed this for a long
time in git.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For one, the documentation invalidly claimed that the paths have to be
absolute when that's not the case and in fact there is a very valid reason
not to use absolute paths (documented the reason as well).
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

HEAD was still described as a symlink instead of a symref.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I copied most of the text from git-status.txt.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch fixes a sparse warning about inaccurate_eof being a
"dubious one-bit signed bitfield", makes three more binary
variables members of this (now unsigned) bitfield and adds a
short comment to indicate the nature of two ternary variables.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Z_NULL is defined as 0, use a proper NULL pointer in its stead.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The declaration of discard_cache() in cache.h already has its "void".
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

inacurate -> inaccurate, sorry if it was a pun. ;-)
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Unfortunately, git-for-each-refs is currently unusable for peeking into tag
comments, since it uses freed pointers, so it just prints out all sort of
garbage.

This makes it strdup() contents and body values.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Ok, this is a _really_ stupid case, and I don't think it matters, but hey,
we should never SIGSEGV.

Steps to reproduce:

	mkdir duh
	cd duh
	git init-db
	git-fmt-merge-msg < /dev/null

will cause a SIGSEGV in cmd_fmt_merge_msg(), because we're doing a
strncmp() with a NULL current_branch.

And yeah, it's an insane schenario, and no, it doesn't really matter. The
only reason I noticed was that a broken version of my "git pull" into an
empty directory would cause this.

This silly patch just replaces the SIGSEGV with a controlled exit with an
error message.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We used to complain that we cannot merge anything we fetched
with a local branch that does not exist yet.  Just treat the
case as a natural extension of fast forwarding and make the
local branch'es tip point at the same commit we just fetched.
After all an empty repository without an initial commit is an
ancestor of any commit.

[jc: I added a trivial test.  We've become sloppy but we should
 stick to the discipline of covering new behaviour with new
 tests. ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Otherwise OpenBSD header files drop S_ISLNK() definition which is used in
an inline defined in cache.h
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Although I converted upstream coreutils to git last month, I just
reconverted coreutils once again, as a test, and ended up with a
git repository of about 130MB (contrast with my packed git repo of
size 52MB).  That was because there were a lot of commits (but < 1024)
after the final automatic "git-repack -a -d".

Running a final
  git-repack -a -d && git-prune-packed
cut the final repository size down to the expected size.

So this looks like an easy way to improve git-cvsimport.
Just run "git repack ..." at the end if there's more than
some reasonable amount of not-packed data.

My choice of 1MB is a little arbitrarily.  I wouldn't mind missing
the minimal repo size by 1MB.  At the other end of the spectrum,
it's probably not worthwhile to pack everything when the total
repository size is less than 1MB.

Here's the patch:
Signed-off-by: NJim Meyering <jim@meyering.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Looks like a repo.or.cz-specific change slipped in.
Signed-off-by: NAlexandre Julliard <julliard@winehq.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It is often wanted on the #git channel that this were to work to
recover removed directory:

	rm -fr Documentation
	git checkout -- Documentation
	git checkout HEAD -- Documentation ;# alternatively

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

Instead of silently ignoring one over the other, complain on
this incompatible combination.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

"git-index-pack --fix-thin" relies on mmap() not changing the current
file position (otherwise the pack will be corrupted when writing the
final SHA1). Meet that expectation.
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>

* maint:
  Rework cvsexportcommit to handle binary files for all cases.
  Catch errors when writing an index that contains invalid objects.
  test-lib.sh: A command dying due to a signal is an unexpected failure.
  git-update-index(1): fix use of quoting in section title

Also adds test cases for adding removing and deleting
binary and text files plus two tests for the checks on
binary files.
Signed-off-by: NRobin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If git-write-index is called without --missing-ok, it reports invalid
objects that it finds in the index. But without this patch it dies
right away or may run into an infinite loop.
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When test_expect_failure detects that a command failed, it still has to
treat a program that crashed from a signal as unexpected failure.
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>