13 years agobuiltin-checkout.c: fix possible usage segfault
Jay Soffian [Mon, 18 Feb 2008 10:20:20 +0000 (05:20 -0500)]
builtin-checkout.c: fix possible usage segfault

Not terminating the options[] array with OPT_END can cause
usage ("git checkout -h") output to segfault.

Signed-off-by: Jay Soffian <>
Signed-off-by: Junio C Hamano <>
13 years agocheckout: notice when the switched branch is behind or forked
Junio C Hamano [Sun, 17 Feb 2008 01:17:09 +0000 (17:17 -0800)]
checkout: notice when the switched branch is behind or forked

When you are switching to a branch that is marked to merge from
somewhere else, e.g. when you have:

    [branch "next"]
            remote = upstream
            merge = refs/heads/next
    [remote "upstream"]
            url = ...
            fetch = refs/heads/*:refs/remotes/linus/*

and you say "git checkout next", the branch you checked out
may be behind, and you may want to update from the upstream
before continuing to work.

This patch makes the command to check the upstream (in this
example, "refs/remotes/linus/next") and our branch "next", and:

    (1) if they match, nothing happens;

    (2) if you are ahead (i.e. the upstream is a strict ancestor
        of you), one line message tells you so;

    (3) otherwise, you are either behind or you and the upstream
        have forked.  One line message will tell you which and
        then you will see a "log --pretty=oneline --left-right".

We could enhance this with an option that tells the command to
check if there is no local change, and automatically fast
forward when you are truly behind.  But I ripped out that change
because I was unsure what the right way should be to allow users
to control it (issues include that checkout should not become
automatically interactive).

Signed-off-by: Junio C Hamano <>
13 years agoBuild in checkout
Daniel Barkalow [Thu, 7 Feb 2008 16:40:23 +0000 (11:40 -0500)]
Build in checkout

The only differences in behavior should be:

 - git checkout -m with non-trivial merging won't print out
   merge-recursive messages (see the change in

 - git checkout -- paths... will give a sensible error message if
   HEAD is invalid as a commit.

 - some intermediate states which were written to disk in the shell
   version (in particular, index states) are only kept in memory in
   this version, and therefore these can no longer be revealed by
   later write operations becoming impossible.

 - when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
   rr-cache/MERGE_RR, like reset always has.

I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.

Other than these items, the results should be identical to the shell
version, so far as I can tell.

[jc: squashed lock-file fix from Dscho in]

Signed-off-by: Daniel Barkalow <>
Signed-off-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
13 years agoMove code to clean up after a branch change to branch.c
Daniel Barkalow [Thu, 7 Feb 2008 16:40:16 +0000 (11:40 -0500)]
Move code to clean up after a branch change to branch.c

Signed-off-by: Daniel Barkalow <>
13 years agoLibrary function to check for unmerged index entries
Daniel Barkalow [Thu, 7 Feb 2008 16:40:13 +0000 (11:40 -0500)]
Library function to check for unmerged index entries

It's small, but it was in three places already, so it should be in the

Signed-off-by: Daniel Barkalow <>
13 years agoUse diff -u instead of diff in t7201
Daniel Barkalow [Thu, 7 Feb 2008 16:40:11 +0000 (11:40 -0500)]
Use diff -u instead of diff in t7201

If the test failed, it was giving really unclear ed script
output. Instead, give a diff that sort of suggests the problem. Also
replaces the use of "git diff" for this purpose with "diff -u".

Signed-off-by: Daniel Barkalow <>
13 years agoMove create_branch into a library file
Daniel Barkalow [Thu, 7 Feb 2008 16:40:08 +0000 (11:40 -0500)]
Move create_branch into a library file

You can also create branches, in exactly the same way, with checkout -b.

This introduces branch.{c,h} library files for doing porcelain-level
operations on branches (such as creating them with their appropriate
default configuration).

Signed-off-by: Daniel Barkalow <>
13 years agoBuild-in merge-recursive
Daniel Barkalow [Thu, 7 Feb 2008 16:40:05 +0000 (11:40 -0500)]
Build-in merge-recursive

This makes write_tree_from_memory(), which writes the active cache as
a tree and returns the struct tree for it, available to other code. It
also makes available merge_trees(), which does the internal merge of
two trees with a known base, and merge_recursive(), which does the
recursive internal merge of two commits with a list of common

The first two of these will be used by checkout -m, and the third is
presumably useful in general, although the implementation of checkout
-m which entirely matches the behavior of the shell version does not
use it (since it ignores the difference of ancestry between the old
branch and the new branch).

Signed-off-by: Daniel Barkalow <>
13 years agoAdd "skip_unmerged" option to unpack_trees.
Daniel Barkalow [Thu, 7 Feb 2008 16:40:02 +0000 (11:40 -0500)]
Add "skip_unmerged" option to unpack_trees.

This option allows the caller to reset everything that isn't unmerged,
leaving the unmerged things to be resolved. If, after a merge of
"working" and "HEAD", this is used with "HEAD" (reset, !update), the
result will be that all of the changes from "local" are in the working
tree but not added to the index (either with the index clean but
unchanged, or with the index unmerged, depending on whether there are

This will be used in checkout -m.

Signed-off-by: Daniel Barkalow <>
13 years agoDiscard "deleted" cache entries after using them to update the working tree
Daniel Barkalow [Thu, 7 Feb 2008 16:39:59 +0000 (11:39 -0500)]
Discard "deleted" cache entries after using them to update the working tree

Way back in read-tree.c, we used a mode 0 cache entry to indicate that
an entry had been deleted, so that the update code would remove the
working tree file, and we would just skip it when writing out the
index file afterward.

These days, unpack_trees is a library function, and it is still
leaving these entries in the active cache. Furthermore, unpack_trees
doesn't correctly ignore those entries, and who knows what other code
wouldn't expect them to be there, but just isn't yet called after a
call to unpack_trees. To avoid having other code trip over these
entries, have check_updates() remove them after it removes the working
tree files.

While we're at it, simplify the loop in check_updates(), and avoid
passing global variables as parameters to check_updates(): there is
only one call site anyway.

Signed-off-by: Daniel Barkalow <>
13 years agoSend unpack-trees debugging output to stderr
Daniel Barkalow [Thu, 7 Feb 2008 16:39:56 +0000 (11:39 -0500)]
Send unpack-trees debugging output to stderr

This is to keep git-stash from getting confused if you're debugging

Signed-off-by: Daniel Barkalow <>
13 years agoAdd flag to make unpack_trees() not print errors.
Daniel Barkalow [Thu, 7 Feb 2008 16:39:52 +0000 (11:39 -0500)]
Add flag to make unpack_trees() not print errors.

(This applies only to errors where a plausible operation is impossible due
to the particular data, not to errors resulting from misuse of the merge

This will allow builtin-checkout to suppress merge errors if it's
going to try more merging methods.

Additionally, if unpack_trees() returns with an error, but without
printing anything, it will roll back any changes to the index (by
rereading the index, currently). This obviously could be done by the
caller, but chances are that the caller would forget and debugging
this is difficult. Also, future implementations may give unpack_trees() a
more efficient way of undoing its changes than the caller could.

Signed-off-by: Daniel Barkalow <>
13 years agoAllow callers of unpack_trees() to handle failure
Daniel Barkalow [Thu, 7 Feb 2008 16:39:48 +0000 (11:39 -0500)]
Allow callers of unpack_trees() to handle failure

Return an error from unpack_trees() instead of calling die(), and exit
with an error in read-tree, builtin-commit, and diff-lib. merge-recursive
already expected an error return from unpack_trees, so it doesn't need to
be changed. The merge function can return negative to abort.

This will be used in builtin-checkout -m.

Signed-off-by: Daniel Barkalow <>
13 years agolazy index hashing
Junio C Hamano [Wed, 23 Jan 2008 07:01:13 +0000 (23:01 -0800)]
lazy index hashing

This delays the hashing of index names until it becomes necessary for
the first time.

Signed-off-by: Junio C Hamano <>
13 years agoCreate pathname-based hash-table lookup into index
Linus Torvalds [Wed, 23 Jan 2008 02:41:14 +0000 (18:41 -0800)]
Create pathname-based hash-table lookup into index

This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.

No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.

That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.

Guiding principles behind this patch:

 - it shouldn't be too costly. In fact, my primary goal here was to
   actually speed up "git commit" with a fully populated kernel tree, by
   being faster at checking whether a file already existed in the index. I
   did succeed, but only barely:

Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real    0m0.255s
user    0m0.168s
sys     0m0.088s

Best after:

[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real    0m0.233s
user    0m0.144s
sys     0m0.088s

   so some things are actually faster (~8%).

   Caveat: that's really the best case. Other things are invariably going
   to be slightly slower, since we populate that index cache, and quite
   frankly, few things really use it to look things up.

   That said, the cost is really quite small. The worst case is probably
   doing a "git ls-files", which will do very little except puopulate the
   index, and never actually looks anything up in it, just lists it.

[torvalds@woody linux]$ time git ls-files > /dev/null
real    0m0.016s
user    0m0.016s
sys     0m0.000s

[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real    0m0.021s
user    0m0.012s
sys     0m0.008s

   and while the thing has really gotten relatively much slower, we're
   still talking about something almost unmeasurable (eg 5ms). And that
   really should be pretty much the worst case.

   So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
   poison - this patch has the advantage that it will _likely_ speed up
   the cases that are complex and expensive more than it slows down the
   cases that are already so fast that nobody cares. But if you look at
   relative speedups/slowdowns, it doesn't look so good.

 - It should be simple and clean

   The code may be a bit subtle (the reasons I do hash removal the way I
   do etc), but it re-uses the existing hash.c files, so it really is
   fairly small and straightforward apart from a few odd details.

Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).

NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.

Signed-off-by: Linus Torvalds <>
Signed-off-by: Junio C Hamano <>
13 years agoread-cache.c: introduce is_racy_timestamp() helper
Junio C Hamano [Mon, 21 Jan 2008 08:44:50 +0000 (00:44 -0800)]
read-cache.c: introduce is_racy_timestamp() helper

This moves a common boolean expression into a helper function,
and makes the comparison between filesystem timestamp and index
timestamp done in the function in line with the other places.
st.st_mtime should be casted to (unsigned int) when compared to
an index timestamp ce_mtime.

Signed-off-by: Junio C Hamano <>
13 years agoread-cache.c: fix a couple more CE_REMOVE conversion
Junio C Hamano [Wed, 23 Jan 2008 05:24:21 +0000 (21:24 -0800)]
read-cache.c: fix a couple more CE_REMOVE conversion

It is a D/F conflict if you want to add "foo/bar" to the index
when "foo" already exists.  Also it is a conflict if you want to
add a file "foo" when "foo/bar" exists.

An exception is when the existing entry is there only to mark "I
used to be here but I am being removed".  This is needed for
operations such as "git read-tree -m -u" that update the index
and then reflect the result to the work tree --- we need to
remember what to remove somewhere, and we use the index for
that.  In such a case, an existing file "foo" is being removed
and we can create "foo/" directory and hang "bar" underneath it
without any conflict.

We used to use (ce->ce_mode == 0) to mark an entry that is being
removed, but (CE_REMOVE & ce->ce_flags) is used for that purpose
these days.  An earlier commit forgot to convert the logic in
the code that checks D/F conflict condition.

The old code knew that "to be removed" entries cannot be at
higher stage and actively checked that condition, but it was an
unnecessary check.  This patch removes the extra check as well.

Acked-by: Linus Torvalds <>
Signed-off-by: Junio C Hamano <>
13 years agoAlso use unpack_trees() in do_diff_cache()
Johannes Schindelin [Sun, 20 Jan 2008 15:19:56 +0000 (15:19 +0000)]
Also use unpack_trees() in do_diff_cache()

As in run_diff_index(), we call unpack_trees() with the oneway_diff()
function in do_diff_cache() now.  This makes the function diff_cache()

Signed-off-by: Johannes Schindelin <>
Signed-off-by: Linus Torvalds <>
13 years agoMake run_diff_index() use unpack_trees(), not read_tree()
Linus Torvalds [Sun, 20 Jan 2008 01:27:12 +0000 (17:27 -0800)]
Make run_diff_index() use unpack_trees(), not read_tree()

A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.

The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.

So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree.  That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!

This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.

Best time before:

[torvalds@woody linux]$ time git commit > /dev/null
real    0m0.399s
user    0m0.232s
sys     0m0.164s

Best time after:

[torvalds@woody linux]$ time git commit > /dev/null
real    0m0.254s
user    0m0.140s
sys     0m0.112s

so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the

Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 60.69    0.000704           0     69230        31 lstat
 23.62    0.000274           0      5522           getdents
  8.36    0.000097           0      5508      2638 open
  2.59    0.000030           0      2869           close
  2.50    0.000029           0       274           write
  1.47    0.000017           0      2844           fstat

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 45.17    0.000276           0      5522           getdents
 26.51    0.000162           0     23112        31 lstat
 19.80    0.000121           0      5503      2638 open
  4.91    0.000030           0      2864           close
  1.48    0.000020           0       274           write
  1.34    0.000018           0      2844           fstat

It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..

NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in

Signed-off-by: Linus Torvalds <>
13 years agoAvoid running lstat(2) on the same cache entry.
Junio C Hamano [Sat, 19 Jan 2008 07:45:24 +0000 (23:45 -0800)]
Avoid running lstat(2) on the same cache entry.

Aside from the lstat(2) done for work tree files, there are
quite many lstat(2) calls in refname dwimming codepath.  This
patch is not about reducing them.

 * It adds a new ce_flag, CE_UPTODATE, that is meant to mark the
   cache entries that record a regular file blob that is up to
   date in the work tree.  If somebody later walks the index and
   wants to see if the work tree has changes, they do not have
   to be checked with lstat(2) again.

 * fill_stat_cache_info() marks the cache entry it just added
   with CE_UPTODATE.  This has the effect of marking the paths
   we write out of the index and lstat(2) immediately as "no
   need to lstat -- we know it is up-to-date", from quite a lot
   fo callers:

    - git-apply --index
    - git-update-index
    - git-checkout-index
    - git-add (uses add_file_to_index())
    - git-commit (ditto)
    - git-mv (ditto)

 * refresh_cache_ent() also marks the cache entry that are clean
   with CE_UPTODATE.

 * write_index is changed not to write CE_UPTODATE out to the
   index file, because CE_UPTODATE is meant to be transient only
   in core.  For the same reason, CE_UPDATE is not written to
   prevent an accident from happening.

Signed-off-by: Junio C Hamano <>
Signed-off-by: Linus Torvalds <>
13 years agoindex: be careful when handling long names
Junio C Hamano [Sat, 19 Jan 2008 07:42:00 +0000 (23:42 -0800)]
index: be careful when handling long names

We currently use lower 12-bit (masked with CE_NAMEMASK) in the
ce_flags field to store the length of the name in cache_entry,
without checking the length parameter given to
create_ce_flags().  This can make us store incorrect length.

Currently we are mostly protected by the fact that many
codepaths first copy the path in a variable of size PATH_MAX,
which typically is 4096 that happens to match the limit, but
that feels like a bug waiting to happen.  Besides, that would
not allow us to shorten the width of CE_NAMEMASK to use the bits
for new flags.

This redefines the meaning of the name length stored in the
cache_entry.  A name that does not fit is represented by storing
CE_NAMEMASK in the field, and the actual length needs to be
computed by actually counting the bytes in the name[] field.
This way, only the unusually long paths need to suffer.

Signed-off-by: Junio C Hamano <>
Signed-off-by: Linus Torvalds <>
13 years agoMake on-disk index representation separate from in-core one
Linus Torvalds [Tue, 15 Jan 2008 00:03:17 +0000 (16:03 -0800)]
Make on-disk index representation separate from in-core one

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

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: Linus Torvalds <>
13 years agoGIT 1.5.4-rc4 v1.5.4-rc4
Junio C Hamano [Mon, 21 Jan 2008 01:04:53 +0000 (17:04 -0800)]
GIT 1.5.4-rc4

Signed-off-by: Junio C Hamano <>
13 years agoMerge git://
Junio C Hamano [Mon, 21 Jan 2008 00:58:38 +0000 (16:58 -0800)]
Merge git://

* git://
  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"

13 years agoMerge git://
Junio C Hamano [Mon, 21 Jan 2008 00:57:56 +0000 (16:57 -0800)]
Merge git://

* git://
  [PATCH] gitk: make Ctrl "+" really increase the font size

13 years agohttp-push and http-fetch: handle URLs without trailing /
Grégoire Barbier [Sat, 19 Jan 2008 15:22:50 +0000 (16:22 +0100)]
http-push and http-fetch: handle URLs without trailing /

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: Junio C Hamano <>
13 years agohttp-push: clarify the reason of error from the initial PROPFIND request
Junio C Hamano [Sun, 20 Jan 2008 23:00:54 +0000 (15:00 -0800)]
http-push: clarify the reason of error from the initial PROPFIND request

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: Junio C Hamano <>
13 years agohttp-push: fail when info/refs exists and is already locked
Grégoire Barbier [Sat, 19 Jan 2008 15:22:48 +0000 (16:22 +0100)]
http-push: fail when info/refs exists and is already locked

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

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: Junio C Hamano <>
13 years agohttp-push: fix webdav lock leak.
Grégoire Barbier [Sat, 19 Jan 2008 15:22:47 +0000 (16:22 +0100)]
http-push: fix webdav lock leak.

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/


  $ git clone http://myhost/myrepo.git/
  $ cd myrepo
  $ git push http
  Fetching remote heads...
  No refs in common and none specified; doing nothing.
  $ git push http
  Fetching remote heads...
  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: - gb [19/Jan/2008:14:24:56 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 200 465
(...) - 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: Gr\e.A\eNigoire Barbier <>
Signed-off-by: Junio C Hamano <>
13 years agoparse_commit_buffer: tighten checks while parsing
Martin Koegler [Sat, 19 Jan 2008 17:35:23 +0000 (18:35 +0100)]
parse_commit_buffer: tighten checks while parsing

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

Signed-off-by: Martin Koegler <>
Signed-off-by: Junio C Hamano <>
13 years agoUpdate git-completion for new 'remote rm' option
Dan McGee [Sun, 20 Jan 2008 06:54:57 +0000 (00:54 -0600)]
Update git-completion for new 'remote rm' option

Signed-off-by: Dan McGee <>
Signed-off-by: Junio C Hamano <>
13 years agodoc typo: s/prior committing/prior to committing/
Jim Meyering [Sat, 19 Jan 2008 15:23:32 +0000 (16:23 +0100)]
doc typo: s/prior committing/prior to committing/

Signed-off-by: Jim Meyering <>
Signed-off-by: Junio C Hamano <>
13 years agoInclude rev-list options in git-log manpage.
Miklos Vajna [Fri, 18 Jan 2008 22:58:57 +0000 (23:58 +0100)]
Include rev-list options in git-log manpage.

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: Miklos Vajna <>
Signed-off-by: Junio C Hamano <>
13 years agohttp-push: disable http-push without USE_CURL_MULTI
Grégoire Barbier [Sun, 13 Jan 2008 19:02:59 +0000 (20:02 +0100)]
http-push: disable http-push without USE_CURL_MULTI

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: Grégoire Barbier <>
Signed-off-by: Junio C Hamano <>
13 years agosend-email: add no-validate option
Jeff King [Fri, 18 Jan 2008 14:20:10 +0000 (09:20 -0500)]
send-email: add no-validate option

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: Jeff King <>
Signed-off-by: Junio C Hamano <>
13 years agosend-email: validate patches before sending anything
Jeff King [Fri, 18 Jan 2008 14:19:48 +0000 (09:19 -0500)]
send-email: validate patches before sending anything

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: Jeff King <>
Signed-off-by: Junio C Hamano <>
13 years agosend-email: detect invocation errors earlier
Jeff King [Fri, 18 Jan 2008 14:19:36 +0000 (09:19 -0500)]
send-email: detect invocation errors earlier

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: Jeff King <>
Signed-off-by: Junio C Hamano <>
13 years agofast-import: Don't use a maybe-clobbered errno value
Jim Meyering [Fri, 18 Jan 2008 18:35:49 +0000 (19:35 +0100)]
fast-import: Don't use a maybe-clobbered errno value

Without this change, each diagnostic could use an errno value
clobbered by the close or unlink in rollback_lock_file.

Signed-off-by: Jim Meyering <>
Signed-off-by: Junio C Hamano <>
13 years agoMove sha1_file_to_archive into libgit
Lars Hjemli [Mon, 14 Jan 2008 16:36:34 +0000 (17:36 +0100)]
Move sha1_file_to_archive into libgit

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: Lars Hjemli <>
Signed-off-by: Junio C Hamano <>
13 years agocolor unchanged lines as "plain" in "diff --color-words"
Jeff King [Thu, 17 Jan 2008 15:03:06 +0000 (10:03 -0500)]
color unchanged lines as "plain" in "diff --color-words"

These were mistakenly being colored in "meta" color.

Signed-off-by: Junio C Hamano <>
13 years agoautoconf: Add checking for unsetenv function
Jakub Narebski [Fri, 18 Jan 2008 01:03:51 +0000 (02:03 +0100)]
autoconf: Add checking for unsetenv function

Update (and 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: Jakub Narebski <>
Signed-off-by: Junio C Hamano <>
13 years agocore-tutorial typofix
Thomas Zander [Wed, 16 Jan 2008 22:48:21 +0000 (23:48 +0100)]
core-tutorial typofix

Signed-off-by: Thomas Zander <>
Signed-off-by: Junio C Hamano <>
13 years agoOfficially deprecate repo-config.
Junio C Hamano [Fri, 18 Jan 2008 06:52:40 +0000 (22:52 -0800)]
Officially deprecate repo-config.

Signed-off-by: Junio C Hamano <>
13 years agoFix random fast-import errors when compiled with NO_MMAP
Shawn O. Pearce [Fri, 18 Jan 2008 03:57:00 +0000 (22:57 -0500)]
Fix random fast-import errors when compiled with NO_MMAP

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 (which was broken
by c3b0dec509fe136c5417422f31898b5a4e2d5e02) finally works again.

Signed-off-by: Shawn O. Pearce <>
Signed-off-by: Junio C Hamano <>
13 years agofast-import.c: don't try to commit marks file if write failed
Brandon Casey [Thu, 17 Jan 2008 16:58:34 +0000 (10:58 -0600)]
fast-import.c: don't try to commit marks file if write failed

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: Brandon Casey <>
Acked-by: Shawn O. Pearce <>
Signed-off-by: Junio C Hamano <>
13 years agogit-gui: Makefile - Handle $DESTDIR on Cygwin
Mark Levedahl [Fri, 18 Jan 2008 03:50:23 +0000 (22:50 -0500)]
git-gui: Makefile - Handle $DESTDIR on Cygwin

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: Mark Levedahl <>
Signed-off-by: Shawn O. Pearce <>
13 years agogit-gui: add french glossary: glossary/fr.po
Christian Couder [Wed, 16 Jan 2008 07:19:34 +0000 (08:19 +0100)]
git-gui: add french glossary: glossary/fr.po

Signed-off-by: Christian Couder <>
Signed-off-by: Shawn O. Pearce <>
13 years agorefs.c: rework ref_locks by abstracting from underlying struct lock_file
Brandon Casey [Wed, 16 Jan 2008 19:14:30 +0000 (13:14 -0600)]
refs.c: rework ref_locks by abstracting from underlying struct lock_file

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: Junio C Hamano <>
13 years agoImprove use of lockfile API
Brandon Casey [Wed, 16 Jan 2008 19:12:46 +0000 (13:12 -0600)]
Improve use of lockfile API

Remove remaining double close(2)'s.  i.e. close() before
commit_locked_index() or commit_lock_file().

Signed-off-by: Junio C Hamano <>
13 years agoclose_lock_file(): new function in the lockfile API
Brandon Casey [Wed, 16 Jan 2008 19:05:32 +0000 (11:05 -0800)]
close_lock_file(): new function in the lockfile API

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

 1. hold_lock_file_for_update() to get a file descriptor for

 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

This adds close_lock_file() you can call between step 2 and 3 in
the above sequence.

Signed-off-by: Junio C Hamano <>
13 years agoDocument lockfile API
Junio C Hamano [Wed, 16 Jan 2008 19:00:13 +0000 (11:00 -0800)]
Document lockfile API

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: Junio C Hamano <>
13 years agoBe more careful about updating refs
Linus Torvalds [Tue, 15 Jan 2008 23:50:17 +0000 (15:50 -0800)]
Be more careful about updating refs

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

Signed-off-by: Linus Torvalds <>
Signed-off-by: Junio C Hamano <>
13 years agoCorrect spelling in diff.c comment
Bill Lear [Wed, 16 Jan 2008 12:46:53 +0000 (06:46 -0600)]
Correct spelling in diff.c comment

Correct a spelling mistake in a comment.

Signed-off-by: Bill Lear <>
Signed-off-by: Junio C Hamano <>
13 years agoDocumentation: fix and clarify grammar in git-merge docs.
Dave Peticolas [Wed, 16 Jan 2008 05:16:05 +0000 (21:16 -0800)]
Documentation: fix and clarify grammar in git-merge docs.

Signed-off-by: Dave Peticolas <>
Signed-off-by: Junio C Hamano <>
13 years agoMake 'git fsck' complain about non-commit branches
Linus Torvalds [Wed, 16 Jan 2008 00:34:17 +0000 (16:34 -0800)]
Make 'git fsck' complain about non-commit branches

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: Linus Torvalds <>
Signed-off-by: Junio C Hamano <>
13 years agoMake builtin-commit.c more careful about parenthood
Linus Torvalds [Wed, 16 Jan 2008 00:12:33 +0000 (16:12 -0800)]
Make builtin-commit.c more careful about parenthood

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: Linus Torvalds <>
Signed-off-by: Junio C Hamano <>
13 years agotreat any file with NUL as binary
Dmitry Potapov [Wed, 16 Jan 2008 01:59:12 +0000 (04:59 +0300)]
treat any file with NUL as binary

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: Dmitry Potapov <>
Signed-off-by: Junio C Hamano <>
13 years agogit-gui: Refresh file status description after hunk application
Shawn O. Pearce [Wed, 16 Jan 2008 06:29:39 +0000 (01:29 -0500)]
git-gui: Refresh file status description after hunk application

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: Shawn O. Pearce <>
13 years agogit-gui: Allow 'Create New Repository' on existing directories
Shawn O. Pearce [Wed, 16 Jan 2008 06:14:42 +0000 (01:14 -0500)]
git-gui: Allow 'Create New Repository' on existing directories

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: Shawn O. Pearce <>
13 years agogit-gui: Initial french translation
Christian Couder [Wed, 16 Jan 2008 05:51:40 +0000 (00:51 -0500)]
git-gui: Initial french translation

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: Christian Couder <>
Signed-off-by: Shawn O. Pearce <>
13 years agogit-gui: Improve German translation.
Christian Stimming [Tue, 15 Jan 2008 19:41:39 +0000 (20:41 +0100)]
git-gui: Improve German translation.

Change translation of "clone" back to "klonen" because "kopieren" is a
much broader term than this particular git action.

Signed-off-by: Shawn O. Pearce <>
13 years agogit-gui: Updated Swedish translation after mailing list review.
Peter Karlsson [Sat, 12 Jan 2008 08:28:57 +0000 (09:28 +0100)]
git-gui: Updated Swedish translation after mailing list review.

Signed-off-by: Shawn O. Pearce <>
13 years agogit-gui: Fix broken revert confirmation.
Christian Stimming [Tue, 8 Jan 2008 20:21:15 +0000 (21:21 +0100)]
git-gui: Fix broken revert confirmation.

I broke this extremely cool feature in 1ac17950,
but it is rather easy to fix this. Sorry for that.

Signed-off-by: Christian Stimming <>
Signed-off-by: Shawn O. Pearce <>
13 years agogit-gui: Update German translation
Christian Stimming [Mon, 7 Jan 2008 21:00:25 +0000 (22:00 +0100)]
git-gui: Update German translation

"revert" translated as "verwerfen".
"hunk" translated as "Kontext".
Several menu items reworded to be shorter.

Signed-off-by: Christian Stimming <>
Signed-off-by: Shawn O. Pearce <>
13 years agogit-gui: Update glossary: add term "hunk"
Christian Stimming [Mon, 7 Jan 2008 20:48:55 +0000 (21:48 +0100)]
git-gui: Update glossary: add term "hunk"

Signed-off-by: Shawn O. Pearce <>
13 years agogit-commit: fix double close(2) that can close a wrong file descriptor
Kristian Høgsberg [Tue, 15 Jan 2008 20:00:02 +0000 (15:00 -0500)]
git-commit: fix double close(2) that can close a wrong file descriptor

The codepath to prepare index files for the temporary and next
index file was closing file descriptor it obtained from the
lockfile API by hand, without letting the API know that the fd
should not be doubly closed.

This is not usually a problem (except it may get EBADFD) but if
we opened another fd for an entirely unrelated purpose (say, an
fd used to mmap a packfile) between the time we close the fd to
the index file and the time we commit or rollback the lockfile
(causing it to also try closing the recorded fd), the lockfile
API will close an incorrect file descriptor that is still used
for an entirely unrelated purpose.

There's four close(fd) calls in prepare_index() and they're all
incorrect.  The open fd's are cleaned up in rollback_index_files() and
shouldn't be closed manually.  The patch below gets rid of the extra
close() calls and should fix the problem.

Signed-off-by: Junio C Hamano <>
13 years agohg-to-git: improve popen calls
Mark Drago [Tue, 15 Jan 2008 01:11:19 +0000 (20:11 -0500)]
hg-to-git: improve popen calls

This patch improves all of the popen calls in by specifying the
template 'hg log' should use instead of calling 'hg log' and grepping for the
desired data.

Signed-off-by: Mark Drago <>
Acked-by: Stelian Pop <>
Signed-off-by: Junio C Hamano <>
13 years agols-remote: add -t and -h options.
Miklos Vajna [Tue, 15 Jan 2008 20:34:54 +0000 (21:34 +0100)]
ls-remote: add -t and -h options.

These options are listed in the manpage (aliases for --tags/--heads) but they
were not handled.

Signed-off-by: Miklos Vajna <>
Signed-off-by: Junio C Hamano <>
13 years agoSquelch bogus progress output from git-rebase--interactive
Junio C Hamano [Tue, 15 Jan 2008 04:01:21 +0000 (20:01 -0800)]
Squelch bogus progress output from git-rebase--interactive

The command repeats "Rebasing (1/1)" many times even when
there is only one task remaining, because mark_action_done() is
called to skip comment and empty lines in the TODO file.

This should fix it.

Signed-off-by: Junio C Hamano <>
13 years agoAdd using merge subtree How-To
Miklos Vajna [Tue, 15 Jan 2008 00:35:02 +0000 (01:35 +0100)]
Add using merge subtree How-To

Signed-off-by: Miklos Vajna <>
Signed-off-by: Junio C Hamano <>
13 years agoFix git-rerere documentation
Junio C Hamano [Mon, 14 Jan 2008 23:10:38 +0000 (15:10 -0800)]
Fix git-rerere documentation

rerere.enabled is _not_ on by default.  The command is enabled if rr-cache
exists even when rerere.enabled is missing, and enabled or disabled by
explicitly setting the rerere.enabled variable.

13 years agoRevert "builtin-commit.c: remove useless check added by faulty cut and paste"
Junio C Hamano [Mon, 14 Jan 2008 21:54:24 +0000 (13:54 -0800)]
Revert "builtin-commit.c: remove useless check added by faulty cut and paste"

This reverts commit 16335fdd7ace78a8285ba25fd7a81177a48e7c9b.

We are calling overlay_tree_on_cache() which does use CE_UPDATE
flag to mark duplicated entries, which is the same as the
codepath in git-ls-files with its --with-tree option.

Because the pathname ce->name is given to path_list_insert()
which does not allow duplicates, there is no breakage either way
from the correctness point of view in this codepath, unlike the
one in ls-files.  But avoiding unnecessary processing with a
single bit check is certainly better.

13 years agoMake default pre-commit hook less noisy
Jean-Luc Herren [Mon, 14 Jan 2008 21:47:42 +0000 (22:47 +0100)]
Make default pre-commit hook less noisy

This hook thought to have found a conflict marker any time it saw
a 7-character combination of any of the characters '<>=' at the
beginning of a line, whereas it should only look for the *same*
character to appear repeatedly.

Also, restrict it to match exactly 7 times, to avoid matching the
underlining with '='-characters often used in documentation.

Signed-off-by: Jean-Luc Herren <>
Signed-off-by: Junio C Hamano <>
13 years agocvsimport: remove last use of repo-config from git standard tools
Dan McGee [Mon, 14 Jan 2008 04:51:10 +0000 (22:51 -0600)]
cvsimport: remove last use of repo-config from git standard tools

git cvsimport was the last tool to use repo-config instead of config. Update
it to use plain git config.

Signed-off-by: Dan McGee <>
Signed-off-by: Junio C Hamano <>
13 years agoRemove usage of git- (dash) commands from email hook
Dan McGee [Mon, 14 Jan 2008 04:51:01 +0000 (22:51 -0600)]
Remove usage of git- (dash) commands from email hook

Switch all git command calls to use the git (space) command format, and
remove the use of git-repo-config in place of git config.

Signed-off-by: Dan McGee <>
Signed-off-by: Junio C Hamano <>
13 years agobuiltin-commit.c: remove useless check added by faulty cut and paste
Junio C Hamano [Sun, 13 Jan 2008 10:38:46 +0000 (02:38 -0800)]
builtin-commit.c: remove useless check added by faulty cut and paste

2888605c649ccd423232161186d72c0e6c458a48 (builtin-commit: fix
partial-commit support) mindlessly cut and pasted from
builtin-ls-files.c, and included a part that was meant to
exclude redundant path after "ls-files --with-tree" overlayed
the HEAD commit on top of the index.  This logic does not apply
to what git-commit does and should not have been copied, even
though it would not hurt.

Signed-off-by: Junio C Hamano <>
13 years ago[PATCH] gitk: make Ctrl "+" really increase the font size
Johannes Schindelin [Fri, 11 Jan 2008 12:39:33 +0000 (12:39 +0000)]
[PATCH] gitk: make Ctrl "+" really increase the font size

Only Ctrl "=" was bound to increase the font size, probably because
English keyboards have the plus on the same key as the equal sign.
However, not the whole world is English, and at least with some
other keyboard layouts, Ctrl "+" did not work as documented.

Noticed by Stephan Hennig.

Signed-off-by: Johannes Schindelin <>
Signed-off-by: Paul Mackerras <>
13 years agoFix performance regression for partial commits
Linus Torvalds [Sun, 13 Jan 2008 08:30:56 +0000 (00:30 -0800)]
Fix performance regression for partial commits

When running "git commit paths" to create a partial commit, we
used to carefully build the temporary index so that we do not
lose the cached stat information.  The rewrite of the command in
C lost it by carelessly using read_tree().

This resurrects the earlier behaviour to keep the cached stat
information as much as possible by using one-tree merge logic.

Signed-off-by: Linus Torvalds <>
Signed-off-by: Junio C Hamano <>
13 years agogit-clean: fix off-by-one memory access when given no arguments
Jeff King [Sat, 12 Jan 2008 09:04:32 +0000 (04:04 -0500)]
git-clean: fix off-by-one memory access when given no arguments

The "seen" variable is used by match_pathspec, and must have
as many elements as there are in the given pathspec. We
create the pathspec either from the command line arguments
_or_ from just the current prefix.

Thus allocating "seen" based upon just argc is wrong, since
if argc == 0, then we still have one pathspec, the prefix,
but we don't allocate any space in "seen".

Signed-off-by: Jeff King <>
Tested-by: İsmail Dönmez <>
Signed-off-by: Junio C Hamano <>
13 years agogit-svn: handle leading/trailing whitespace from svnsync revprops
Eric Wong [Sat, 12 Jan 2008 07:13:55 +0000 (23:13 -0800)]
git-svn: handle leading/trailing whitespace from svnsync revprops

Repositories generated by svnsync cannot be relied on to have
properly set revprops without newlines in UUIDs and URLs.  There
may be broken versions of svnsync out there that append extra
newlines to UUIDs, or the revprops could've been changed by
repository administrators at any time, too.

At least one repository we've come across has an embedded
newline erroneously set in the svnsync-uuid prop.  This is bad
because the trailing newline is taken as another record by the library, and the wantarray detection causes tmp_config()
to return an array with an empty-but-existing second element.

We will now strip leading and trailing whitespace both before
setting and after reading the uuid and url for svnsync values.
We will also force tmp_config to return a single scalar when
reading existing values.

SVN UUIDs should never have whitespace in them, and SVN
repository URLs should be URI-escaped, so neither of those
values we ever see in git-svn should actually have whitespace
in them.

Thanks to Dennis Schridde for the bug report and Junio for
helping diagnose this.

Signed-off-by: Eric Wong <>
Signed-off-by: Junio C Hamano <>
13 years agoGIT 1.5.4-rc3 v1.5.4-rc3
Junio C Hamano [Sat, 12 Jan 2008 05:14:39 +0000 (21:14 -0800)]
GIT 1.5.4-rc3

Signed-off-by: Junio C Hamano <>
13 years agoRPM spec: include gitk message files.
Junio C Hamano [Sat, 12 Jan 2008 05:40:15 +0000 (21:40 -0800)]
RPM spec: include gitk message files.

Signed-off-by: Junio C Hamano <>
13 years agogit-relink.txt: describe more clearly how hard linking occurs
Brandon Casey [Fri, 11 Jan 2008 18:14:19 +0000 (12:14 -0600)]
git-relink.txt: describe more clearly how hard linking occurs

Signed-off-by: Brandon Casey <>
Signed-off-by: Junio C Hamano <>
13 years agoDocument some default values in config.txt
Michele Ballabio [Fri, 11 Jan 2008 21:11:13 +0000 (22:11 +0100)]
Document some default values in config.txt

This documents the default values of, gc.autopacklimit
fetch.unpacklimit, receive.unpacklimit and transfer.unpacklimit.

Signed-off-by: Michele Ballabio <>
Signed-off-by: Junio C Hamano <>
13 years agoMerge ../gitk
Junio C Hamano [Fri, 11 Jan 2008 08:51:30 +0000 (00:51 -0800)]
Merge ../gitk

* ../gitk:
  gitk: Update German translation.
  gitk: Fix typo in user message.
  gitk: Fix the Makefile to cope with systems lacking msgfmt

13 years agogitk: Update German translation.
Christian Stimming [Wed, 9 Jan 2008 21:21:58 +0000 (22:21 +0100)]
gitk: Update German translation.

Now 100% complete (163 strings).

Signed-off-by: Christian Stimming <>
Signed-off-by: Junio C Hamano <>
13 years agogitk: Fix typo in user message.
Christian Stimming [Wed, 9 Jan 2008 21:23:18 +0000 (22:23 +0100)]
gitk: Fix typo in user message.

Signed-off-by: Christian Stimming <>
Signed-off-by: Junio C Hamano <>
13 years agogitk: Fix the Makefile to cope with systems lacking msgfmt
Charles Bailey [Wed, 9 Jan 2008 14:31:09 +0000 (14:31 +0000)]
gitk: Fix the Makefile to cope with systems lacking msgfmt

The script and the .gitignore in the po directory have been
shamelessly copied from the current git-gui.  This enables the top
level "make NO_MSGFMT" to work consistently for git across the git-gui
and gitk sub-projects.

This is the same effective patch that has previously been posted as a
git.git patch which more succinctly described the copying of
po/.gitignore and po/ from git-gui.

Signed-off-by: Charles Bailey <>
Signed-off-by: Junio C Hamano <>
13 years agopack-objects: remove redundant and wrong call to deflateEnd()
Junio C Hamano [Fri, 11 Jan 2008 07:26:09 +0000 (23:26 -0800)]
pack-objects: remove redundant and wrong call to deflateEnd()

We somehow called deflateEnd() on a stream that we have called
deflateEnd() on already.

In fact, the second deflateEnd() has always been returning
Z_STREAM_ERROR.  We just never checked the error return from
that particular deflateEnd().

The first one returns 0 for success.  We might want to tighten
the check even more to check that.

Noticed by Marco.

Signed-off-by: Junio C Hamano <>
13 years agobundle, fast-import: detect write failure
Jim Meyering [Thu, 10 Jan 2008 08:54:25 +0000 (09:54 +0100)]
bundle, fast-import: detect write failure

I noticed some unchecked writes.  This fixes them.

* bundle.c (create_bundle): Die upon write failure.
* fast-import.c (keep_pack): Die upon write or close failure.

Signed-off-by: Jim Meyering <>
Signed-off-by: Junio C Hamano <>
13 years agoTrim leading / off of paths in git-svn prop_walk
Kevin Ballard [Wed, 9 Jan 2008 06:37:20 +0000 (01:37 -0500)]
Trim leading / off of paths in git-svn prop_walk

prop_walk adds a leading / to all subdirectory paths. Unfortunately
this causes a problem when the remote repo lives in a subdirectory itself,
as the leading / causes subsequent PROPFIND calls to be executed on
the wrong path. Trimming the / before calling the PROPFIND fixes this problem.

Signed-off-by: Kevin Ballard <>
Acked-by: Eric Wong <>
Signed-off-by: Junio C Hamano <>
13 years agoshortlog: mention the "-e" option in the usage
Johannes Schindelin [Wed, 9 Jan 2008 11:39:54 +0000 (11:39 +0000)]
shortlog: mention the "-e" option in the usage

Signed-off-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
13 years agoChange git-gc documentation to reflect gc.packrefs implementation.
Florian La Roche [Wed, 9 Jan 2008 16:05:16 +0000 (17:05 +0100)]
Change git-gc documentation to reflect gc.packrefs implementation.

56752391a8c0c591853b276e4fa0b45c34ced181 (Make "git gc" pack all
refs by default) changed the default of gc.packrefs to true, to
pack all refs by default in any repository.  IOW, the users need
to disable it explicitly if they want to by setting the config
variable, since 1.5.3.

However, we forgot to update the documentation.  This fixes it.

Signed-off-by: Florian La Roche <>
Signed-off-by: Junio C Hamano <>
13 years agorecv_sideband: Do not use ANSI escape sequence on dumb terminals.
Johannes Sixt [Tue, 8 Jan 2008 16:24:53 +0000 (17:24 +0100)]
recv_sideband: Do not use ANSI escape sequence on dumb terminals.

The "clear to end of line" sequence is used to nicely output the progress
indicator without leaving garbage on the terminal. However, this works
only on ANSI capable terminals. We use the same check as in color.c to
find out whether the terminal supports this feature and use a workaround
(a few spaces in a row) if it does not.

[jc: as an old fashoned git myself, and given the fact that the
possible prefix and suffix are small number of short constant strings,
I actually prefer a simpler-and-more-stupid approach.  This is with
Nico's clean-up.]

Signed-off-by: Johannes Sixt <>
Signed-off-by: Junio C Hamano <>
13 years agoMerge branch 'master' of git://
Junio C Hamano [Wed, 9 Jan 2008 06:41:15 +0000 (22:41 -0800)]
Merge branch 'master' of git://git./gitk/gitk

* 'master' of git://
  [PATCH] gitk: use user-configured background in view definition dialog
  [PATCH] gitk: Update German translation
  [PATCH] gitk: Update and fix Makefile
  gitk: Restore some widget options whose defaults changed in Tk 8.5
  gitk: Recode de.po to UTF-8
  [PATCH] gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright character is valid utf8.
  [PATCH] gitk i18n: More markup -- various options menus
  [PATCH] gitk i18n: Initial German translation
  [PATCH] gitk i18n: Markup several strings for translation
  [PATCH] gitk i18n: Import msgcat for message string translation; load translation catalogs
  [PATCH] gitk i18n: Add Makefile with rules for po file creation and installation

13 years ago[PATCH] gitk: use user-configured background in view definition dialog
Gerrit Pape [Wed, 9 Jan 2008 03:19:47 +0000 (14:19 +1100)]
[PATCH] gitk: use user-configured background in view definition dialog

Have the text fields in the view definition dialog (View->New view...)
use the background color as configured through the preferences, instead
of hard-coded 'white'.

This was suggested by Paul Wise through

Signed-off-by: Gerrit Pape <>
Signed-off-by: Paul Mackerras <>
13 years ago[PATCH] gitk: Update German translation
Christian Stimming [Wed, 9 Jan 2008 03:13:22 +0000 (14:13 +1100)]
[PATCH] gitk: Update German translation

Signed-off-by: Christian Stimming <>
Signed-off-by: Paul Mackerras <>
13 years ago[PATCH] gitk: Update and fix Makefile
Christian Stimming [Wed, 9 Jan 2008 03:12:18 +0000 (14:12 +1100)]
[PATCH] gitk: Update and fix Makefile

This Makefile uses the template provided at git.git/gitk-git/Makefile
by Junio and adds the rules for the i18n files.

Signed-off-by: Christian Stimming <>
Signed-off-by: Paul Mackerras <>
13 years agogit.el: Make status refresh faster.
Alexandre Julliard [Tue, 8 Jan 2008 13:49:09 +0000 (14:49 +0100)]
git.el: Make status refresh faster.

Don't set the needs-refresh flag when inserting a new file info, since
ewoc refreshes it upon insert already; this makes a full refresh twice
as fast.

Also make git-fileinfo-prettyprint a little faster by not retrieving
permission values twice.

Signed-off-by: Alexandre Julliard <>
Signed-off-by: Junio C Hamano <>
13 years agogit.el: Refresh files from their real state upon commit.
Alexandre Julliard [Tue, 8 Jan 2008 13:46:22 +0000 (14:46 +0100)]
git.el: Refresh files from their real state upon commit.

Instead of just setting the state to up-to-date, retrieve the full
state again, so that the file type can be displayed properly.

Signed-off-by: Alexandre Julliard <>
Signed-off-by: Junio C Hamano <>