* jn/gitweb-log-history:
gitweb: Make 'history' view (re)use git_log_generic()
gitweb: Refactor common parts of 'log' and 'shortlog' views
gitweb: Refactor 'log' action generation, adding git_log_body()
* jn/help-everywhere: (23 commits)
diff --no-index: make the usage string less scary
merge-{recursive,subtree}: use usagef() to print usage
Introduce usagef() that takes a printf-style format
Let 'git <command> -h' show usage without a git dir
Show usage string for 'git http-push -h'
Let 'git http-fetch -h' show usage outside any git repository
Show usage string for 'git stripspace -h'
Show usage string for 'git unpack-file -h'
Show usage string for 'git show-index -h'
Show usage string for 'git rev-parse -h'
Show usage string for 'git merge-one-file -h'
Show usage string for 'git mailsplit -h'
Show usage string for 'git imap-send -h'
Show usage string for 'git get-tar-commit-id -h'
Show usage string for 'git fast-import -h'
Show usage string for 'git check-ref-format -h'
http-fetch: add missing initialization of argv0_path
Show usage string for 'git show-ref -h'
Show usage string for 'git merge-ours -h'
Show usage string for 'git commit-tree -h'
...
* jp/fetch-cull-many-refs:
remote: fix use-after-free error detected by glibc in ref_remove_duplicates
fetch: Speed up fetch of large numbers of refs
remote: Make ref_remove_duplicates faster for large numbers of refs
Add branch management for releases to gitworkflows
The current man page does a reasonable job at describing branch management
during the development process, but it does not contain any guidance as to
how the branches are affected by releases.
Add a basic introduction to the branch management undertaken during a
git.git release, so that a reader may gain some insight into how the
integration, maintenance, and topic branches are affected during the
release transition, and is thus able to better design the process for their
own project.
Other release activities such as reviews, testing, and creating
distributions are currently out of scope.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git remote: Separate usage strings for subcommands
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
This commit also removes the complete options list from
the first line of the subcommand usage string. Instead,
individual options are documented in the detailed
description following the general usage line.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-rename: reduce memory footprint by freeing blob data early
After running one round of estimate_similarity(), filespecs on either
side will have populated their cnt_data fields, and we do not need
the blob text anymore. We used to retain the blob data to optimize
for smaller projects (not freeing the blob data here would mean that
the final output phase would not have to re-read it), but we are
efficient enough without such optimization for smaller projects anyway,
and freeing memory early will help larger projects.
replace: use a GIT_NO_REPLACE_OBJECTS env variable
This has the same effect as --no-replace-objects option; git ignores the
replace refs. When --no-replace-objects option is passed to git, this
environment variable is set to "1" and exported to subprocesses in order
to propagate the same setting.
It is useful for example for scripts, as the git commands used in them can
now be aware that they must not read replace refs.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
describe: do not use unannotated tag even if exact match
4d23660 (describe: when failing, tell the user about options that
work, 2009-10-28) forgot to update the shortcut path where the code
detected and used a possible exact match. This means that an
unannotated tag on HEAD would be used by 'git describe'.
Guard this code path against the new circumstances, where unannotated
tags can be present in ->util even if we're not actually planning to
use them.
While there, also add some tests for --all.
Reported by 'yashi' on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule.c: Squelch a "use before assignment" warning
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) compiler
(and probably others) mistakenly thinks variable 'right' is used
before assigned. Work around it by giving it a fake initialization.
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup_revisions(): do not call get_pathspec() too early
This is necessary because we will later allow pathspecs to be fed from the
standard input, and pathspecs taken from the command line (and converted
via get_pathspec() already) in revs->prune_data too early gets in the way
when we want to append from the standard input.
Move the logic to read revs from standard input that rev-list knows about
from it to revision machinery, so that all the users of setup_revisions()
can feed the list of revs from the standard input when "--stdin" is used
on the command line.
Allow some users of the revision machinery that want different semantics
from the "--stdin" option to disable it by setting an option in the
rev_info structure.
This also cleans up the kludge made to bundle.c via cut and paste.
gitweb.js: fix null object exception in initials calculation
Currently handleLine() assumes that a commit author name will always
start with a capital letter. It's possible that the author name is
user@example.com and therefore calling a match() on the name will fail
to return any matches. Subsequently joining these matches will cause an
exception. Fix by checking that we have a match before trying to join
the results into a set of initials for the author.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The t/t9700/test.pl script uses method invocation syntax when
using the Cwd module to determine the current working directory.
This fails on cygwin, since cygwin perl specifically checks for
any arguments to the cwd() function and croak()'s with the message
"Usage: Cwd::cwd()". (In perl v5.8.8 distribution, see the file
perl-5.8.8/cygwin/cygwin.c lines 139-157)
In order to avoid the problem, we replace the method invocation
syntax with a simple function call.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
expand_user_path: expand ~ to $HOME, not to the actual homedir.
In 395de250d (Expand ~ and ~user in core.excludesfile, commit.template),
we introduced the mechanism. But expanding ~ using getpw is not what
people overriding $HOME would usually expect. In particular, git looks
for the user's .gitconfig using $HOME, so it's better to be consistent.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/tutorial-test:
t1200: prepare for merging with Fast-forward bikeshedding
t1200: further modernize test script style
t1200: Make documentation and test agree
t1200: cleanup and modernize test style
* ef/msys-imap:
Windows: use BLK_SHA1 again
MSVC: Enable OpenSSL, and translate -lcrypto
mingw: enable OpenSSL
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
imap-send: build imap-send on Windows
imap-send: fix compilation-error on Windows
imap-send: use run-command API for tunneling
imap-send: use separate read and write fds
imap-send: remove useless uid code
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
On this slow laptop, this decreases the time to load
git-completion.bash from about 500 ms to about 175 ms.
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru> Acked-by: Shawn O. Pearce <spearce@spearce.org> Cc: Stephen Boyd <bebarino@gmail.com> Cc: SZEDER Gábor <szeder@ira.uka.de> Cc: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
Document git-svn's first-parent rule
git svn: attempt to create empty dirs on clone+rebase
git svn: add authorsfile test case for ~/.gitconfig
git svn: read global+system config for clone+init
git svn: handle SVN merges from revisions past the tip of the branch
Make sure $PERL_PATH is defined when the test suite is run.
Some test scripts run Perl scripts as if they were git-* scripts, and
thus need to use the same perl that will be put in the shebang line of
git*.perl commands. $PERL_PATH therefore needs to be used instead of
a bare "perl".
The tests can fail if another perl is found in $PATH before the one
defined in $PERL_PATH.
Example test failure caused by this: the perl defined in $PERL_PATH has
Error.pm installed, and therefore the Git.pm's Makefile.PL doesn't install
the private copy. The perl from $PATH doesn't have Error.pm installed, and
all git*.perl scripts invoked during the test will fail loading Error.pm.
Makefile patch by Jeff King <peff@peff.net>.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
core.autocrlf documentation: mention the crlf attribute
The description of the configuration variable is obsolete and
wrong (saying only file content is used), not just incomplete.
It has used the attribute mechanism for a long time.
The documentation of gitattributes mentions the core.autocrlf
configuration variable in its description of crlf attribute.
Refer to the gitattributes documentation from here as well.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a paragraph about the swapped sides in a --merge rebase, which was
otherwise only documented in the sources.
Add a paragraph about the effects of the 'ours' strategy to the -s
description. Also remove the mention of the 'octopus' strategy, which
was copied from the git-merge description but is pointless in a
rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "break" phase works by counting changes between two
blobs with the same path. We do this by splitting the file
into chunks (or lines for text oriented files) and then
keeping a count of chunk hashes.
The "rename" phase counts changes between blobs at two
different paths. However, it uses the exact same set of
chunk hashes (which are immutable for a given sha1).
The rename phase can therefore use the same hash data as
break. Unfortunately, we were throwing this data away after
computing it in the break phase. This patch instead attaches
it to the filespec and lets it live through the rename
phase, working under the assumption that most of the time
that breaks are being computed, renames will be too.
We only do this optimization for files which have actually
been broken, as those ones will be candidates for rename
detection (and it is a time-space tradeoff, so we don't want
to waste space keeping useless data).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
As we look at each changed file and consider breaking it, we
load the blob data and make a decision about whether to
break, which is independent of any other blobs that might
have changed. However, we keep the data in memory while we
consider breaking all of the other files. Which means that
both versions of every file you are diffing are in memory at
the same time.
This patch instead frees the blob data as we finish with
each file pair, leading to much lower memory usage.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'js/maint-diff-color-words' into maint
* js/maint-diff-color-words:
diff --color-words: bit of clean-up
diff --color-words -U0: fix the location of hunk headers
t4034-diff-words: add a test for word diff without context
* jc/maint-blank-at-eof:
diff -B: colour whitespace errors
diff.c: emit_add_line() takes only the rest of the line
diff.c: split emit_line() from the first char and the rest of the line
diff.c: shuffling code around
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
http-backend: Let gcc check the format of more printf-type functions.
We already have these checks in many printf-type functions that have
prototypes which are in header files. Add these same checks to
static functions in http-backend.c
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn: attempt to create empty dirs on clone+rebase
We parse unhandled.log files for empty_dir statements and make a
best effort attempt to recreate empty directories on fresh
clones and rebase. This should cover the majority of cases
where users work off a single branch or for projects where
branches do not differ in empty directories.
Since this cannot affect "normal" git commands like "checkout"
or "reset", so users switching between branches in a single
working directory should use the new "git svn mkdirs" command
after switching branches.
We already have these checks in many printf-type functions that have
prototypes which are in header files. Add these same checks to some
more prototypes in header functions and to static functions in .c
files.
cc: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-diff-color-words:
diff --color-words: bit of clean-up
diff --color-words -U0: fix the location of hunk headers
t4034-diff-words: add a test for word diff without context
* ja/fetch-doc:
Documentation/merge-options.txt: order options in alphabetical groups
Documentation/git-pull.txt: Add subtitles above included option files
Documentation/fetch-options.txt: order options alphabetically
* jc/receive-pack-auto:
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
gc --auto --quiet: make the notice a bit less verboase
Make it clear in the docs that the merge takes the tree of HEAD and
ignores everything in the other branches. This should hopefully clear
up confusion, usually caused by the user looking for a strategy that
resolves all conflict hunks in favour of HEAD (which is completely
different and currently not supported).
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update 'git remote update' usage string to match man page.
Commit b344e161 taught 'git remote update' to understand
[group | remote] as its argument. The man page was updated
to document this change, but the usage string was not.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote: fix use-after-free error detected by glibc in ref_remove_duplicates
In ref_remove_duplicates, when we encounter a duplicate and remove it
from the list we need to make sure that the prev pointer stays
pointing at the last entry and also skip over adding the just freed
entry to the string_list.
Makefile: Ensure rpm packages can be read by older rpm versions
The kernel.org hosts where the packages are built are now using Fedora
11, which defaults to sha256 for file digests instead of md5. Older
versions of rpm can not handle these packages. Tell rpmbuild to use md5
file digests for better compatibility.
Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Make 'history' view (re)use git_log_generic()
Make git_history use git_log_generic, passing git_history_body as one
of its paramaters. This required changes to git_log_generic, in
particular passing more things as parameters.
While refactoring common code of 'log', 'shortlog' and 'history' view,
we did unify pagination, using always the form used by 'history' view,
namely
first * prev * next
in place of
HEAD * prev * next
used by 'log' and 'shortlog' views.
The 'history' view now supports commit limiting via 'hpb' parameter,
similarly to 'shortlog' (and 'log') view. Performance of 'history'
view got improved a bit, as it doesn't run git_get_hash_by_path for
"current" version in a loop. Error detection and reporting for
'history' view changed a bit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Refactor common parts of 'log' and 'shortlog' views
Put the common parts of git_log and git_shortlog into git_log_generic
subroutine: git_log and git_shortlog are now thin wrappers calling
git_log_generic with appropriate arguments.
The unification of code responsible for 'log' and 'shorlog' actions
lead to the following changes in gitweb output
* 'tree' link in page_nav now uses $hash parameter, as was the case
for 'shortlog' but not for 'log'
* 'log' view now respect $hash_parent limiting, like 'shortlog' did
* 'log' view doesn't have special case for empty list anymore, and it
always uses page_header linking to summary view, like 'shortlog'
did.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Put the main part of 'log' view generation into git_log_body,
similarly how it is done for 'shortlog' and 'history' views (and
also for 'tags' and 'heads' views).
This is preparation for extracting common code between 'log',
'shortlog' and 'history' actions.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since $GIT_DIR does not exist when initializing new repositories,
we can follow back to the global and system config files for
git.
The logic for this was originally introduced when
$GIT_DIR/config was the only config file git could read (back
when "git config" was "git repo-config"), so the function is
renamed to "read_git_config" instead of "read_repo_config".
git svn: handle SVN merges from revisions past the tip of the branch
When recording the revisions that it has merged, SVN sets the top
revision to be the latest revision in the repository, which is not
necessarily a revision on the branch that is being merged from. When
it is not on the branch, git-svn fails to add the extra parent to
represent the merge because it relies on finding the commit on the
branch that corresponds to the top of the SVN merge range.
In order to correctly handle this case, we look for the maximum
revision less than or equal to the top of the SVN merge range that is
actually on the branch being merged from.
[ew: This includes the following (squashed) commit to prevent
errors during bisect:]
git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
properties. The problematic case is when there is some commit on an
unrelated branch after the last commit on the merged-from branch.
When SVN records the mergeinfo property, it records the latest
revision in the whole repository, which, in the problematic case, is
not on the branch it is merging from.
To trigger the git-svn bug, we modify t9151 to include two SVN merges,
the second of which has an intervening commit. The SVN dump was
generated using SVN 1.6.6 (on Debian squeeze amd64).
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
gitk: Fix "git gui blame" invocation when called from top-level directory
When run in the top-level directory of a git repository, "git
rev-parse --git-dir" doesn't return an absolute path, but merely
".git", so the selected file for "git gui blame" has a relative path.
The function make_relative then tries to make the already relative
path relative, which results in a path like "../../../../Makefile"
with as many ".." as there are elements of [pwd].
This regression was introduced by commit 9712b81 (gitk: Fix bugs in
blaming code, 2008-12-06), which fixed "git gui blame" when called from
subdirs.
This also fixes it for bare repositories.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
At the command line, trying to check out a remote branch gives you a
detailed warning message, but the gitk GUI currently allows it without
any fuss.
Since the GUI is often used by people much less familiar with git, it
seems reasonable to make the GUI more restrictive than the command line,
not less.
This prevents a lot of detached HEAD commits by new users.
Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Improve appearance of radiobuttons and checkbuttons
Commit 5497f7a23ac11f9b230892220d5ed80263eedd1f ("gitk: Add configuration
for UI colour scheme") added a call to tk_setPalette at startup.
Unfortunately, tk_setPalette always chooses a dark red color for
the selectColor value if none is given explicitly, and this makes
checkbuttons and radiobuttons look rather bad.
This restores the previous appearance by specifying selectColor
explicitly. For light backgrounds we use white for selectColor, and
for dark backgrounds we use black. The formula and threshold for
distinguishing light from dark are the same as used in tk_setPalette
for choosing the foreground color.
http-backend: Fix bad treatment of uintmax_t in Content-Length
Our Content-Length needs to report an off_t, which could be larger
precision than size_t on this system (e.g. 32 bit binary built with
64 bit large file support).
We also shouldn't be passing a size_t parameter to printf when
we've used PRIuMAX as the format specifier.
Fix both issues by using uintmax_t for the hdr_int() routine,
allowing strbuf's size_t to automatically upcast, and off_t to
always fit.
Also fixed the copy loop we use inside of send_local_file(), we never
actually updated the size variable so we might as well not use it.
Reported-by: Tarmigan <tarmigan+git@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In theory it is possible for sideband channel #2 to be delayed if
pack data is quick to come up for sideband channel #1. And because
data for channel #2 is read only 128 bytes at a time while pack data
is read 8192 bytes at a time, it is possible for many pack blocks to
be sent to the client before the progress message fifo is emptied,
making the situation even worse. This would result in totally garbled
progress display on the client's console as local progress gets mixed
with partial remote progress lines.
Let's prevent such situations by giving transmission priority to
progress messages over pack data at all times.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Provide a DEFAULT_PAGER knob so packagers can set the fallback
pager to something appropriate during the build.
Examples:
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which
forces users to alter their environment (PATH, GIT_PAGER, LESS,
etc) or have a local or global gitconfig before paging works as
expected.
On Debian systems, by policy packages must fall back to the
'pager' command, so that changing the target of the
/usr/bin/pager symlink changes the default pager for all packages
at once.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Provide a DEFAULT_EDITOR knob to allow setting the fallback
editor to use instead of vi (when VISUAL, EDITOR, and GIT_EDITOR
are unset). The value can be set at build time according to a
system’s policy. For example, on Debian systems, the default
editor should be the 'editor' command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>