Johan Herland [Mon, 11 Feb 2008 23:43:41 +0000 (00:43 +0100)]
Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR
When using the '-w $cvsdir' option to cvsexportcommit, it will chdir into
$cvsdir before executing several other git commands. If $GIT_DIR is set to
a relative path (e.g. '.'), the git commands executed by cvsexportcommit
will naturally fail.
Therefore, ensure that $GIT_DIR is absolute before the chdir to $cvsdir.
Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 12 Feb 2008 00:46:20 +0000 (16:46 -0800)]
Merge branch 'lt/in-core-index'
* lt/in-core-index:
lazy index hashing
Create pathname-based hash-table lookup into index
read-cache.c: introduce is_racy_timestamp() helper
read-cache.c: fix a couple more CE_REMOVE conversion
Also use unpack_trees() in do_diff_cache()
Make run_diff_index() use unpack_trees(), not read_tree()
Avoid running lstat(2) on the same cache entry.
index: be careful when handling long names
Make on-disk index representation separate from in-core one
Junichi Uekawa [Mon, 11 Feb 2008 15:00:07 +0000 (00:00 +0900)]
git-blame.el: show the when, who and what in the minibuffer.
Change the default operation to show 'when (day the commit was made),
who (who made the commit), what (what the commit log was)' in the
minibuffer instead of SHA1 and title of the commit log.
Since the user may prefer other displaying options, it is made as a
user-configurable option.
Junio C Hamano [Mon, 11 Feb 2008 03:34:34 +0000 (19:34 -0800)]
Define the project whitespace policy
This establishes what the "bad" whitespaces are for this
project.
The rules are:
- Unless otherwise specified, indent with SP that could be
replaced with HT are not "bad". But SP before HT in the
indent is "bad", and trailing whitespaces are "bad".
- For C source files, initial indent by SP that can be replaced
with HT is also "bad".
- Test scripts in t/ and test vectors in its subdirectories can
contain anything, so we make it unrestricted for now.
Anything "bad" will be shown in WHITESPACE error indicator in
diff output, and "apply --whitespace=warn" will warn about it.
Junio C Hamano [Mon, 11 Feb 2008 18:41:18 +0000 (10:41 -0800)]
Add config_error_nonbool() helper function
This is used to report misconfigured configuration file that does not
give any value to a non-boolean variable, e.g.
[section]
var
It is perfectly fine to say it if the section.var is a boolean (it means
true), but if a variable expects a string value it should be flagged as
a configuration error.
Mike Hommey [Sat, 9 Feb 2008 09:41:36 +0000 (10:41 +0100)]
Work around curl-gnutls not liking to be reinitialized
curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.
We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).
While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonas Fonseca [Mon, 4 Feb 2008 22:01:20 +0000 (23:01 +0100)]
man pages are littered with .ft C and others
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
Gerrit Pape [Fri, 8 Feb 2008 09:53:58 +0000 (09:53 +0000)]
builtin-commit: remove .git/SQUASH_MSG upon successful commit
After doing a merge --squash, and commit afterwards, the commit message
template SQUASH_MSG in the git directory is not removed, which means that
the content of SQUASH_MSG is used as default commit message for all
subsequent commits. So have git commit remove the file SQUASH_MSG from
the git directory upon a successful commit.
The problem was discovered by Frédéric Brière, reported through
http://bugs.debian.org/464656
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git prune remove temporary packs that look like write failures
Write errors when repacking (eg, due to out-of-space conditions)
can leave temporary packs (and possibly other files beginning
with "tmp_") lying around which no existing
codepath removes and which aren't obvious to the casual user.
These can also be multi-megabyte files wasting noticeable space.
Unfortunately there's no way to definitely tell in builtin-prune
that a tmp_ file is not being used by a concurrent process,
such as a fetch. However, it is documented that pruning should
only be done on a quiet repository and --expire is honoured
(using code from Johannes Schindelin, along with a test case
he wrote) so that its safety is the same as that of loose
object pruning.
Since they might be signs of a problem (unlike orphaned loose
objects) the names of any removed files are printed.
Signed-off-by: David Tweed (david.tweed@gmail.com) Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that the default of branch.autosetupmerge is true
In 34a3e69 (git-branch: default to --track) the default was changed to
true, to help new git users. But yours truly forgot to update the
documentation. This fixes it.
Noticed by Kalle Olavi Niemitalo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_beginning_of_line didn't take into account that the
previous line might have ended with \ in which case it shouldn't
stop but continue its search.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mike Hommey [Sat, 9 Feb 2008 09:41:36 +0000 (10:41 +0100)]
Work around curl-gnutls not liking to be reinitialized
curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.
We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).
While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git pack-objects" has the option --max-pack-size to limit the file
size of the packs to a certain amount of bytes. On platforms where
the pack file size is limited by filesystem constraints, it is easy
to forget this option, and this option does not exist for "git gc"
to begin with.
So introduce a config variable to set the default maximum, but make
this overrideable by the command line.
Suggested by Tor Arvid Lund.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In ba227857(Reduce the number of connects when fetching), we checked
the return value of git_connect() to see if the connection was
successful.
However, for the git:// protocol, there is no need to have another
process, so the return value was NULL.
Now, it makes sense to assume the rule that git_connect() will return
NULL if it fails (at the moment, it die()s if it fails), so return
a dummy child process.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refuse to revert a file if it is modified in an existing buffer but
not saved. On success, revert the buffers that contains the files that
have been reverted.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git.el: Support for showing unknown/ignored directories.
Instead of recursing into directories that only contain unknown files,
display only the directory itself. Its contents can be expanded with
git-find-file (bound to C-m).
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 7 Feb 2008 08:02:08 +0000 (00:02 -0800)]
gitattributes: fix relative path matching
There was an embarrassing pair of off-by-one miscounting that
failed to match path "a/b/c" when "a/.gitattributes" tried to
name it with relative path "b/c".
Robin Rosenberg [Sun, 30 Sep 2007 00:20:45 +0000 (02:20 +0200)]
Improve bash prompt to detect various states like an unfinished merge
This patch makes the git prompt (when enabled) show if a merge or a
rebase is unfinished. It also detects if a bisect is being done as
well as detached checkouts.
An uncompleted git-am cannot be distinguised from a rebase (the
non-interactive version). Instead of having an even longer prompt
we simply ignore that and hope the power users that use git-am knows
the difference.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Acked-by: Shawn O. Pearce <spearce@spearce.org>
gitweb: Make feed entries point to commitdiff view
Change feeds entries (feeds items) from pointing (linking) to 'commit'
view to pointing to 'commitdiff' view.
First, feed entries have whatchanged-like list of files which were
modified in a commit, so 'commitdiff' view more naturally reflects
feed entry (is more naturally alternate / extended version of a feed
item). Second, this way the patches are shown directly and code review
is done more easily via watching feeds.
[jn: Rewritten commit message]
Signed-off-by: Florian La Roche <laroche@redhat.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Eric Wong [Tue, 29 Jan 2008 09:18:58 +0000 (01:18 -0800)]
git-svn: improve repository URL matching when following parents
This way we can avoid the spawning of a new SVN::Ra session by
reusing the existing one.
The most problematic issue is that some svn servers disallow
too many connections from a single IP, so this will allow
git-svn to fetch from those repositories with a higher success
rate by using fewer connections.
This sometimes showed up as a new (and redundant)
[svn-remote "$parent_refname"] entry in $GIT_DIR/svn/.metadata.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
I was looking at some of the perl commands, and noticed that
git-remote was the only one to lack a 'use strict' pragma at the top,
which could be a good thing for its maintainability. Hopefully, the
required changes are minimal.
Signed-off-by: Rafael Garcia-Suarez <rgarciasuarez@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Tue, 5 Feb 2008 08:17:33 +0000 (09:17 +0100)]
Fix misuse of prefix_path()
When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path,
init-db made it relative to exec_path using prefix_path(), which
is wrong. prefix_path() is about a file inside the work tree.
There was a similar misuse in config.c that takes relative
ETC_GITCONFIG path. Noticed by Junio C Hamano.
We concatenate the paths manually. (prefix_filename() won't do
because it expects a prefix with a trailing '/'.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few options to git-send-email to suppress the automatic
generation of 'Cc' fields: --suppress-from, and --signed-off-cc.
However, there are other times that git-send-email automatically
includes Cc'd recipients. This is not desirable for all development
environments.
Add a new option --suppress-cc, which can be specified one or more
times to list the categories of auto-cc fields that should be
suppressed. If not specified, it defaults to values to give the same
behavior as specified by --suppress-from, and --signed-off-cc. The
categories are:
self - patch sender. Same as --suppress-from.
author - patch author.
cc - cc lines mentioned in the patch.
cccmd - avoid running the cccmd.
sob - signed off by lines.
all - all non-explicit recipients
Signed-off-by: David Brown <git@davidb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Daniel Barkalow [Mon, 4 Feb 2008 18:26:23 +0000 (13:26 -0500)]
Reduce the number of connects when fetching
This shares the connection between getting the remote ref list and
getting objects in the first batch. (A second connection is still used
to follow tags).
When we do not fetch objects (i.e. either ls-remote disconnects after
getting list of refs, or we decide we are already up-to-date), we
clean up the connection properly; otherwise the connection is left
open in need of cleaning up to avoid getting an error message from
the remote end when ssh is used.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 11 Jan 2008 06:49:35 +0000 (22:49 -0800)]
Make error messages from cherry-pick/revert more sensible
The original "rewrite in C" did somewhat a sloppy job while
stealing code from git-write-tree.
The caller pretends as if the write_tree() function would return
an error code and being able to issue a sensible error message
itself, but write_tree() function just calls die() and never
returns an error. Worse yet, the function claims that it was
running git-write-tree (which is no longer true after
cherry-pick stole it).
Tested-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Witten [Mon, 4 Feb 2008 00:53:57 +0000 (19:53 -0500)]
git-send-email: SIG{TERM,INT} handlers
A single signal handler is used for both SIGTERM and
SIGINT in order to clean up after an uncouth termination
of git-send-email.
In particular, the handler resets the text color (this cleanup
was already present), turns on tty echoing (in case termination
occurrs during a masked Password prompt), and informs the user
of of any temporary files created by --compose.
Signed-off-by: Michael Witten <mfwitten@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Witten [Mon, 4 Feb 2008 00:53:56 +0000 (19:53 -0500)]
git-send-email: ssh/login style password requests
Whilst convenient, it is most unwise to record passwords
in any place but one's brain. Moreover, it is especially
foolish to store them in configuration files, even with
access permissions set accordingly.
git-send-email has been amended, so that if it detects
an smtp username without a password, it promptly prompts
for the password and masks the input for privacy.
Furthermore, the argument to --smtp-pass has been rendered
optional.
The documentation has been updated to reflect these changes.
Signed-off-by: Michael Witten <mfwitten@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonas Fonseca [Mon, 4 Feb 2008 22:01:20 +0000 (23:01 +0100)]
man pages are littered with .ft C and others
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
Junio C Hamano [Mon, 4 Feb 2008 06:37:58 +0000 (22:37 -0800)]
fix misuse of prefix_path()
When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path,
init-db made it relative to exec_path using prefix_path(), which
is wrong. prefix_path() is about a file inside the work tree.
There was a similar misuse in config.c that takes relative
ETC_GITCONFIG path.
A convenience function prefix_filename() can concatenate two paths
to form a path that points at somewhere outside the work tree.
Use it in these codepaths instead.
Martin Koegler [Sun, 3 Feb 2008 21:22:39 +0000 (22:22 +0100)]
parse_object_buffer: don't ignore errors from the object specific parsing functions
In the case of an malformed object, the object specific parsing functions
would return an error, which is currently ignored. The object can be partial
initialized in this case.
This patch make parse_object_buffer propagate such errors.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Martin Koegler [Sun, 3 Feb 2008 21:22:37 +0000 (22:22 +0100)]
git-fsck: report missing author/commit line in a commit as an error
A zero commit date could be caused by:
* a missing author line
* a missing commiter line
* a malformed email address in the commiter line
* a malformed commit date
Simply reporting it as zero commit date is missleading.
Additionally, it upgrades the message to an error (instead of an printf).
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let "git svn" run "git gc --auto" every 1000 imported commits to
reduce the number of loose objects.
To handle the common use case of frequent imports, where each
invocation typically fetches much less than 1000 commits, also run gc
unconditionally at the end of the import.
"1000" is the same number that was used by default when we called
git-repack. It isn't necessarily still the best choice.
Signed-off-by: Karl Hasselström <kha@treskal.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 3 Feb 2008 08:00:09 +0000 (00:00 -0800)]
Fix "git-commit -C $tag"
The scripted version might not have handled this correctly
either, but the version rewritten in C definitely does not grok
this and complains $tag is not a commit object.
Junio C Hamano [Sun, 3 Feb 2008 07:47:22 +0000 (23:47 -0800)]
known breakage: revision range computation with clock skew
This is the absolute minimum (and reliable) reproduction recipe
to demonstrate that revision range in a history with clock skew
sometimes fails to mark UNINTERESTING commit in topologically
early parts of the history.
The history looks like this:
o---o---o---o
one four
but one has the largest timestamp. "git rev-list four..one"
fails to notice that "one" should not be emitted.
Junio C Hamano [Fri, 1 Feb 2008 09:50:53 +0000 (01:50 -0800)]
Sane use of test_expect_failure
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision. Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:
test_expect_{success,failure} 'test title' '
setup1 &&
setup2 &&
setup3 &&
what is to be tested
'
And expecting a failure exit from the whole sequence misses the
point of writing tests. Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test. The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.
This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:
test_expect_success 'test title' '
setup1 &&
setup2 &&
setup3 &&
! this command should fail
'
test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass. So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:
test_expect_failure 'git-foo should create bar' '
rm -f bar &&
git foo &&
test -f bar
'
This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".
projects / thirdparty / git.git / log
