On big endian platforms with 8-byte unsigned long, the code reads the
size of the index extension section (which is a 4-byte network byte
order integer) incorrectly.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This converts the index explicitly on read and write to its on-disk
format, allowing the in-core format to contain more flags, and be
simpler.

In particular, the in-core format is now host-endian (as opposed to the
on-disk one that is network endian in order to be able to be shared
across machines) and as a result we can dispense with all the
htonl/ntohl on accesses to the cache_entry fields.

This will make it easier to make use of various temporary flags that do
not exist in the on-disk format.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* git://repo.or.cz/git-gui:
  git-gui: Makefile - Handle $DESTDIR on Cygwin
  git-gui: add french glossary: glossary/fr.po
  git-gui: Refresh file status description after hunk application
  git-gui: Allow 'Create New Repository' on existing directories
  git-gui: Initial french translation
  git-gui: Improve German translation.
  git-gui: Updated Swedish translation after mailing list review.
  git-gui: Fix broken revert confirmation.
  git-gui: Update German translation
  git-gui: Update glossary: add term "hunk"

* git://git.kernel.org/pub/scm/gitk/gitk:
  [PATCH] gitk: make Ctrl "+" really increase the font size

The URL to a repository http-push and http-fetch takes should
have a trailing slash.  Instead of failing the request, add it
ourselves before attempting such a request.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The first thing http-push does is a PROPFIND to see if the other
end supports locking.  The failure message we give is always
reported as "no DAV locking support at the remote repository",
regardless of the reason why we ended up not finding the locking
support on the other end.

This moves the code to report "no DAV locking support" down the
codepath so that the message is issued only when we successfully
get a response to PROPFIND and the other end say it does not
support locking.  Other failures, such as connectivity glitches
and credential mismatches, have their own error message issued
and we will not issue "no DAV locking" error (we do not even
know if the remote end supports it).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Failing instead of silently not updating remote refs makes the things
clearer for the user when trying to push on a repository while another
person do (or while a dandling locks are waiting for a 10 minutes
timeout).

When silently not updating remote refs, the user does not even know
that git has pushed the objects but leaved the refs as they were
before (e.g. a new bunch of commits on branch "master" is uploaded,
however the branch by itsel still points on the previous head commit).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Releasing webdav lock even if push fails because of bad (or no)
reference on command line.

To reproduce the issue that this patch fixes, prepare a test repository
availlable over http+webdav, say at http://myhost/myrepo.git/

Then:

  $ git clone http://myhost/myrepo.git/
  $ cd myrepo
  $ git push http
  Fetching remote heads...
    refs/
    refs/heads/
    refs/tags/
  No refs in common and none specified; doing nothing.
  $ git push http
  Fetching remote heads...
    refs/
    refs/heads/
    refs/tags/
  No refs in common and none specified; doing nothing.
  $

Finally, you look at the web server logs, and will find one LOCK query
and no UNLOCK query, of course the second one will be in 423 return
code instead of 200:

