* tr/cache-tree:
reset: update cache-tree data when appropriate
commit: write cache-tree data when writing index anyway
Refactor cache_tree_update idiom from commit
Test the current state of the cache-tree optimization
Add test-scrap-cache-tree
* jc/stream-to-pack:
bulk-checkin: replace fast-import based implementation
csum-file: introduce sha1file_checkpoint
finish_tmp_packfile(): a helper function
create_tmp_packfile(): a helper function
write_pack_header(): a helper function
Conflicts:
pack.h
* nd/misc-cleanups:
unpack_object_header_buffer(): clear the size field upon error
tree_entry_interesting: make use of local pointer "item"
tree_entry_interesting(): give meaningful names to return values
read_directory_recursive: reduce one indentation level
get_tree_entry(): do not call find_tree_entry() on an empty tree
tree-walk.c: do not leak internal structure in tree_entry_len()
* maint-1.7.7:
Git 1.7.7.5
Git 1.7.6.5
blame: don't overflow time buffer
fetch: create status table using strbuf
checkout,merge: loosen overwriting untracked file check based on info/exclude
cast variable in call to free() in builtin/diff.c and submodule.c
apply: get rid of useless x < 0 comparison on a size_t type
Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
builtin/fetch.c
When showing the raw timestamp, we format the numeric
seconds-since-epoch into a buffer, followed by the timezone
string. This string has come straight from the commit
object. A well-formed object should have a timezone string
of only a few bytes, but we could be operating on data
pushed by a malicious user.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we fetch from a remote, we print a status table like:
From url
* [new branch] foo -> origin/foo
We create this table in a static buffer using sprintf. If
the remote refnames are long, they can overflow this buffer
and smash the stack.
Instead, let's use a strbuf to build the string.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/resolve-ref:
Copy resolve_ref() return value for longer use
Convert many resolve_ref() calls to read_ref*() and ref_exists()
Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c
refs.c
* jc/pull-signed-tag:
commit-tree: teach -m/-F options to read logs from elsewhere
commit-tree: update the command line parsing
commit: teach --amend to carry forward extra headers
merge: force edit and no-ff mode when merging a tag object
commit: copy merged signed tags to headers of merge commit
merge: record tag objects without peeling in MERGE_HEAD
merge: make usage of commit->util more extensible
fmt-merge-msg: Add contents of merged tag in the merge message
fmt-merge-msg: package options into a structure
fmt-merge-msg: avoid early returns
refs DWIMmery: use the same rule for both "git fetch" and others
fetch: allow "git fetch $there v1.0" to fetch a tag
merge: notice local merging of tags and keep it unwrapped
fetch: do not store peeled tag object names in FETCH_HEAD
Split GPG interface into its own helper library
Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c
* jc/request-pull-show-head-4:
request-pull: use the annotated tag contents
fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
environment.c: Fix an sparse "symbol not declared" warning
builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
fmt-merge-msg: use branch.$name.description
request-pull: use the branch description
request-pull: state what commit to expect
request-pull: modernize style
branch: teach --edit-description option
format-patch: use branch description in cover letter
branch: add read_branch_desc() helper function
Conflicts:
builtin/branch.c
Normally git tag strips tag message lines starting with '#', trailing
spaces from every line and empty lines from the beginning and end.
--cleanup allows to select different cleanup modes for tag message.
It provides the same interface as --cleanup option in git-commit.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After making fixes to the contents to be committed, it is not unusual to
update the current commit without rewording the message. Idioms to tell
"commit --amend" that we do not need an editor have been:
$ EDITOR=: git commit --amend
$ git commit --amend -C HEAD
but that was only because a more natural "--no-edit" option in
$ git commit --amend --no-edit
was not honoured.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the case of --mixed and --hard, we throw away the old index and
rebuild everything from the tree argument (or HEAD). So we have an
opportunity here to fill in the cache-tree data, just as read-tree
did.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In prepare_index(), we refresh the index, and then write it to disk if
this changed the index data. After running hooks we re-read the index
and compute the root tree sha1 with the cache-tree machinery.
This gives us a mostly free opportunity to write up-to-date cache-tree
data: we can compute it in prepare_index() immediately before writing
the index to disk.
If we do this, we were going to write the index anyway, and the later
cache-tree update has no further work to do. If we don't do it, we
don't do any extra work, though we still don't have have cache-tree
data after the commit.
The only case that suffers badly is when the pre-commit hook changes
many trees in the index. I'm writing this off as highly unusual.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We'll need to safely create or update the cache-tree data of the_index
from other places. While at it, give it an argument that lets us
silence the messages produced by unmerged entries (which prevent it
from working).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref() may return a pointer to a static buffer. Callers that
use this value longer than a couple of statements should copy the
value to avoid some hidden resolve_ref() call that may change the
static buffer's value.
The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c
demonstrates this. The first call is in cmd_merge()
branch = resolve_ref("HEAD", head_sha1, 0, &flag);
Then deep in lookup_commit_or_die() a few lines after, resolve_ref()
may be called again and destroy "branch".
lookup_commit_or_die
lookup_commit_reference
lookup_commit_reference_gently
parse_object
lookup_replace_object
do_lookup_replace_object
prepare_replace_object
for_each_replace_ref
do_for_each_ref
get_loose_refs
get_ref_dir
get_ref_dir
resolve_ref
All call sites are checked and made sure that xstrdup() is called if
the value should be saved.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/fsck-progress:
fsck: print progress
fsck: avoid reading every object twice
verify_packfile(): check as many object as possible in a pack
fsck: return error code when verify_pack() goes wrong
* nd/misc-cleanups:
unpack_object_header_buffer(): clear the size field upon error
tree_entry_interesting: make use of local pointer "item"
tree_entry_interesting(): give meaningful names to return values
read_directory_recursive: reduce one indentation level
get_tree_entry(): do not call find_tree_entry() on an empty tree
tree-walk.c: do not leak internal structure in tree_entry_len()
The comment on top of stripspace() claims that the buffer
will no longer be NUL-terminated. However, this has not been
the case at least since the move to using strbuf in 2007.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git apply is passed something that is not a patch, it does not produce
an error message or exit with a non-zero status if it was not actually
"applying" the patch i.e. --check or --numstat etc were supplied on the
command line.
Fix this by producing an error when apply fails to find any hunks whatsoever
while parsing the patch.
This will cause some of the output formats (--numstat, --diffstat, etc) to
produce an error when they formerly would have reported zero changes and
exited successfully. That seems like the correct behavior though. Failure
to recognize the input as a patch should be an error.
Plus, add a test.
Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This extends the earlier approach to stream a large file directly from the
filesystem to its own packfile, and allows "git add" to send large files
directly into a single pack. Older code used to spawn fast-import, but the
new bulk-checkin API replaces it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When on master, "git checkout -B master <commit>" is a more natural way to
say "git reset --keep <commit>", which was originally invented for the
exact purpose of moving to the named commit while keeping the local changes
around.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Overwriting the current branch with a different commit is forbidden, as it
will make the status recorded in the index and the working tree out of
sync with respect to the HEAD. There however is no reason to forbid it if
the current branch is renamed to itself, which admittedly is something
only an insane user would do, but is handy for scripts.
Test script is by Conrad Irwin.
Reported-by: Soeren Sonnenburg <sonne@debian.org>
Reported-by: Josh Chia (谢任中)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ignored files usually are generated files (e.g. .o files) and can be
safely discarded. However sometimes users may have important files in
working directory, but still want a clean "git status", so they mark
them as ignored files. But in this case, these files should not be
overwritten without asking first.
Enable this use case with --no-overwrite-ignore, where git only sees
tracked and untracked files, no ignored files. Those who mix
discardable ignored files with important ones may have to sort it out
themselves.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back in 1127148 (Loosen "working file will be lost" check in
Porcelain-ish - 2006-12-04), git-checkout.sh learned to quietly
overwrite ignored files. Howver the code only took .gitignore files
into account.
Standard ignored files include all specified in .gitignore files in
working directory _and_ $GIT_DIR/info/exclude. This patch makes sure
ignored files in info/exclude can also be overwritten automatically in
the spirit of the original patch.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option --force should not put us in 'create branch' mode. The
fact that this option is only valid in 'create branch' mode is
already caught by the the next 'if' in which we assure that we
are in the correct mode.
Without this patch, "git branch -f" without any other argument ends
up calling create_branch without any branch name.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "git cherry-pick --abort" command currently renames the
.git/sequencer directory to .git/sequencer-old instead of removing it
on success due to an accident. cherry-pick --abort is designed to
work in three steps:
1) find which commit to roll back to
2) call "git reset --merge <commit>" to move to that commit
3) remove the .git/sequencer directory
But the careless author forgot step 3 entirely. The only reason the
command worked anyway is that "git reset --merge <commit>" renames the
.git/sequencer directory as a secondary effect --- after moving to
<commit>, or so the logic goes, it is unlikely but possible that the
caller of git reset wants to continue the series of cherry-picks that
was in progress, so git renames the sequencer state to
.git/sequencer-old to be helpful while allowing the cherry-pick to be
resumed if the caller did not want to end the sequence after all.
By running "git cherry-pick --abort", the operator has clearly
indicated that she is not planning to continue cherry-picking. Remove
the (renamed) .git/sequencer directory as intended all along.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, it is not possible to rename or remove a directory that has
open files. 'revert --abort' renamed .git/sequencer when it still had
.git/sequencer/head open. Close the file as early as possible to allow
the rename operation on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
