* tr/commit-slab-cleanup:
commit-slab: sizeof() the right type in xrealloc
commit-slab: declare functions "static inline"
commit-slab: document clear_$slabname()
The "--tags" option to "git fetch" used to be literally a synonym to
a "refs/tags/*:refs/tags/*" refspec, which meant that (1) as an
explicit refspec given from the command line, it silenced the lazy
"git fetch" default that is configured, and (2) also as an explicit
refspec given from the command line, it interacted with "--prune"
to remove any tag that the remote we are fetching from does not
have.
This demotes it to an option; with it, we fetch all tags in
addition to what would be fetched without the option, and it does
not interact with the decision "--prune" makes to see what
remote-tracking refs the local has are missing the remote
counterpart.
* mh/fetch-tags-in-addition-to-normal-refs: (23 commits)
fetch: improve the error messages emitted for conflicting refspecs
handle_duplicate(): mark error message for translation
ref_remote_duplicates(): extract a function handle_duplicate()
ref_remove_duplicates(): simplify loop logic
t5536: new test of refspec conflicts when fetching
ref_remove_duplicates(): avoid redundant bisection
git-fetch.txt: improve description of tag auto-following
fetch-options.txt: simplify ifdef/ifndef/endif usage
fetch, remote: properly convey --no-prune options to subprocesses
builtin/remote.c:update(): use struct argv_array
builtin/remote.c: reorder function definitions
query_refspecs(): move some constants out of the loop
fetch --prune: prune only based on explicit refspecs
fetch --tags: fetch tags *in addition to* other stuff
fetch: only opportunistically update references based on command line
get_expanded_map(): avoid memory leak
get_expanded_map(): add docstring
builtin/fetch.c: reorder function definitions
get_ref_map(): rename local variables
api-remote.txt: correct section "struct refspec"
...
* git://repo.or.cz/git-gui:
git-gui: correct spelling errors in comments
git-gui: add menu item to launch a bash shell on Windows.
git-gui: corrected setup of git worktree under cygwin.
git-gui: right half window is paned
git-gui: Add gui.displayuntracked option
git-gui: show the maxrecentrepo config option in the preferences dialog
git-gui: added gui.maxrecentrepo to extend the number of remembered repos
git-gui: Improve font rendering on retina macbooks
* git://ozlabs.org/~paulus/gitk:
gitk: Recognize -L option
gitk: Support showing the gathered inline diffs
gitk: Split out diff part in $commitinfo
gitk: Refactor per-line part of getblobdiffline and its support
gitk: Support -G option from the command line
gitk: Tag display improvements
git-config used a static match array to hold the matches we want to
unset/replace when using --unset or --replace-all. Use a
variable-sized array instead.
This in particular fixes the symptoms git-svn had when storing large
numbers of svn-remote.*.added-placeholder entries in the config file.
While the tests are rather more paranoid than just --unset and
--replace-all, the other operations already worked. Indeed git-svn's
usage only breaks the first time *after* creating so many entries,
when it wants to unset and re-add them all.
Reported-by: Jess Hottenstein <jess.hottenstein@gmail.com>
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff -- ':(icase)makefile'" were rejected unnecessarily.
This needs to be merged to 'maint' later.
* nd/magic-pathspec:
diff: restrict pathspec limitations to diff b/f case only
Add a few formatting directives to "git for-each-ref --format=...",
to paint them in color, etc.
* rr/for-each-ref-decoration:
for-each-ref: avoid color leakage
for-each-ref: introduce %(color:...) for color
for-each-ref: introduce %(upstream:track[short])
for-each-ref: introduce %(HEAD) asterisk marker
t6300 (for-each-ref): don't hardcode SHA-1 hexes
t6300 (for-each-ref): clearly demarcate setup
Updates to remote-bzr and remote-hg in contrib.
* rh/remote-hg-bzr-updates:
remote-bzr, remote-hg: fix email address regular expression
test-hg.sh: help user correlate verbose output with email test
test-hg.sh: fix duplicate content strings in author tests
test-hg.sh: avoid obsolete 'test' syntax
test-hg.sh: eliminate 'local' bashism
test-bzr.sh, test-hg.sh: prepare for change to push.default=simple
test-bzr.sh, test-hg.sh: allow running from any dir
test-lib.sh: convert $TEST_DIRECTORY to an absolute path
Allow customizing the paths to Perl modules with the new
PERLLIB_EXTRA makefile variable.
* jn/perl-lib-extra:
Makefile: add PERLLIB_EXTRA variable that adds to default perl path
Makefile: rebuild perl scripts when perl paths change
Build and installation procedure clean-up.
* jn/mediawiki-makefile-updates:
git-remote-mediawiki build: handle DESTDIR/INSTLIBDIR with whitespace
git-remote-mediawiki build: make 'install' command configurable
git-remote-mediawiki: honor DESTDIR in "make install"
git-remote-mediawiki: do not remove installed files in "clean" target
An attempt to automatically align the names in the "git status"
output, taking the display width of (translated) section labels
into account.
* nd/wt-status-align-i18n:
wt-status: take the alignment burden off translators
"git cat-file --batch-check=ok" did not check the existence of the
named object.
* sb/sha1-loose-object-info-check-existence:
sha1_loose_object_info(): do not return success on missing object
Fix a rather longstanding corner-case bug in twoway "reset to
there" merge, which is most often seen in "git am --abort".
* jk/two-way-merge-corner-case-fix:
t1005: add test for "read-tree --reset -u A B"
t1005: reindent
unpack-trees: fix "read-tree -u --reset A B" with conflicted index
People often wished a way to tell "git log --branches" (and "git
log --remotes --not --branches") to exclude some local branches
from the expansion of "--branches" (similarly for "--tags", "--all"
and "--glob=<pattern>"). Now they have one.
* jc/ref-excludes:
rev-parse: introduce --exclude=<glob> to tame wildcards
rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API
rev-list --exclude: tests
document --exclude option
revision: introduce --exclude=<glob> to tame wildcards
Enhance "rev-parse --parseopt" mode to help parsing options with
an optional parameter.
* nv/parseopt-opt-arg:
rev-parse --parseopt: add the --stuck-long mode
Use the word 'stuck' instead of 'sticked'
Issue "100 Continue" responses to help use of GSS-Negotiate
authentication scheme over HTTP transport when needed.
* bc/http-100-continue:
remote-curl: fix large pushes with GSSAPI
remote-curl: pass curl slot_results back through run_slot
http: return curl's AUTHAVAIL via slot_results
Code the logic in "pull --rebase" that figures out a fork point
from reflog entries in C.
* jc/merge-base-reflog:
merge-base: teach "--fork-point" mode
merge-base: use OPT_CMDMODE and clarify the command line parsing
When two processes created one loose object file each, which fell
into the same fan-out bucket that previously did not have any
objects, they both tried to do an equivalent of
mkdir .git/objects/$fanout &&
chmod $shared_perm .git/objects/$fanout
before writing into their file .git/objects/$fanout/$remainder,
one of which could have failed unnecessarily when the second
invocation of mkdir found that the directory already has been
created by the first one.
* jh/loose-object-dirs-creation-race:
sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
* jk/robustify-parse-commit:
checkout: do not die when leaving broken detached HEAD
use parse_commit_or_die instead of custom message
use parse_commit_or_die instead of segfaulting
assume parse_commit checks for NULL commit
assume parse_commit checks commit->object.parsed
log_tree_diff: die when we fail to parse a commit
A behavior change, but a worthwhile one: "git submodule foreach"
was treating its arguments as part of a single command to be
concatenated and passed to a shell, making writing buggy
scripts too easy.
This patch preserves the old "just pass it to the shell" behavior
when a single argument is passed to 'git submodule foreach' and
moves to a new "skip the shell and use the arguments passed
unmolested" behavior when more than one argument is passed.
The old behavior (always concatenating and passing to the shell)
was similar to the 'ssh' command, while the new behavior (switching
on the number of arguments) is what 'xterm -e' does.
May need more thought to make sure this change is advertised well
so that scripts that used multiple arguments but added their own
extra layer of quoting are not broken.
* ak/submodule-foreach-quoting:
submodule foreach: skip eval for more than one argument
The usage sample of add_submodule_odb() function in the Submodules
section expects non-zero return value for success, but the function
actually reports success with zero.
Helped-by: René Scharfe <l.s.r@web.de>
Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Nick Townsend <nick.townsend@mac.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When submodule.$name.update is given as hint from the upstream in
the .gitmodules file, we used to blindly copy it to .git/config,
unless there already is a value defined for the submodule.
However, there is no reason to expect that the update mode hinted by
the upstream is available in the version of Git the user is using,
and a really custom "!cmd" prepared by an upstream person running on
Linux may not even be available to a user on Windows. It is simply
irresponsible to copy the setting blindly and to attempt to use it
during a later "submodule update" without validating it first.
Just show the suggested value to the diagnostic output, and set the
value to 'none' in the configuration, if it is not one of the ones
that are known to be supported by this version of Git.
Helped-by: Jens Lehmann <Jens.Lehmann@web.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When allocating the slab, the code accidentally computed the array
size from s->slab (an elemtype**). The slab is an array of elemtype*,
however, so we should take the size of *s->slab.
Noticed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gives line-log support to gitk, by exploiting the new support for
processing and showing "inline" diffs straight from the git-log
output.
Note that we 'set allknown 0', which is a bit counterintuitive since
this is a "known" option. But that flag prevents gitk from thinking
it can optimize the view by running rev-list to see the topology; in
the -L case that doesn't work.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The previous commit split the diffs into a separate field. Now we
actually want to show them.
To that end we use the stored diff, and
- process it once to build a fake "tree diff", i.e., a list of all
changed files;
- feed it through parseblobdiffline to actually format it into the
$ctext field, like the existing diff machinery would.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
So far we just parsed everything after the headers into the "comment"
bit of $commitinfo, including notes and -- if you gave weird options
-- the diff.
Split out the diff, if any, into a separate field. It's easy to
recognize, since it always starts with /^diff/ and is preceded by an
empty line.
We take care to snip away said empty line. The display code already
properly spaces the end of the message from the first diff, and
leaving another empty line at the end looks ugly.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
For later use with data sources other than a pipe, refactor the big
worker part of getblobdiffline to a separate function
parseblobdiffline. Also refactor its initialization and wrap-up to
separate routines.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The -G option's usage is exactly analogous to that of -S, so
supporting it is easy.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