1.2.3.4 - gb [19/Jan/2008:14:24:56 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 200 465
(...)
1.2.3.4 - gb [19/Jan/2008:14:25:10 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 423 363

With this patch, there would have be two UNLOCKs in addition of the LOCKs

From the user's point of view:

- If you realize that you should have typed e.g. "git push http
  master" instead of "git push http", you will have to wait for 10
  minutes for the lock to expire by its own.

- Furthermore, if somebody else is dumb enough to type "git push http"
  while you need to push "master" branch, then you'll need too to wait
  for 10 minutes too.
Signed-off-by: NGr.ANigoire Barbier <gb@gbarbier.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This tightens the parsing of a commit object in a couple of ways.

 - The "tree " header must end with a LF (earlier we did not
   check this condition).

 - Make sure parsing of timestamp on the "committer " header
   does not go beyond the buffer, even when (1) the "author "
   header does not end with a LF (this means that the commit
   object is malformed and lacks the committer information) or
   (2) the "committer " header does not have ">" that is the end
   of the e-mail address, or (3) the "committer " header does
   not end with a LF.

We however still keep the existing behaviour to return a parsed
commit object even when non-structural headers such as committer
and author are malformed, so that tools that need to look at
commits to clean up a history with such broken commits can still
get at the structural data (i.e. the parents chain and the tree
object).
Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NDan McGee <dpmcgee@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Replace the "This manual page describes only the most frequently used options."
text with the list of rev-list options in git-log manpage. (The git-diff-tree
options are already included.)

Move these options to a separate file and include it from both
git-rev-list.txt and git-log.txt.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Make http-push always fail when not compiled with USE_CURL_MULTI, since
otherwise it corrupts the remote repository (and then fails anyway).
Signed-off-by: NGrégoire Barbier <gb@gbarbier.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since we are now sanity-checking the contents of patches and
refusing to send ones with long lines, this knob provides a
way for the user to override the new behavior (if, e.g., he
knows his SMTP path will handle it).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We try to catch errors early so that we don't end up sending
half of a broken patch series. Right now the only validation
is checking that line-lengths are under the SMTP-mandated
limit of 998.

The validation parsing is very crude (it just checks each
line length without understanding the mailbox format) but
should work fine for this simple check.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We never even look at the command line arguments until after
we have prompted the user for some information. So running
"git send-email" without arguments would prompt for "from"
and "to" headers, only to then die with "No patch files
specified." Instead, let's try to do as much error checking
as possible before getting user input.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Without this change, each diagnostic could use an errno value
clobbered by the close or unlink in rollback_lock_file.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When the specfile (export-subst) attribute was introduced, it added a
dependency from archive-{tar|zip}.c to builtin-archive.c. This broke the
support for archive-operations in libgit.a since builtin-archive.o doesn't
belong in libgit.a.

This patch moves the functions required by libgit.a from builtin-archive.c
to the new file archive.c (which becomes part of libgit.a).
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These were mistakenly being colored in "meta" color.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Update configure.ac (and config.mak.in) by adding test for unsetenv
(NO_UNSETENV).  Add comment about NO_UNSETENV to Makefile header, as
original commit 731043fd adding compat/unsetenv.c didn't do that.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NThomas Zander <zander@kde.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

fast-import was relying on the fact that on most systems mmap() and
write() are synchronized by the filesystem's buffer cache.  We were
relying on the ability to mmap() 20 bytes beyond the current end
of the file, then later fill in those bytes with a future write()
call, then read them through the previously obtained mmap() address.

This isn't always true with some implementations of NFS, but it is
especially not true with our NO_MMAP=YesPlease build time option used
on some platforms.  If fast-import was built with NO_MMAP=YesPlease
we used the malloc()+pread() emulation and the subsequent write()
call does not update the trailing 20 bytes of a previously obtained
"mmap()" (aka malloc'd) address.

Under NO_MMAP that behavior causes unpack_entry() in sha1_file.c to
be unable to read an object header (or data) that has been unlucky
enough to be written to the packfile at a location such that it
is in the trailing 20 bytes of a window previously opened on that
same packfile.

This bug has gone unnoticed for a very long time as it is highly data
dependent.  Not only does the object have to be placed at the right
position, but it also needs to be positioned behind some other object
that has been accessed due to a branch cache invalidation.  In other
words the stars had to align just right, and if you did run into
this bug you probably should also have purchased a lottery ticket.

Fortunately the workaround is a lot easier than the bug explanation.

Before we allow unpack_entry() to read data from a pack window
that has also (possibly) been modified through write() we force
all existing windows on that packfile to be closed.  By closing
the windows we ensure that any new access via the emulated mmap()
will reread the packfile, updating to the current file content.

This comes at a slight performance degredation as we cannot reuse
previously cached windows when we update the packfile.  But it
is a fairly minor difference as the window closes happen at only
two points:

 - When the packfile is finalized and its .idx is generated:

   At this stage we are getting ready to update the refs and any
   data access into the packfile is going to be random, and is
   going after only the branch tips (to ensure they are valid).
   Our existing windows (if any) are not likely to be positioned
   at useful locations to access those final tip commits so we
   probably were closing them before anyway.

 - When the branch cache missed and we need to reload:

   At this point fast-import is getting change commands for the next
   commit and it needs to go re-read a tree object it previously
   had written out to the packfile.  What windows we had (if any)
   are not likely to cover the tree in question so we probably were
   closing them before anyway.

We do try to avoid unnecessarily closing windows in the second case
by checking to see if the packfile size has increased since the
last time we called unpack_entry() on that packfile.  If the size
has not changed then we have not written additional data, and any
existing window is still vaild.  This nicely handles the cases where
fast-import is going through a branch cache reload and needs to read
many trees at once.  During such an event we are not likely to be
updating the packfile so we do not cycle the windows between reads.

With this change in place t9301-fast-export.sh (which was broken
by c3b0dec5) finally works again.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We also move the assignment of -1 to the lock file descriptor
up, so that rollback_lock_file() can be called safely after a
possible attempt to fclose(). This matches the contents of
the 'if' statement just above testing success of fdopen().
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

gg_libdir is converted to an absolute Windows path on Cygwin,
but a later step attempts to prefix $DESTDIR to install to a
staging directory. Explicitly separate the uses of gg_libdir for
these two purposes so installation to $DESTDIR will work.
Signed-off-by: NMark Levedahl <mdl123@verizon.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Instead of calling close_lock_file() and commit_lock_file() directly,
which take a struct lock_file argument, add two new functions:
close_ref() and commit_ref(), which handle calling the previous
lock_file functions and modifying the ref_lock structure.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Remove remaining double close(2)'s.  i.e. close() before
commit_locked_index() or commit_lock_file().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The lockfile API is a handy way to obtain a file that is cleaned
up if you die().  But sometimes you would need this sequence to
work:

 1. hold_lock_file_for_update() to get a file descriptor for
    writing;

 2. write the contents out, without being able to decide if the
    results should be committed or rolled back;

 3. do something else that makes the decision --- and this
    "something else" needs the lockfile not to have an open file
    descriptor for writing (e.g. Windows do not want a open file
    to be renamed);

 4. call commit_lock_file() or rollback_lock_file() as
    appropriately.

This adds close_lock_file() you can call between step 2 and 3 in
the above sequence.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We have nice set of placeholders, but nobody stepped in to fill
the gap in the API documentation, so I am doing it myself.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This makes write_ref_sha1() more careful: it actually checks the SHA1 of
the ref it is updating, and refuses to update a ref with an object that it
cannot find.

Perhaps more importantly, it also refuses to update a branch head with a
non-commit object. I don't quite know *how* the stable series maintainers
were able to corrupt their repository to have a HEAD that pointed to a tag
rather than a commit object, but they did. Which results in a totally
broken repository that cannot be cloned or committed on.

So make it harder for people to shoot themselves in the foot like that.

The test t1400-update-ref.sh is fixed at the same time, as it
assumed that the commands involved in the particular test would
not care about corrupted repositories whose refs point at
nonexistant bogus objects.  That assumption does not hold true
anymore.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Correct a spelling mistake in a comment.
Signed-off-by: NBill Lear <rael@zopyra.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NDave Peticolas <dave@krondo.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since having non-commits in branches is a no-no, and just means you cannot
commit on them, let's make fsck tell you when a branch is bad.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When creating the commit object, be a whole lot more careful about making
sure that the parent lines really are valid parent lines. Check things
like MERGE_HEAD having proper SHA1 lines in it, and double-check that all
the parents exist and are actually commits.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are two heuristics in Git to detect whether a file is binary
or text. One in xdiff-interface.c (which is taken from GNU diff)
relies on existence of the NUL byte at the beginning. However,
convert.c used a different heuristic, which relied on the percent
of non-printable symbols (less than 1% for text files).

Due to differences in detection whether a file is binary or not,
it was possible that a file that diff treats as binary could be
treated as text by CRLF conversion. This is very confusing for a
user who sees that 'git diff' shows the file as binary expects it
to be added as binary.

This patch makes is_binary to consider any file that contains at
least one NUL character as binary, to ensure that the heuristics
used for CRLF conversion is tighter than what is used by diff.
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If we apply a hunk in either direction this may change the file's
status.  For example if a file is completely unstaged, and has at
least two hunks in it and the user stages one hunk the file will
change from "Modified, not staged" to "Portions staged for commit".

Resetting the file path causes our trace on this variable to fire;
that trace is used to update the file header in the diff viewer to
the file's current status.

Noticed by Johannes Sixt.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Often users setup a few source files and get a project rolling
before they create a Git repository for it.  In such cases the
core Git tools allow users to initialize a new repository by
simply running `git init` at the desired root level directory.

We need to allow the same situation in git-gui; if the user is
trying to make a new repository we should let them do that to any
location they chose.  If the directory already exists and already
has files contained within it we still should allow the user to
create a repository there.  However we still need to disallow
creating a repository on top of an existing repository.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Here are some of the choices made to translate Git Gui to french:

- commit         -> "commit" (noun) or "commiter" (verb)
- stage (index)  -> "pré-commit" (noun) or "pré-commiter" (verb)
- (re)scan       -> "(re)synchroniser"
- reset          -> "réinitialiser"
- checkout       -> "emprunt" (noun) or "emprunter" (verb)
- revision expression -> "expression de révison"

I am not completely happy with these, but it's a start...

[sp: Inserted a missing LF in message on line 466]
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>