* mm/maint-add-p-quit:
Update git-add.txt according to the new possibilities of 'git add -p'.
add-interactive: refactor mode hunk handling
git add -p: new "quit" command at the prompt.
The original implementation considered the mode separately
from the rest of the hunks, asking about it outside the main
hunk-selection loop. This patch instead places a mode change
as the first hunk in the loop. This has two advantages:
1. less duplicated code (since we use the main selection
loop). This also cleans up an inconsistency, which is
that the main selection loop separates options with a
comma, whereas the mode prompt used slashes.
2. users can now skip the mode change and come back to it,
search for it (via "/mode"), etc, as they can with other
hunks.
To facilitate this, each hunk is now marked with a "type".
Mode hunks are not considered for splitting (which would
make no sense, and also confuses the split_hunk function),
nor are they editable. In theory, one could edit the mode
lines and change to a new mode. In practice, there are only
two modes that git cares about (0644 and 0755), so either
you want to move from one to the other or not (and you can
do that by staging or not staging).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's already 'd' to stop staging hunks in a file, but no explicit
command to stop the interactive staging (for the current files and the
remaining ones). Of course you can do 'd' and then ^C, but it would be
more intuitive to allow 'quit' action.
Instead of doing the (potentially very expensive) "in_merge_base()"
check for each commit that might be pruned if it is unreachable, do a
preparatory reachability graph of the commit space, so that the common
case of being reachable can be tested directly.
[ Cleaned up a bit and tweaked to actually work. - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'bs/maint-1.6.0-tree-walk-prefix' into maint
* bs/maint-1.6.0-tree-walk-prefix:
match_tree_entry(): a pathspec only matches at directory boundaries
tree_entry_interesting: a pathspec only matches at directory boundary
Merge branch 'cb/maint-merge-recursive-submodule-fix' into maint
* cb/maint-merge-recursive-submodule-fix:
simplify output of conflicting merge
update cache for conflicting submodule entries
add tests for merging with submodules
Update docs on behaviour of 'core.sharedRepository' and 'git init --shared'
This documentation update is needed to reflect the recent changes where
"core.sharedRepository = 0mode" was changed to set, not loosen, the
repository permissions.
Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/gitattributes: clarify location of config text
The gitattributes documentation has a section on the "diff"
attribute, with subsections for each of the things you might
want to configure in your diff config section (external
diff, hunk headers, etc). The first such subsection
specifically notes that the definition of the diff driver
should go into $GIT_DIR/config, but subsequent sections do
not.
This location is implied if you are reading the
documentation sequentially, but it is not uncommon for a new
user to jump to (or be referred to) a specific section. For
a new user who does not know git well enough to recognize
the config syntax, it is not clear that those directives
don't also go into the gitattributes file.
This patch just mentions the config file in each subsection,
similar to the way it is mentioned in the first.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).
Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.
The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)
Read: Thanks to Johannes Sixt for the correct printf call
which replaces the perl invocation.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Wed, 8 Apr 2009, Björn Steinbrink wrote:
>
> The name of the processed object was duplicated for passing it to
> add_object(), but that already calls path_name, which allocates a new
> string anyway. So the memory allocated by the xstrdup calls just went
> nowhere, leaking memory.
Ack, ack.
There's another easy 5% or so for the built-in object walker: once we've
created the hash from the name, the name isn't interesting any more, and
so something trivial like this can help a bit.
Does it matter? Probably not on its own. But a few more memory saving
tricks and it might all make a difference.
This test was added recently (5a688fe, "core.sharedrepository = 0mode"
should set, not loosen; 2009-03-28). It checked the result of a sed
invocation for emptyness, but in some cases it forgot to print anything
at all, so that those checks would never be false.
Due to this mistake, it went unnoticed that the files in objects/info are
not necessarily 0440, but can also be 0660. Because the 0mode setting
tries to guarantee that the files are accessible only to the people they
are meant to be used by, we should only make sure that they are readable
by the user and the group when the configuration is set to 0660. It is a
separate matter from the core.shredrepository settings that w-bit from
immutable object files under objects/[0-9a-f][0-9a-f] directories should
be dropped.
COMMIT_EDITMSG is still world-readable, but it (and any transient files
that are meant for repositories with a work tree) does not matter. If you
are working on a shared machine and on a sekrit stuff, the root of the
work tree would be with mode 0700 (or 0750 to allow peeking by other
people in the group), and that would mean that .git/COMMIT_EDITMSG in such
a repository would not be readable by the strangers anyway.
Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an
arbitrary editor the user happens to use, and we have no guarantee what it
does (e.g. it may create a new file with umask and replace, it may rewrite
in place, it may leave an editor backup file but use umask to create it,
etc.), and the protection of the file lies majorly on the protection of
the root of the work tree.
This test cannot be run on Windows; it requires POSIXPERM when merged to
'master'.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/shared-literally:
t1301: loosen test for forced modes
set_shared_perm(): sometimes we know what the final mode bits should look like
move_temp_to_file(): do not forget to chmod() in "Coda hack" codepath
Move chmod(foo, 0444) into move_temp_to_file()
"core.sharedrepository = 0mode" should set, not loosen
Merge branch 'jc/maint-1.6.0-keep-pack' into maint
* jc/maint-1.6.0-keep-pack:
pack-objects: don't loosen objects available in alternate or kept packs
t7700: demonstrate repack flaw which may loosen objects unnecessarily
Remove --kept-pack-only option and associated infrastructure
pack-objects: only repack or loosen objects residing in "local" packs
git-repack.sh: don't use --kept-pack-only option to pack-objects
t7700-repack: add two new tests demonstrating repacking flaws
is_kept_pack(): final clean-up
Simplify is_kept_pack()
Consolidate ignore_packed logic more
has_sha1_kept_pack(): take "struct rev_info"
has_sha1_pack(): refactor "pretend these packs do not exist" interface
git-repack: resist stray environment variable
The name of the processed object was duplicated for passing it to
add_object(), but that already calls path_name, which allocates a new
string anyway. So the memory allocated by the xstrdup calls just went
nowhere, leaking memory.
This reduces the RSS usage for a "rev-list --all --objects" by about 10% on
the gentoo repo (fully packed) as well as linux-2.6.git:
gentoo:
| old | new
----------------|-------------------------------
RSS | 1537284 | 1388408
VSZ | 1816852 | 1667952
time elapsed | 1:49.62 | 1:48.99
min. page faults| 417178 | 379919
linux-2.6.git:
| old | new
----------------|-------------------------------
RSS | 324452 | 292996
VSZ | 491792 | 460376
time elapsed | 0:14.53 | 0:14.28
min. page faults| 89360 | 81613
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-pull.sh: better warning message for "git pull" on detached head.
Otherwise, git complains about not finding a branch to pull from in
'branch..merge', which is hardly understandable. While we're there,
reword the sentences slightly.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.1:
Documentation: clarify .gitattributes search
git-checkout.txt: clarify that <branch> applies when no path is given.
git-checkout.txt: fix incorrect statement about HEAD and index
Most of the time when we give branch name in the message, we quote it
inside a pair of single-quotes. git-checkout uses double-quotes; this
patch corrects the inconsistency.
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.0:
Documentation: clarify .gitattributes search
git-checkout.txt: clarify that <branch> applies when no path is given.
git-checkout.txt: fix incorrect statement about HEAD and index
git-checkout.txt: fix incorrect statement about HEAD and index
The command "git checkout" checks out from the index by default, not
HEAD (the introducing comment were correct, but the detailled
explanation added below were not).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously we ignored the result of calling add_interactive,
which meant that if an error occurred we simply committed
whatever happened to be in the index.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When merging merge bases during a recursive merge we do not want to
leave any unmerged entries. Otherwise we cannot create a temporary
tree for the recursive merge to work with.
We failed to do so in case of a submodule conflict between merge
bases, causing a NULL pointer dereference in the next step of the
recursive merge.
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix 'git checkout <submodule>' to update the index
While 'git checkout <submodule>' should not update the submodule's
working directory, it should update the index. This is in line with
how submodules are handled in the rest of Git.
While at it, test 'git reset [<commit>] <submodule>', too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dm/maint-docco:
Documentation: Remove spurious uses of "you" in git-bisect.txt.
Documentation: minor grammatical fix in git-check-ref-format.txt
Documentation: minor grammatical fixes in git-check-attr.txt
Documentation: minor grammatical fixes in git-cat-file.txt
Documentation: minor grammatical fixes and rewording in git-bundle.txt
Documentation: remove some uses of the passive voice in git-bisect.txt
Documentation: reword example text in git-bisect.txt.
Documentation: reworded the "Description" section of git-bisect.txt.
Documentation: minor grammatical fixes in git-branch.txt.
Documentation: minor grammatical fixes in git-blame.txt.
Documentation: reword the "Description" section of git-bisect.txt.
Documentation: minor grammatical fixes in git-archive.txt.
One of the aspects of the test checked explicitly for the
g+s bit to be set on created directories. However, this is
only the means to an end (the "end" being having the correct
group set). And in fact, on systems where
DIR_HAS_BSD_GROUP_SEMANTICS is set, we do not even need to
use this "means" at all, causing the test to fail.
This patch removes that part of the test. In an ideal world
it would be replaced by a test to check that the group was
properly assigned, but that is difficult to automate because
it requires the user running the test suite be a member of
multiple groups.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
mailmap: resurrect lower-casing of email addresses
Commit 0925ce4(Add map_user() and clear_mailmap() to mailmap) broke the
lower-casing of email addresses. This mostly did not matter if your
.mailmap has only lower-case email addresses; However, we did not
require .mailmap to contain lowercase-only email addresses.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.1:
Fix bash completion in path with spaces
bash completion: only show 'log --merge' if merging
git-tag(1): add hint about commit messages
Documentation: update graph api example.
* maint-1.6.0:
Fix bash completion in path with spaces
bash completion: only show 'log --merge' if merging
git-tag(1): add hint about commit messages
Documentation: update graph api example.
Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com> Trivially-acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix ls-tree usage with dash-prefixed paths
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
Thanks to Anton Gyllenberg for pointing me toward the
Twisted repository as a real-world example of this case.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Embarrassingly, the common prefix calculation did not work properly, due
to a mistake in the assignment: instead of assigning the dirname of the
current file name, the dirname of the current common prefix needs to
be assigned to common prefix, when the current prefix does not match the
current file name.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
set_shared_perm(): sometimes we know what the final mode bits should look like
adjust_shared_perm() first obtains the mode bits from lstat(2), expecting
to find what the result of applying user's umask is, and then tweaks it
as necessary. When the file to be adjusted is created with mkstemp(3),
however, the mode thusly obtained does not have anything to do with user's
umask, and we would need to start from 0444 in such a case and there is no
point running lstat(2) for such a path.
This introduces a new API set_shared_perm() to bypass the lstat(2) and
instead force setting the mode bits to the desired value directly.
adjust_shared_perm() becomes a thin wrapper to the function.
move_temp_to_file(): do not forget to chmod() in "Coda hack" codepath
Now move_temp_to_file() is responsible for doing everything that is
necessary to turn a tempfile in $GIT_DIR into its final form, it must make
sure "Coda hack" codepath correctly makes the file read-only.
When writing out a loose object or a pack (index), move_temp_to_file() is
called to finalize the resulting file. These files (loose files and packs)
should all have permission mode 0444 (modulo adjust_shared_perm()).
Therefore, instead of doing chmod(foo, 0444) explicitly from each callsite
(or even forgetting to chmod() at all), do the chmod() call from within
move_temp_to_file().
Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"core.sharedrepository = 0mode" should set, not loosen
This fixes the behaviour of octal notation to how it is defined in the
documentation, while keeping the traditional "loosen only" semantics
intact for "group" and "everybody".
Three main points of this patch are:
- For an explicit octal notation, the internal shared_repository variable
is set to a negative value, so that we can tell "group" (which is to
"OR" in 0660) and 0660 (which is to "SET" to 0660);
- git-init did not set shared_repository variable early enough to affect
the initial creation of many files, notably copied templates and the
configuration. We set it very early when a command-line option
specifies a custom value.
- Many codepaths create files inside $GIT_DIR by various ways that all
involve mkstemp(), and then call move_temp_to_file() to rename it to
its final destination. We can add adjust_shared_perm() call here; for
the traditional "loosen-only", this would be a no-op for many codepaths
because the mode is already loose enough, but with the new behaviour it
makes a difference.
Users were confused about the meaning and use of the --root option.
Notably, since 68c2ec7 (format-patch: show patch text for the root
commit, 2009-01-10), --root has nothing to do with showing the patch
text for the root commit any more.
Shorten and clarify the corresponding paragraph in the DESCRIPTION
section, document --root under OPTIONS, and add an explicit note that
root commits are formatted regardless.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --no-index: Do not generate patch output if other output is requested
Previously, 'git diff --no-index --stat a b' generated patch output in
addition to the --stat output (or whatever other output format was
requested). Now only the requested output is generated, and patch
output remains the default.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Increase the size of the die/warning buffer to avoid truncation
Long messages like those from lockfile.c when a lock can't be
obtained truncate with only 256 bytes in the message buffer.
Bump it to 1024 to give more space for these longer cases.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
avoid possible overflow in delta size filtering computation
On a 32-bit system, the maximum possible size for an object is less than
4GB, while 64-bit systems may cope with larger objects. Due to this
limitation, variables holding object sizes are using an unsigned long
type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
When large objects are encountered, and/or people play with large delta
depth values, it is possible for the maximum allowed delta size
computation to overflow, especially on a 32-bit system. When this
occurs, surviving result bits may represent a value much smaller than
what it is supposed to be, or even zero. This prevents some objects
from being deltified although they do get deltified when a smaller depth
limit is used. Fix this by always performing a 64-bit multiplication.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>