* maint:
xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
Update cherry documentation.
Refer to git-rev-parse:Specifying Revisions from git.txt
git-fetch.sh printed protocol fix
RPM package re-classification.
Documentation: note about contrib/.
git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
Set $HOME for selftests
xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
This removes the '#' and '(' tests and adds a '$' test instead although I have
no idea what it is actually good for - but hey, if that's what GNU diff does...
Pasky only went and did as Junio sayeth.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Refer to git-rev-parse:Specifying Revisions from git.txt
The brief list given in "Symbolic Identifiers" section of the
main documentation is good enough for overview, but help the
reader to find a more comrehensive list as needed.
We have supported https:// protocol for some time and in 1.4.3
added ftp:// protocol. The transfer were still reported to be
over http.
[jc: Tuncer used substring parameter substitution ${remote%%:*}
but I am deferring it to a later day. We should replace
colon-expr with substring substitution after everybody's shell
can grok it someday, but we are not in a hurry. ]
git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
I incorrectly thought this was hopelessly broken in svn 1.4.0,
but now it's just broken in that the old method didn't work. It
looks like svn propdel and svn propset must be used now and the
(imho) more obvious svn rm --force && svn add no longer works.
"make -C t full-svn-test" should now work.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Acked-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Set HOME environment variable to test trash directory and export for
selftests. This fixes the git-svn selftests with nonexistent or not
readable home, as found in at least one automated build system:
* maint:
gitweb: Fix setting $/ in parse_commit()
daemon: do not die on older clients.
xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
git-clone: honor --quiet
Documentation for the [remote] config
prune-packed: Fix uninitialized variable.
If the commit couldn't have been read, $/ wasn't restored to \n properly,
causing random havoc like git_get_ref_list() returning the ref names with
trailing \n.
Aside of potential confusion in the body of git_search(), no other $/
surprises are hopefully hidden in the code.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
In the older times, the clients did not say which host they were trying
to connect, and the code we recently added did not quite handle the
older clients correctly.
I noticed that a cron-launched "git-clone --quiet" was generating
progress output to standard error -- and thus always spamming me.
The offending output was due to git-clone invoking git-read-tree with
its undocumented -v option.
This change turns off "-v" for --quiet.
Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
vc-git complains that it can't find the definition of ignore-errors
unless I (require 'cl). So I guess the correct place to do that is in
the file itself.
Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
We already generate a Date: header based on when the patch was
emailed. git-format-patch includes the Date: header of the
patch. Having two Date: headers is just confusing, so we
just use the current Date:
Often the mailed patches in a patch series are created over a
series of several hours or days, so the Date: header from the
original commit is incorrect for email, and often far off enough
for spam filters to complain.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Use column indexes in git-cvsserver where necessary.
Tonight I found a git-cvsserver instance spending a lot of time in
disk IO while trying to process operations against a Git repository
with >30,000 objects contained in it.
Blowing away my SQLLite database and rebuilding all tables with
indexes on the attributes that git-cvsserver frequently runs queries
against seems to have resolved the issue quite nicely.
Since the indexes shouldn't hurt performance on small repositories
and always helps on larger repositories we should just always create
them when creating the revision storage tables.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/pack:
add the capability for index-pack to read from a stream
index-pack: compare only the first 20-bytes of the key.
git-repack: repo.usedeltabaseoffset
pack-objects: document --delta-base-offset option
allow delta data reuse even if base object is a preferred base
zap a debug remnant
let the GIT native protocol use offsets to delta base when possible
make pack data reuse compatible with both delta types
make git-pack-objects able to create deltas with offset to base
teach git-index-pack about deltas with offset to base
teach git-unpack-objects about deltas with offset to base
introduce delta objects with offset to base
* maint:
pager: default to LESS=FRSX not LESS=FRS
Make prune also run prune-packed
git-vc: better installation instructions
gitweb: Do not esc_html $basedir argument to git_print_tree_entry
gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
Fix usagestring for git-branch
git-merge: show usage if run without arguments
Both the git-prune manpage and everday.txt say that git-prune should also prune
unpacked objects that are also found in packs, by running git prune-packed.
Junio thought this was "a regression when prune was rewritten as a built-in."
So modify prune to call prune-packed again.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
gitweb: Do not esc_html $basedir argument to git_print_tree_entry
In git_tree, rename $base variable (which is passed as $basedir
argument to git_print_tree_entry) to $basedir. Do not esc_html
$basedir, as it is part of file_name ('f') argument in link and not
printed. Add '/' at the end only if $basedir is not empty (it is empty
for top directory) and doesn't end in '/' already.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
add the capability for index-pack to read from a stream
This patch only adds the streaming capability to index-pack. Although
the code is different it has the exact same functionality as before to
make sure nothing broke.
This is in preparation for receiving packs over the net, parse them on
the fly, fix them up if they are "thin" packs, and keep the resulting
pack instead of exploding it into loose objects. But such functionality
should come separately.
One immediate advantage of this patch is that index-pack can now deal
with packs up to 4GB in size even on 32-bit architectures since the pack
is not entirely mmap()'d all at once anymore.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply: prepare for upcoming GNU diff -u format change.
The latest GNU diff from CVS emits an empty line to express
an empty context line, instead of more traditional "single
white space followed by a newline". Do not get broken by it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't use $author_name undefined when $from contains no /\s</.
I noticed a case not handled in a recent patch.
Demonstrate it like this:
$ touch new-file
$ git-send-email --dry-run --from j --to k new-file 2>err
new-file
OK. Log says:
Date: Thu, 19 Oct 2006 10:26:24 +0200
Sendmail: /usr/sbin/sendmail
From: j
Subject:
Cc:
To: k
Result: OK
$ cat err
Use of uninitialized value in pattern match (m//) at /p/bin/git-send-email line 416.
Use of uninitialized value in concatenation (.) or string at /p/bin/git-send-email line 420.
Use of uninitialized value in concatenation (.) or string at /p/bin/git-send-email line 468.
There's a patch for the $author_name part below.
The example above shows that $subject may also be used uninitialized.
That should be easy to fix, too.
Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* mw/pathinfo:
gitweb: Fix search form when PATH_INFO is enabled
gitweb: Document features better
gitweb: warn if feature cannot be overridden.
gitweb: start to generate PATH_INFO URLs.
* jc/send-email:
Make git-send-email detect mbox-style patches more readily
git-send-email: real name with period need to be dq-quoted on From: line
git-send-email: do not drop custom headers the user prepared
* rs/rebase:
git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
Supposing that both the base and result sizes were both full size 64-bit
values, their encoding would occupy only 9.2 bytes each. Therefore
inflating 64 bytes is way overkill. Limit it to 20 bytes instead which
should be plenty enough for a couple years to come.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
index-pack: compare only the first 20-bytes of the key.
The "union delta_base" is a strange beast. It is a 20-byte
binary blob key to search a binary searchable deltas[] array,
each element of which uses it to represent its base object with
either a full 20-byte SHA-1 or an offset in the pack. Which
representation is used is determined by another field of the
deltas[] array element, obj->type, so there is no room for
confusion, as long as we make sure we compare the keys for the
same type only with appropriate length. The code compared the
full union with memcmp().
When storing the in-pack offset, the union was first cleared
before storing an unsigned long, so comparison worked fine.
On 64-bit architectures, however, the union typically is 24-byte
long; the code did not clear the remaining 4-byte alignment
padding when storing a full 20-byte SHA-1 representation. Using
memcmp() to compare the whole union was wrong.
This fixes the comparison to look at the first 20-bytes of the
union, regardless of the architecture. As long as ulong is
smaller than 20-bytes this works fine.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
v1.2.0 is Ok and I personally would say it is old enough, but
the improvement between version 2 and version 3 delta is not
bit enough to justify breaking older clients.
We should resurrect this later, but when we do so we shold
make it conditional.
clone: the given repository dir should be relative to $PWD
the repository argument for git-clone should be relative to $PWD
instead of the given target directory. The old behavior gave us
surprising success and you need a few minute to know why it worked.
GIT_DIR is already exported so no need to cd into $D. And this makes
$PWD for git-fetch-pack, which is the actual command to take the given
repository dir, the same as git-clone.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
apply_textdelta and send_stream can use a separate pool from the
rest of the editor interface, so we'll use a separate SVN::Pool
for them and clear the pool after each file is sent to SVN.
This drastically reduces memory usage per-changeset committed,
and makes large commits (and initial imports) of several
thousand files possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Most callers of write_sha1_file_prepare() are only interested in the
resulting hash but don't care about the returned file name or the header.
This patch adds a simple wrapper named hash_sha1_file() which does just
that, and converts potential callers.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
Once a get_commit_editor has been called from an SVN session, RA
layer operations are not allowed (well, unless you're using
file:// or http(s)://). So we'll pass an alternate SVN::Ra
object to our editor object for running 'check-path'.
This should fix commits over svnserve (svn:// without ssh, too).
Closes Debian bug #392702, thanks to Pierre Habouzit for
reporting the bug.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
When configuration variable `repack.UseDeltaBaseOffset` is set
for the repository, the command passes `--delta-base-offset`
option to `git-pack-objects`; this typically results in slightly
smaller packs, but the generated packs are incompatible with
versions of git older than (and including) v1.4.3.
We will make it default to true sometime in the future, but not
for a while.
When whitespace or whitespace change was ignored, the function
xdl_recmatch() returned memcmp() style differences, which is wrong,
since it should return 0 on non-match.
Also, there were three horrible off-by-one bugs, even leading to wrong
hashes in the whitespace special handling.
The issue was noticed by Ray Lehtiniemi.
For good measure, this commit adds a test.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: add a message encouraging use of SVN::* libraries
I'm using svn 1.4.0-4 in Debian unstable and apparently there's
a regression on the SVN side that prevents a symlink from
becoming a regular file (which git supports, of course).
It's not a noticeable regression for most people, but this broke
the full-svn-tests target in t/Makefile for me.
The SVN::* Perl libraries seem to have matured and improved over
the past year, and git-svn has supported them for several months
now, so with that I encourage all users to start using the
SVN::* Perl libraries with git-svn.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
commit: fix a segfault when displaying a commit with unreachable parents
I was running git show on various commits found by fsck-objects
when I found this bug. Since find_unique_abbrev() cannot find
an abbreviation for an object not in the database, it will
return NULL, which is bad to run strlen() on. So instead, we'll
just display the unabbreviated sha1 that we referenced in the
commit.
I'm not sure that this is the best 'fix' for it because the
commit I was trying to show was broken, but I don't think a
program should segfault even if the user tries to do something
stupid.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
'graft-branches' is slightly longer than the rest of the
commands, so the text was squished together in the formatted
output. This patch just adds some more whitespace to make
the text look more pleasant.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-svn: document some of the newer features
I've forgotten to document many of the features added along the
way in the manpages. This fills in some holes in the
documentation and adds updates some outdated information.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently that was broken. Ideal fix would make the search form use
PATH_INFO too, but it's just one insignificant place so it's no big deal if
we don't for now... This at least makes it work.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Change the --verbose flag to more closely match svn. I was
somehow under the impression that --summary included --raw diff
output, but I was wrong. We now pass -r --raw --name-status as
arguments if passed -v/--verbose.
-r (recursive) is passed by default, since users usually want
it, and accepting it causes difficulty with the -r<revision>
option used by svn users. A --non-recursive switch has been
added to disable this.
Of course, --summary, --raw, -p and any other git-log options
can still be passed directly (without --name-status).
Also, several warnings about referencing undefined variables
have been fixed.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: multi-init saves and reuses --tags and --branches arguments
This should make it much easier to track newly added tags and
branches. Re-running multi-init without command-line arguments
should now detect new-tags and branches.
--trunk shouldn't change often, but running multi-init on it
is now idempotent.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
The confusion can be avoided in most cases by writing the remote message
in one go to prevent interleacing with local messages. The buffer
declaration has been moved inside recv_sideband() to avoid extra string
copies.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a --dry-run option to git-send-email due to having made too many
mistakes with it in the past week. I like having a safety catch on my
machine gun.
Signed-off-by: Matthew @ilcox <matthew@wil.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Waitz noticed that one of the case arms had an impossible
choice. It turns out that what it was checking was redundant and
the typo did not have any effect.
git-svnimport.perl: copying directory from original SVN place
When copying whole directory, if source directory is not in already
imported tree, try to get it from original SVN location. This happens
when source directory is not matched by provided 'trunk' and/or
'tags/branches' templates or when it is not part of specified SVN
sub-project.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
> On Sat, 07 Oct 2006 21:52:02 -0700
> Junio C Hamano <junkio@cox.net> wrote:
>
>> Using DAV, if it works with the server, has the advantage of not
>> having to keep objects/info/packs up-to-date from repository
>> owner's point of view. But the repository owner ends up keeping
>> up-to-date as a side effect of keeping info/refs up-to-date
>> anyway (as I do not see a code to read that information over
>> DAV), so there is no point doing this over DAV in practice.
>>
>> Perhaps we should remove call to remote_ls() from
>> fetch_indices() unconditionally, not just protected with
>> NO_EXPAT and be done with it?
>
> That makes a lot of sense. A server really has to always provide
> a objects/info/packs anyway, just to be fetchable today by clients
> that are compiled with NO_EXPAT.
And even for an isolated group where everybody knows that
everybody else runs DAV-enabled clients, they need info/refs
prepared for ls-remote and git-fetch script, which means you
will run update-server-info to keep objects/info/packs up to
date.
Nick, do you see holes in my logic?
-- >8 --
http-fetch.c: drop remote_ls()
While doing remote_ls() over DAV potentially allows the server
side not to keep objects/info/pack up-to-date, misconfigured or
buggy servers can silently ignore or not to respond to DAV
requests and makes the client hang.
The server side (unfortunately) needs to run git-update-server-info
even if remote_ls() removes the need to keep objects/info/pack file
up-to-date, because the caller of git-http-fetch (git-fetch) and other
clients that interact with the repository (e.g. git-ls-remote) need to
read from info/refs file (there is no code to make that unnecessary by
using DAV yet).
Perhaps the right solution in the longer-term is to make info/refs
also unnecessary by using DAV, and we would want to resurrect the
code this patch removes when we do so, but let's drop remote_ls()
implementation for now. It is causing problems without really
helping anything yet.
git will keep it for us until we need it next time.
gitweb: Cleanup Git logo and Git logo target generation
Rename $githelp_url and $githelp_label to $logo_url and $logo_label to
be more obvious what they refer to; while at it add commented out
previous contents (git documentation at kernel.org). Add comment about
logo size.
Use $cgi->a(...) to generate Git logo link; it automatically escapes
attribute values when it is needed. Escape href attribute using
esc_url instead of (incorrect!) esc_html.
Move styling of git logo <img> element from "style" attribute to CSS
via setting class to "logo". Perhaps we should set it by id rather
than by class.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Noted by Jiri Slaby, git-tar-tree --remote doesn't need to be run
from inside of a git archive. Since git-tar-tree is now only a
wrapper for git-archive, which calls setup_git_directory() as
needed, we should drop the flag RUN_SETUP.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-send-email detect mbox-style patches more readily
Earlier we insisted that mbox file to begin with "From ". That
is fine as long as you feed format-patch output, but if you
handcraft the input file, this is unnecessary burden. We should
detect lines that look like e-mail headers and say that is also
a mbox file.
The other input file format is traditional "send lots of email",
whose first line would never look like e-mail headers, so this
is a safe change.
The original patch was done by Matthew Wilcox, which checked
explicitly for headers the script pays attention to.
Add symlink support to ZIP file creation, and a few tests.
This implementation sets the "version made by" field
(creator_version) to Unix for symlinks, only; regular files and
directories are still marked as originating from FAT/VFAT/NTFS.
Also set "external file attributes" (attr2) to 0 for regular
files and 16 for directories (FAT attribute), and to the file
mode for symlinks.
We could always set the creator_version to Unix and include the
mode, but then Info-ZIP unzip would set the mode of the extracted
files to *exactly* the value stored in attr2. The FAT trick
makes it apply the umask instead. Note: FAT has no executable
bit, so this information is not stored in the ZIP file.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>