* 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
Conflicts:
diff.c
* 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
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>
Found with valgrind while looking for Content-Length corruption in
smart http.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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
Conflicts:
diff.c
* rs/pretty-wrap:
log --format: don't ignore %w() at the start of format string
Implement wrap format %w() as if it is a mode switch
Conflicts:
pretty.c
* 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>
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>
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.
Previously fetch could crash with:
*** glibc detected *** git: corrupted double-linked list: ...
Also add a test to try and catch problems with duplicate removal in
the future.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
The commit for:
git svn: read global+system config for clone+init
Initially lacked a test case because the author was unable to
reproduce it under his test environment, this adds it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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".
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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:]
Author: Toby Allsopp <toby.allsopp@navman.co.nz>
Date: Fri Nov 13 09:48:39 2009 +1300
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>
Also convert a button to use the themed widget set.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
