remote: let guess_remote_head() optionally return all matches
Determining HEAD is ambiguous since it is done by comparing SHA1s.
In the case of multiple matches we return refs/heads/master if it
matches, else we return the first match we encounter. builtin-remote
needs all matches returned to it, so add a flag for it to request such.
To be simple and consistent, the return value is now a copy (including
peer_ref) of the matching refs.
Originally contributed by Jeff King along with the prior commit as a
single patch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
To ensure that copied refs can always be freed w/o causing a
double-free, make copy_ref() perform a deep copy.
Also have copy_ref() return NULL if asked to copy NULL to simplify
things for the caller.
Background: currently copy_ref() performs a shallow copy. This is fine
for current callers who never free the result and/or only copy refs
which contain NULL pointers. But copy_ref() is about to gain a new
caller (guess_remote_head()) which copies refs where peer_ref is not
NULL and the caller of guess_remote_head() will want to free the result.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there is nothing to be skipped, the output from
rev-list --bisect-vars was eval'ed without first being
strung together with &&; this is probably not a problem
as it is much less likely to be a bad input than the list
handcrafted by the filter_skip function, but it still is
a good discipline.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped
When the "bad" commit was also "skip"ped and when more than one
commit was skipped, the "filter_skipped" function would have
printed something like:
bisect_rev=<hash1>|<hash2>
(where <hash1> and <hash2> are hexadecimal sha1 hashes)
and this would have been evaled later as piping "bisect_rev=<hash1>"
into "<hash2>", which would have failed.
So this patch makes the "filter_skipped" function properly quote
what it outputs, so that it will print something like:
bisect_rev='<hash1>|<hash2>'
which will be properly evaled later. The caller was not stopping
properly because the scriptlet this function returned to be evaled
was not strung together with && and because of this, an error in
an earlier part of the output was simply ignored.
A test case is added to the test suite.
And while at it, we also initialize the VARS, FOUND and TRIED
variables, so that we protect ourselves from environment variables
the user may have with these names.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you are in the middle of "git rebase", "git am --abort" by mistake
would have referred to nonexistent ORIG_HEAD and barfed, or worse yet, used
a stale ORIG_HEAD and taken you to an unexpected commit.
Also the option parsing did not reject "git am --abort --skip".
git-am: Keep index in case of abort with dirty index
git am --abort resets the index unconditionally. But in case a previous
git am exited due to a dirty index it is preferable to keep that index.
Make it so.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
OS X's GNU grep does not support -P/--perl-regexp.
We use a basic RE instead, and simplify the pattern slightly by
replacing '+' with '*' so it can be more easily expressed using a basic
RE. The important part of pattern, checking for a SHA-1 has suffix in
the successful PUT/MOVE operations, remains the same. Also, a-z instead
of a-f was an obvious mistake in the original RE. Here are samples of
what we want to match:
The AIX mkstemp() modifies its template parameter to an empty string if
the call fails. The existing code had already recomputed the template,
but too late to be good.
See also 6ff6af62, which fixed this problem in a different spot.
Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function had complications which made it hard to extend.
- It used to do two things: find the HEAD ref, and then find a
matching ref, optionally returning the former via assignment to a
passed-in pointer. Since finding HEAD is a one-liner, just have a
caller do it themselves and pass it as an argument.
- It used to manually search through the ref list for
refs/heads/master; this can be a one-line call to
find_ref_by_name.
Originally contributed by Jeff King along with the next commit as a
single patch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move locate_head() to remote.c and rename it to guess_remote_head() to
more accurately reflect what it does. This is in preparation for being
able to call it from builtin-remote.c
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ref_newer() appears to have been copied from builtin-send-pack.c to
http-push.c via cut and paste. This patch moves the function and its
helper unmark_and_free() to remote.c. There was a slight difference
between the two implementations, one used TMP_MARK for the mark, the
other used 1. Per Jeff King, I went with TMP_MARK as more correct.
This is in preparation for being able to call it from builtin-remote.c
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_local_heads() appears to have been copied from builtin-send-pack.c
to http-push.c via cut and paste. This patch moves the function and its
helper one_local_ref() to remote.c.
The two copies of one_local_ref() were not identical. I used the more
recent version from builtin-send-pack.c after confirming with Jeff King
that it was an oversight that commit 30affa1e did not update both
copies.
This is in preparation for being able to call it from builtin-remote.c
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since it doesn't actually touch its argument, this makes
sense.
However, we still want to return a non-const version (which
requires a cast) so that this:
struct ref *a, *b;
a = find_ref_by_name(b);
works. Unfortunately, you can also silently strip the const
from a variable:
struct ref *a;
const struct ref *b;
a = find_ref_by_name(b);
This is a classic C const problem because there is no way to
say "return the type with the same constness that was passed
to us"; we provide the same semantics as standard library
functions like strchr.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was mostly being tested implicitly by the "http push"
tests. But making a separate test script means that:
- we will run fetch tests even when http pushing support
is not built
- when there are failures on fetching, they are easier to
see and isolate, as they are not in the middle of push
tests
This script defaults to running the webserver on port 5550,
and puts the original t5540 on port 5540, so that the two
can be run simultaneously without conflict (but both still
respect an externally set LIB_HTTPD_PORT).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are some redirects and some error checking that need
to be done by the caller; let's move both into the
start_httpd function so that all callers don't have to
repeat them (there is only one caller now, but another will
follow in this series).
This doesn't violate any assumptions that aren't already
being made by lib-httpd, which is happy to say "skipping"
and call test_done for a number of other cases.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure objects/pack exists before creating a new pack
In a repository created with git older than f49fb35 (git-init-db: create
"pack" subdirectory under objects, 2005-06-27), objects/pack/ directory is
not created upon initialization. It was Ok because subdirectories are
created as needed inside directories init-db creates, and back then,
packfiles were recent invention.
After the said commit, new codepaths started relying on the presense of
objects/pack/ directory in the repository. This was exacerbated with 8b4eb6b (Do not perform cross-directory renames when creating packs,
2008-09-22) that moved the location temporary pack files are created from
objects/ directory to objects/pack/ directory, because moving temporary to
the final location was done carefully with lazy leading directory creation.
Many packfile related operations in such an old repository can fail
mysteriously because of this.
This commit introduces two helper functions to make things work better.
- odb_mkstemp() is a specialized version of mkstemp() to refactor the
code and teach it to create leading directories as needed;
- odb_pack_keep() refactors the code to create a ".keep" file while
create leading directories as needed.
This patch allows the HTTP tests to run on OS X 10.5. It is not
sufficient to be able to pass in LIB_HTTPD_PATH and
LIB_HTTPD_MODULE_PATH alone, as the apache.conf also needs a couple
tweaks.
These changes are put into an <IfDefine> to keep them Darwin specific,
but this means lib-httpd.sh needs to be modified to pass -DDarwin to
apache when running on Darwin. As long as we're making this change to
lib-httpd.sh, we may as well set LIB_HTTPD_PATH and
LIB_HTTPD_MODULE_PATH to appropriate default values for the platform.
Note that we now pass HTTPD_PARA to apache at shutdown as well.
Otherwise apache will emit a harmless, but noisy warning that LogFormat
is an unknown directive.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitattributes.txt: Path matching rules are explained in gitignore.txt
The rules how the patterns are matched against path names are the same
for .gitattribute and .gitignore files.
This also replace the notion "glob pattern" by "pattern" because
gitignore.txt talks about "glob" only in some contexts where the pattern
is mentioned.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
README: fix path to "gitcvs-migration.txt" and be more consistent
README suggested to look at "Documentation/gittutorial.txt" for the
tutorial and to use "man git-commandname" for documentation of each
command.
This was not consistent because the tutorial can also be available with
"man gittutorial" once git is installed, and the documentation for each
command can be available at "Documentation/git-commandname.txt" before
installing git.
This patch tries to make the description more consistent. It also fixes
the path to the cvs-migration documentation that changed from
"Documentation/cvs-migration.txt" to "Documentation/gitcvs-migration.txt".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-quiltimport: preserve standard input to be able to read user input
When run without --author and it fails to determine an author, git
quiltimport tries `read patch_author` to get user input, but standard
input has been redirected to the patch series file. This commit lets
quiltimport read the series file through file descriptor 3 so that the
standard input is preserved.
Reported by Uwe Kleine-König through http://bugs.debian.org/515910
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some people prefer to call the pretty-print styles "format", and get
annoyed to see "git log --format=short" fail. Introduce it as a synonym
to --pretty so that both can be used.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Install builtins with the user and group of the installing personality
If 'make install' was run with sufficient privileges, then the installed
builtins in gitexecdir, which are either hardlinked, symlinked, or copied,
would receive the user and group of whoever built git. With this commit
the initial hardlink or copy is done from the installation tree and not
the build tree to fix this.
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fixup: Add bare repository indicator for __git_ps1
Signed-off-by: Marius Storm-Olsen <git@storm-olsen.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: don't create temporary compose file until it is needed
Commit eed6ca7 caused a minor regression when it switched to using
tempfile() to generate the temporary compose file. Since tempfile()
creates the file at the time it generates the filename, zero-length
temporary files are being left behind unless --compose is used (in which
case the file is cleaned up).
This patch fixes the regression by not calling tempfile() to generate
the compose filename unless --compose is in use.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: read the dcommit url from the config file on a per remote basis
git-svn: fix delete+add branch tracking with empty files
git-svn: Create leading directories in create-ignore
write_index(): update index_state->timestamp after flushing to disk
Since this timestamp is used to check for racy-clean files, it is
important to keep it uptodate.
For the 'git checkout' command without the '-q' option, this make a
huge difference. Before, each and every file which was updated, was
racy-clean after the call to unpack_trees() and write_index() but
before the GIT process ended.
And because of the call to show_local_changes() in builtin-checkout.c,
we ended up reading those files back into memory, doing a SHA1 to
check if the files was really different from the index. And, of
course, no file was different.
With this fix, 'git checkout' without the '-q' option should now be
almost as fast as with the '-q' option, but not quite, as we still do
some few lstat(2) calls more without the '-q' option.
Below is some average numbers for 10 checkout's to v2.6.27 and 10 to
v2.6.25 of the Linux kernel, to show the difference:
before (git version 1.6.2.rc1.256.g58a87):
7.860 user 2.427 sys 19.465 real 52.8% CPU faults: 0 major 95331 minor
after:
6.184 user 2.160 sys 17.619 real 47.4% CPU faults: 0 major 38994 minor
Signed-off-by: Kjetil Barvik <barvik@broadpark.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a particular changeset affects multiple depot paths, it
will appear multiple times in the output of "p4 changes".
Filter out the duplicates to avoid the extra empty commits that
this otherwise would create.
Signed-off-by: Pete Wyckoff <pw@padd.com> Acked-by: Simon Hausmann <simon@lst.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prefixes the branch name with "BARE:" if you're in a
bare repository.
Signed-off-by: Marius Storm-Olsen <git@storm-olsen.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: read the dcommit url from the config file on a per remote basis
The commit url for dcommit is determined in the following order:
commandline option --commit-url
svn.commiturl
svn-remote.<name>.commiturl
svn-remote.<name>.url
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de> Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: fix delete+add branch tracking with empty files
Original bug report and test case by Björn Steinbrink.
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Hi Eric,
>
> seems that the empty symlink stuff gets confused about which revision to
> use when looking for the parent's file.
>
> r3 = f1a6fcf6b0a1c4a373d0b2b65a3d70700084f361 (tags/1.0.1)
> Found possible branch point: file:///home/doener/h/svn/tags/1.0 => file:///home/doener/h/svn/branches/1.0, 4
> Found branch parent: (1.0) 63ae640ba01014ecbb3df590999ed1fa5914545b
> Following parent with do_switch
> Successfully followed parent
> r5 = 26fcfef5bcced97ab74faf1af7341a2ae0d272aa (1.0)
> Found possible branch point: file:///home/doener/h/svn/branches/1.0 => file:///home/doener/h/svn/tags/1.0.1, 5
> Found branch parent: (tags/1.0.1) 26fcfef5bcced97ab74faf1af7341a2ae0d272aa
> Following parent with do_switch
> Scanning for empty symlinks, this may take a while if you have many empty files
> You may disable this with `git config svn.brokenSymlinkWorkaround false'.
> This may be done in a different terminal without restarting git svn
> Filesystem has no item: File not found: revision 3, path '/branches/1.0/file' at /usr/local/libexec/git-core/git-svn line 3318
>
> Note how it tries to look at revision 3 instead of revision 5 (which it
> correctly detected as the parent). The import succeeds when
> svn.brokenSymlinkWorkaround is set to false. Testcase below.
For deep threading mode, i.e., the mode that gives a thread structured
like
+ [PATCH 0/n] Cover letter
`-+ [PATCH 1/n] First patch
`-+ [PATCH 2/n] Second patch
`-+ ...
we currently have to use 'git send-email --thread' (the default). On
the other hand, format-patch also has a --thread option which gives
shallow mode, i.e.,
+ [PATCH 0/n] Cover letter
|-+ [PATCH 1/n] First patch
|-+ [PATCH 2/n] Second patch
...
To reduce the confusion resulting from having two indentically named
features in different tools giving different results, let format-patch
take an optional argument '--thread=deep' that gives the same output
as 'send-mail --thread'. With no argument, or 'shallow', behave as
before. Also add a configuration variable format.thread with the same
semantics.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch: thread as reply to cover letter even with in-reply-to
Currently, format-patch --thread --cover-letter --in-reply-to $parent
makes all mails, including the cover letter, a reply to $parent.
However, we would want the reader to consider the cover letter above
all the patches.
This changes the semantics so that only the cover letter is a reply to
$parent, while all the patches are formatted as replies to the cover
letter.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, format-patch can only track a single reference (the
In-Reply-To:) for each mail. To ensure proper threading, we should
list all known references for every mail.
Change the rev_info.ref_message_id field to a string_list, so that we
can append references at will, and change the output formatting
routines to print all of them in the References: header. The last
entry in the list is implicitly assumed to be the In-Reply-To:, which
gives output consistent with RFC 2822:
The "References:" field will contain the contents of the parent's
"References:" field (if any) followed by the contents of the
parent's "Message-ID:" field (if any).
Note that this is just preparatory work; nothing uses it yet, so all
"References:" fields in the output are still only one deep.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'for-junio' of git://source.winehq.org/~julliard/git/git
* 'for-junio' of git://source.winehq.org/~julliard/git/git:
Add a README in the contrib/emacs directory.
git.el: Improve the confirmation message on remove and revert.
git.el: Make sure that file lists are sorted as they are created.
git.el: Make sure that file lists are sorted as they are created.
This avoids a possibly redundant sort in git-update-status-files and
git-status-filenames-map, and allows callers to continue using the
list without having to copy it.
It also fixes the confusing success messages reported by Brent
Goodrick.
Talking about --date, one thing I wanted for the 1234567890 date was to
get things in the raw format. Sure, you get them with --pretty=raw, but it
felt a bit sad that you couldn't just ask for the date in raw format.
So here's a throw-away patch (meaning: I won't be re-sending it, because I
really don't think it's a big deal) to add "--date=raw". It just prints
out the internal raw git format - seconds since epoch plus timezone (put
another way: 'date +"%s %z"' format)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-fsck, of all tools, has very few tests. This adds some more:
* a corrupted object;
* a branch pointing to a non-commit;
* a tag pointing to a nonexistent object;
* and a tag pointing to an object of a type other than what the tag
itself claims.
Only the first two are caught. At least the third probably should,
too, but currently slips through.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
With gcc's --coverage option, we can perform automatic coverage data
collection for the test suite.
Add a new Makefile target 'coverage' that scraps all previous coverage
results, recompiles git with the required compiler/linker flags (in
addition to any flags you specify manually), then runs the test suite
and compiles a report.
The compilation must be done with all optimizations disabled, since
inlined functions (and for line-by-line coverage, also optimized
branches/loops) break coverage tracking.
The tests are run serially (with -j1). The coverage code should
theoretically allow concurrent access to its data files, but the
author saw random test failures. Obviously this could be improved.
The report currently consists of a list of functions that were never
executed during the tests, which is written to
'coverage-untested-functions'. Once this list becomes reasonably
short, we would also want to look at branches that were never taken.
Currently only toplevel *.c files are considered. It would be nice to
at least include xdiff, but --coverage did not save data to
subdirectories on the system used to write this (gcc 4.3.2).
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
More friendly message when locking the index fails.
Just saying that index.lock exists doesn't tell the user _what_ to do
to fix the problem. We should give an indication that it's normally
safe to delete index.lock after making sure git isn't running here.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Hyperlink multiple git hashes on the same commit message line
The current implementation only hyperlinks the first hash on
a given line of the commit message. It seems sensible to
highlight all of them if there are multiple, and it seems
plausible that there would be multiple even with a tidy line
length limit, because they can be abbreviated as short as 8
characters.
Benchmark:
I wanted to make sure that using the 'e' switch to the Perl regex
wasn't going to kill performance, since this is called once per commit
message line displayed.
In all three A/B scenarios I tried, the A and B yielded the same
results within 2%, where A is the version of code before this patch
and B is the version after.
1: View a commit message containing the last 1000 commit hashes
2: View a commit message containing 1000 lines of 40 dots to avoid
hyperlinking at the same message length
3: View a short merge commit message with a few lines of text and
no hashes
All were run in CGI mode on my sub-production hardware on a recent
clone of git.git. Numbers are the average of 10 reqests per second
with the first request discarded, since I expect this change to affect
primarily CPU usage. Measured with ApacheBench.
Note that the web page rendered was the same; while the new code
supports multiple hashes per line, there was at most one per line.
The primary purpose of scenarios 2 and 3 were to verify that the
addition of 1000 commit messages had an impact on how much of the time
was spent rendering commit messages. They were all within 2% of 0.80
requests per second (much faster).
So I think the patch has no noticeable effect on performance.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
system_path(): simplify using strip_path_suffix(), and add suffix "git"
At least for the author of this patch, the logic in system_path() was
too hard to understand. Using the function strip_path_suffix() documents
the idea of the code better.
The real change is to add the suffix "git", so that a runtime prefix will
be computed correctly even when the executable was called in /git/ as is
the case in msysGit (Windows insists to search the current directory
before the PATH when looking for an executable).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function strip_path_suffix() will try to strip a given suffix from
a given path. The suffix must start at a directory boundary (i.e. "core"
is not a path suffix of "libexec/git-core", but "git-core" is).
Arbitrary runs of directory separators ("slashes") are assumed identical.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4014 tests format-patch --thread since 7d812145, but the tests were
ineffective right from the start at least for bash and dash. The
loops of the form
for ...; do something || break; done
introduced by 7d812145 and 5d02294 always exit with status 0, even if
'something' failed, because 'break' returns 0 unless there was no loop
to break.
We take a rather different approach that uses an admittedly heinous
inline Perl script to mangle all interesting information into a format
that is invariant between runs. We can then test the full patch
sequence in one go (with --stdout), doing away with the loop problem.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we inside verify_uptodate() can already tell from the ce entry that
it is already uptodate by testing it with ce_uptodate(ce), there is no
need to call lstat(2) and ie_match_stat() afterwards.
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
'struct cache' does not have a 'usec' member, but a 'unsigned int
nsec' member. Simmilar 'struct stat' does not have a 'st_mtim.usec'
member, and we should instead use 'st_mtim.tv_nsec'.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We were not testing the output of "git branch" anywhere.
Not only does this not protect us against regressions in the
output, but we are not exercising code paths which may have
bugs (such as the one fixed by 45e2b61).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 45e2b61 fixed the initialization of a "len" struct
parameter via strlen. We can use that to clean up what is
now 3 strlens in a 6-line sequence.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Notice the memmove line, where the CPU did 7710 / 277 = 27.8 cycles
per instruction, and compared to the total cycles spent inside the
source code of GIT for this command, all the memmove() calls
translates to (7710 * 100) / 14775 = 52.2% of this.
Retesting with a GIT program compiled for gcov usage, I found out that
the memmove() calls came from remove_index_entry_at() in read-cache.c,
where we have:
remove_index_entry_at() is called 4902 times from check_updates() in
unpack-trees.c, and each time called we move each cache_entry pointers
(from the removed one) one step to the left.
Since we have 28828 entries in the cache this time, and if we on
average move half of them each time, we in total move approximately
4902 * 0.5 * 28828 * 4 = 282 629 712 bytes, or twice this amount if
each pointer is 8 bytes (64 bit).
OK, is seems that the function check_updates() is called 28 times, so
the estimated guess above had been more correct if check_updates() had
been called only once, but the point is: we get lots of bytes moved.
To fix this, and use an O(N) algorithm instead, where N is the number
of cache_entries, we delete/remove all entries in one loop through all
entries.
From a retest, the new remove_marked_cache_entries() from the patch
below, ended up with the following output line from oprofile:
If we can trust the numbers from oprofile in this case, we saved
approximately ((7710 - 46) * 20000) / (2 * 1000 * 1000 * 1000) = 0.077
seconds CPU time with this fix for this particular test. And notice
that now the CPU did only 46 / 15 = 3.1 cycles/instruction.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
tests: fix "export var=val"
Skip timestamp differences for diff --no-index
Documentation/git-push: --all, --mirror, --tags can not be combined
The improved error handling catches a bug in filter-branch when using
-d pointing to a path outside any git repository:
$ git filter-branch -d /tmp/foo master
fatal: Not a git repository (or any of the parent directories): .git
This error message comes from git for-each-ref in line 224. GIT_DIR is
set correctly by git-sh-setup (to the foo.git repository), but not
exported (yet).
Signed-off-by: Lars Noschinski <lars@public.noschinski.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We display empty diffs for files whose timestamps have changed.
Usually, refreshing the index makes those empty diffs go away.
However, when not using the index they are not very useful and
there is no option to suppress them.
This forces on the skip_stat_unmatch option for diff --no-index,
suppressing any empty diffs. This option is also used for diffs
against the index when "diff.autorefreshindex" is set, but that
option does not apply to diff --no-index.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix parsing of timestamp obtained from svn
Ward Wouts reports that git-svn barfed like this:
Unable to parse date: 2004-03-09T09:44:33.Z at /usr/bin/git-svn line 3995
The parse_svn_date sub expects there always are one or more digits after
the decimal point to record fractional seconds, but this example does not
and results in a failure like this.
The fix is based on the original fix by the reporter, further cleaned up.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Eric Wong <normalperson@yhbt.net>
gitweb: Fix warnings with override permitted but no repo override
When a feature like "blame" is permitted to be overridden in the
repository configuration but it is not actually set in the repository,
a warning is emitted due to the undefined value of the repository
configuration, even though it's a perfectly normal condition.
Emitting warning is grounds for test failure in the gitweb test
script.
This error was caused by rewrite of git_get_project_config from using
"git config [<type>] <name>" for each individual configuration
variable checked to parsing "git config --list --null" output in
commit b201927 (gitweb: Read repo config using 'git config -z -l').
Earlier version of git_get_project_config was returning empty string
if variable do not exist in config; newer version is meant to return
undef in this case, therefore change in feature_bool was needed.
Additionally config_to_* subroutines were meant to be invoked only if
configuration variable exists; therefore we added early return to
git_get_project_config: it now returns no value if variable does not
exists in config. Otherwise config_to_* subroutines (config_to_bool
in paryicular) wouldn't be able to distinguish between the case where
variable does not exist and the case where variable doesn't have value
(the "[section] noval" case, which evaluates to true for boolean).
While at it fix bug in config_to_bool, where checking if $val is
defined (if config variable has value) was done _after_ stripping
leading and trailing whitespace, which lead to 'Use of uninitialized
value' warning.
Add test case for features overridable but not overriden in repo
config, and case for no value boolean configuration variable.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash completion: refactor common log, shortlog and gitk options
Refactor options that are useful for more than one of them into a
variable used by the relevant completions. This has the effect of
adding the following options to git-log:
gitweb: fix wrong base URL when non-root DirectoryIndex
CGI::url() has some issues when rebuilding the script URL if the script
is a DirectoryIndex.
One of these issue is the inability to strip PATH_INFO, which is why
we had to do it ourselves.
Another issue is that the resulting URL cannot be used for the <base>
tag: it works if we're the DirectoryIndex at the root level, but not
otherwise.
We fix this by building the proper base URL ourselves, and improve the
comment about the need to strip PATH_INFO manually while we're at it.
Additionally t/t9500-gitweb-standalone-no-errors.sh had to be modified
to set SCRIPT_NAME variable (CGI standard states that it MUST be set,
and now gitweb uses it if PATH_INFO is not empty, as is the case for
some of tests in t9500).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
One might wonder why add options that specify the default behaviour
anyway (e.g. '--commit', '--no-squash', etc.). Users can override the
default with config options (e.g. 'branch.<name>.mergeoptions',
'merge.log'), but sometimes might still need the default behaviour.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: Fix for rewriteRoot URL containing username.
If the new svn root URL given with the svn-remote.<repo>.rewriteRoot config option
(or by the --rewrite-root option to 'git svn init') contains a username
(such as 'svn+ssh://username@example.com/repo'), find_by_url() cannot find
the repository URL, because the URL contained in the commit message does have
the username removed.
Signed-off-by: Dévai Tamás <devait@mailbox.sk> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-receive-pack.c: fix compiler warnings about format string
While all of the strings passed to warning() are, in fact, literals, the
compiler doesn't recognize them as such because it doesn't see through
the loop used to iterate over them:
builtin-receive-pack.c: In function 'warn_unconfigured_deny':
builtin-receive-pack.c:247: warning: format not a string literal and no format arguments
builtin-receive-pack.c: In function 'warn_unconfigured_deny_delete_current':
builtin-receive-pack.c:273: warning: format not a string literal and no format arguments
Calm the compiler by adding easily recognizable format string literals.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ms/mailmap:
Move mailmap documentation into separate file
Change current mailmap usage to do matching on both name and email of author/committer.
Add map_user() and clear_mailmap() to mailmap
Add find_insert_index, insert_at_index and clear_func functions to string_list
Add mailmap.file as configurational option for mailmap location