Initial phases of push and pull with git-remote-mediawiki can be long on
a large wiki. Let the user know what's going on.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When notes are created to record a push, it normally doesn't exist yet.
However, when a push is interrupted and then restarted, it may happen
that a commit already has notes attached, and we want to reflect the newly
created remote revision, hence use 'git notes add -f' to override the
existing one
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The algorithm to find a path from the local revision to the remote one
was calling "git rev-list" and parsing its output N times. Run rev-list
only once, and fill a hashtable with the result to optimize the body of
the loop.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is possible to use git-remote-mediawiki on a tree with both .mw files
and other files. Before git-remote-mediawiki learnt how to export
mediafiles, such mixed trees allowed the user to maintain both the wiki
and other files for the same project in the same repository. With the
newly added support for exporting mediafiles, pushing such mixed trees
would upload unrelated files as mediafiles, which may not be desired.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though the index can record pathnames longer than 1<<12 bytes,
in some places we were not comparing them in full, potentially
replacing index entries instead of adding.
* tg/maint-cache-name-compare:
cache_name_compare(): do not truncate while comparing paths
The streaming index-pack introduced in 1.7.11 had a data corruption
bug, and this should fix it.
* jk/index-pack-streaming-fix:
index-pack: loop while inflating objects in unpack_data
"git commit --amend --only --" was meant to allow "Clever" people to
rewrite the commit message without making any change even when they
have already changes for the next commit added to their index, but
it never worked as advertised since it was introduced in 1.3.0 era.
* jk/maint-commit-amend-only-no-paths:
commit: fix "--amend --only" with no pathspec
"commit --amend" used to refuse amending a commit with an empty log
message, with or without "--allow-empty-message".
* cw/amend-commit-without-message:
Allow edit of empty message with commit --amend
Tightens dependency rules to avoid unnecessary recompilation, and
cleans up our Makefile in general.
* jn/makefile-cleanup:
Makefile: document ground rules for target-specific dependencies
Makefile: move GIT-VERSION-FILE dependencies closer to use
Makefile: build instaweb similar to other scripts
Makefile: update scripts when build-time parameters change
Makefile: do not replace @@GIT_VERSION@@ in shell scripts
Makefile: split prefix flags from GIT-CFLAGS
Makefile: be silent when only GIT_USER_AGENT changes
Makefile: split GIT_USER_AGENT from GIT-CFLAGS
Makefile: do not replace @@GIT_USER_AGENT@@ in scripts
Makefile: apply dependencies consistently to sparse/asm targets
Makefile: do not have git.o depend on common-cmds.h
Makefile: fold XDIFF_H and VCSSVN_H into LIB_H
Makefile: fold MISC_H into LIB_H
Makefile: sort LIB_H list
A handful of files and directories we create had tighter than
necessary permission bits when the user wanted to have group
writability (e.g. by setting "umask 002").
* ar/clone-honor-umask-at-top:
add: create ADD_EDIT.patch with mode 0666
rerere: make rr-cache fanout directory honor umask
Restore umasks influence on the permissions of work tree created by clone
"git apply" learned to wiggle the base version and perform three-way
merge when a patch does not exactly apply to the version you have.
* jc/apply-3way:
apply: tests for the --3way option
apply: document --3way option
apply: allow rerere() to work on --3way results
apply: register conflicted stages to the index
apply: --3way with add/add conflict
apply: move verify_index_match() higher
apply: plug the three-way merge logic in
apply: fall back on three-way merge
apply: accept -3/--3way command line option
apply: move "already exists" logic to check_to_create()
apply: move check_to_create_blob() closer to its sole caller
apply: further split load_preimage()
apply: refactor "previous patch" logic
apply: split load_preimage() helper function out
apply: factor out checkout_target() helper function
apply: refactor read_file_or_gitlink()
apply: clear_image() clears things a bit more
apply: a bit more comments on PATH_TO_BE_DELETED
apply: fix an incomplete comment in check_patch()
"git rebase [-i] --root $tip" can now be used to rewrite all the
history down to the root.
* cw/rebase-i-root:
t3404: make test 57 work with dash and others
Add tests for rebase -i --root without --onto
rebase -i: support --root without --onto
Teach "git p4" to notice "Jobs:" in the log message and relay it to
Perforce to trigger its "jobs" support.
# By Pete Wyckoff
* pw/git-p4-jobs:
git p4: notice Jobs lines in git commit messages
git p4 test: refactor marshal_dump
git p4: remove unused P4Submit interactive setting
The error message from "git push $there :bogo" mentioned we tried
and failed to guess what ref is being deleted based on the LHS of
the refspec, which we don't.
# By Jeff King
* jk/push-delete-ref-error-message:
push: don't guess at qualifying remote refs on deletion
Due to the way "git diff --no-index" is bolted onto by touching the
low level code that is shared with the rest of the "git diff" code,
even though it has to work in a very different way, any comparison
that involves a file "-" at the root level incorrectly tried to read
from the standard input. This cleans up the no-index codepath
further to remove code that reads from the standard input from the
core side, which is never necessary when git is running its usual
diff operation.
* jc/refactor-diff-stdin:
diff-index.c: "git diff" has no need to read blob from the standard input
diff-index.c: unify handling of command line paths
diff-index.c: do not pretend paths are pathspecs
Teaches git to normalize pathnames read from readdir(3) and all
arguments from the command line into precomposed UTF-8 (assuming
that they come as decomposed UTF-8) to work around issues on Mac OS.
I think there still are other places that need conversion
(e.g. paths that are read from stdin for some commands), but this
should be a good first step in the right direction.
* tb/sanitize-decomposed-utf-8-pathname:
git on Mac OS and precomposed unicode
* mm/mediawiki-tests:
git-remote-mediawiki: be more defensive when requests fail
git-remote-mediawiki: more efficient 'pull' in the best case
git-remote-mediawiki: extract revision-importing loop to a function
git-remote-mediawiki: refactor loop over revision ids
git-remote-mediawiki: change return type of get_mw_pages
git-remote-mediawiki (t9363): test 'File:' import and export
git-remote-mediawiki: support for uploading file in test environment
git-remote-mediawiki (t9362): test git-remote-mediawiki with UTF8 characters
git-remote-mediawiki (t9361): test git-remote-mediawiki pull and push
git-remote-mediawiki (t9360): test git-remote-mediawiki clone
git-remote-mediawiki: test environment of git-remote-mediawiki
git-remote-mediawiki: scripts to install, delete and clear a MediaWiki
"mediawiki" remote helper (in contrib/) learned to handle file
attachments.
* mm/mediawiki-file-attachments:
git-remote-mediawiki: improve support for non-English Wikis
git-remote-mediawiki: import "File:" attachments
git-remote-mediawiki: split get_mw_pages into smaller functions
git-remote-mediawiki: send "File:" attachments to a remote wiki
git-remote-mediawiki: don't "use encoding 'utf8';"
git-remote-mediawiki: don't compute the diff when getting commit message
Fixes "git show"'s auto-walking behaviour, and make it behave just
like "git log" does when it walks.
* tr/maint-show-walk:
show: fix "range implies walking"
Demonstrate git-show is broken with ranges
Teach "am --rebasing" codepath to grab authorship, log message and
the patch text directly out of existing commits. This will help
rebasing commits that have confusing "diff" output in their log
messages.
* mz/rebase-no-mbox:
am: don't call mailinfo if $rebasing
am --rebasing: get patch body from commit, not from mailbox
rebase --root: print usage on too many args
rebase: don't source git-sh-setup twice
For -M option (detectRenames) in P4Submit, use 'p4 move' rather
than 'p4 integrate'. Check Perforce server for exisitence of
'p4 move' and use it if present, otherwise revert to 'p4 integrate'.
[pw: wildcard-encode src/dest, add/update tests, tweak code]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git blame" did not try to make sure that the abbreviated commit
object names in its output are unique.
* jc/maint-blame-unique-abbrev:
blame: compute abbreviation width that ensures uniqueness
On Cygwin, the platform pread(2) is not thread safe, just like our own
compat/ emulation, and cannot be used in the index-pack program.
Makefile variable NO_THREAD_SAFE_PREAD can be defined to avoid use of
this function in a threaded program.
* rj/platform-pread-may-be-thread-unsafe:
index-pack: Disable threading on cygwin
"git diff --no-index" did not correctly handle relative paths and
did not correctly give exit codes when run under "--quiet" option.
* th/diff-no-index-fixes:
diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes
diff: handle relative paths in no-index
"git clone --single-branch" to clone a single branch did not limit
the cloning to the specified branch.
* nd/clone-single-fix:
clone: fix ref selection in --single-branch --branch=xxx
When "git log" gets "--simplify-merges/by-decoration" together with
"--first-parent", the combination of these options makes the
simplification logic to use in-core commit objects that haven't been
examined for relevance, either producing incorrect result or taking
too long to produce any output. Teach the simplification logic to
ignore commits that the first-parent traversal logic ignored when
both are in effect to work around the issue.
* jc/rev-list-simplify-merges-first-parent:
revision: ignore side parents while running simplify-merges
revision: note the lack of free() in simplify_merges()
revision: "simplify" options imply topo-order sort
"git add" allows adding a regular file to the path where a submodule
used to exist, but "git update-index" did not allow an equivalent
operation to Porcelain writers.
* hv/submodule-update-nuke-submodules:
update-index: allow overwriting existing submodule index entries
"git diff --no-index" did not work with pagers correctly.
* jk/diff-no-index-pager:
do not run pager with diff --no-index --quiet
fix pager.diff with diff --no-index
"git diff COPYING HEAD:COPYING" gave a nonsense error message that
claimed that the treeish HEAD did not have COPYING in it.
* mm/verify-filename-fix:
verify_filename(): ask the caller to chose the kind of diagnosis
sha1_name: do not trigger detailed diagnosis for file arguments
The documentation for "git cherry-pick A B..C" was misleading.
* cn/cherry-pick-range-docs:
git-cherry-pick.txt: clarify the use of revision range notation
Documentation: --no-walk is no-op if range is specified
"git archive" incorrectly computed the header checksum; the symptom
was observed only when using pathnames with hi-bit set.
* jc/ustar-checksum-is-unsigned:
archive: ustar header checksum is computed unsigned
Running "git bundle verify" on a bundle that records a complete
history said "it requires these 0 commits".
* jc/bundle-complete-notice:
tweak "bundle verify" of a complete history
"git ls-files --exclude=t -i" did not consider anything under t/ as
excluded, as it did not pay attention to exclusion of leading paths
while walking the index. Other two users of excluded() are also
updated.
* jc/ls-files-i-dir:
dir.c: make excluded() file scope static
unpack-trees.c: use path_excluded() in check_ok_to_remove()
builtin/add.c: use path_excluded()
path_excluded(): update API to less cache-entry centric
ls-files -i: micro-optimize path_excluded()
ls-files -i: pay attention to exclusion of leading paths
"git request-pull $url dev" when the tip of "dev" branch was tagged
with "ext4-for-linus" used the contents from the tag in the output
but still asked the "dev" branch to be pulled, not the tag.
* jc/request-pull-match-tagname:
request-pull: really favor a matching tag
We failed to use ce_namelen() equivalent and instead only compared
up to the CE_NAMEMASK bytes by mistake. Adding an overlong path
that shares the same common prefix as an existing entry in the index
did not add a new entry, but instead replaced the existing one, as
the result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the unpack_data function is given a consume() callback,
it unpacks only 64K of the input at a time, feeding it to
git_inflate along with a 64K output buffer. However,
because we are inflating, there is a good chance that the
output buffer will fill before consuming all of the input.
In this case, we need to loop on git_inflate until we have
fed the whole input buffer, feeding each chunk of output to
the consume buffer.
The current code does not do this, and as a result, will
fail the loop condition and trigger a fatal "serious inflate
inconsistency" error in this case.
While we're rearranging the loop, let's get rid of the
extra last_out pointer. It is meant to point to the
beginning of the buffer that we feed to git_inflate, but in
practice this is always the beginning of our same 64K
buffer, because:
1. At the beginning of the loop, we are feeding the
buffer.
2. At the end of the loop, if we are using a consume()
function, we reset git_inflate's pointer to the
beginning of the buffer. If we are not using a
consume() function, then we do not care about the value
of last_out at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we do not have any pathspec, we typically disallow an
explicit "--only", because it makes no sense (your commit
would, by definition, be empty). But since 6a74642
(git-commit --amend: two fixes., 2006-04-20), we have
allowed "--amend --only" with the intent that it would amend
the commit, ignoring any contents staged in the index.
However, while that commit allowed the combination, we never
actually implemented the logic to make it work. The current
code notices that we have no pathspec and assumes we want to
do an as-is commit (i.e., the "--only" is ignored).
Instead, we must make sure to follow the partial-commit
code-path. We also need to tweak the list_paths function to
handle a NULL pathspec.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We should be letting the user's umask take care of
restricting permissions. Even though this is a temporary
file and probably nobody would notice, this brings us in
line with other temporary file creations in git (e.g.,
choosing "e"dit from git-add--interactive).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
