Commit Graph

7315 Commits

Author SHA1 Message Date
Jeff King
7b6257b0d4 add test for streaming corrupt blobs
We do not have many tests for handling corrupt objects. This
new test at least checks that we detect a byte error in a
corrupt blob object while streaming it out with cat-file.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 13:47:06 -07:00
Junio C Hamano
870987dec7 Merge branch 'jk/fully-peeled-packed-ref'
Not that we do not actively encourage having annotated tags outside
refs/tags/ hierarchy, but they were not advertised correctly to the
ls-remote and fetch with recent version of Git.

* jk/fully-peeled-packed-ref:
  pack-refs: add fully-peeled trait
  pack-refs: write peeled entry for non-tags
  use parse_object_or_die instead of die("bad object")
  avoid segfaults on parse_object failure
2013-03-25 14:01:07 -07:00
Junio C Hamano
62bd0c0105 Merge branch 'jk/peel-ref'
Recent optimization broke shallow clones.

* jk/peel-ref:
  upload-pack: load non-tip "want" objects from disk
  upload-pack: make sure "want" objects are parsed
  upload-pack: drop lookup-before-parse optimization
2013-03-25 14:01:03 -07:00
Junio C Hamano
33c1506d62 Merge branch 'ph/tag-force-no-warn-on-creation'
"git tag -f <tag>" always said "Updated tag '<tag>'" even when
creating a new tag (i.e. not overwriting nor updating).

* ph/tag-force-no-warn-on-creation:
  tag: --force does not have to warn when creating tags
2013-03-25 14:00:58 -07:00
Junio C Hamano
9b12c6ed77 Merge branch 'pw/p4-symlinked-root'
"git p4" did not behave well when the path to the root of the P4
client was not its real path.

* pw/p4-symlinked-root:
  git p4: avoid expanding client paths in chdir
  git p4 test: should honor symlink in p4 client root
  git p4 test: make sure P4CONFIG relative path works
2013-03-25 14:00:50 -07:00
Junio C Hamano
63868f636f Merge branch 'jk/empty-archive'
"git archive" reports a failure when asked to create an archive out
of an empty tree.  It would be more intuitive to give an empty
archive back in such a case.

* jk/empty-archive:
  archive: handle commits with an empty tree
  test-lib: factor out $GIT_UNZIP setup
2013-03-25 14:00:48 -07:00
Junio C Hamano
573f1a9cf1 Merge branch 'ks/rfc2047-one-char-at-a-time'
When "format-patch" quoted a non-ascii strings on the header files,
it incorrectly applied rfc2047 and chopped a single character in
the middle of it.

* ks/rfc2047-one-char-at-a-time:
  format-patch: RFC 2047 says multi-octet character may not be split
2013-03-25 14:00:46 -07:00
Junio C Hamano
fb3b7b1f95 Merge branch 'jk/alias-in-bare'
An aliased command spawned from a bare repository that does not say
it is bare with "core.bare = yes" is treated as non-bare by mistake.

* jk/alias-in-bare:
  setup: suppress implicit "." work-tree for bare repos
  environment: add GIT_PREFIX to local_repo_env
  cache.h: drop LOCAL_REPO_ENV_SIZE
2013-03-25 14:00:44 -07:00
Junio C Hamano
55f6fbef3d Merge branch 'jc/push-follow-tag'
The new "--follow-tags" option tells "git push" to push relevant
annotated tags when pushing branches out.

* jc/push-follow-tag:
  push: --follow-tags
  commit.c: use clear_commit_marks_many() in in_merge_bases_many()
  commit.c: add in_merge_bases_many()
  commit.c: add clear_commit_marks_many()
2013-03-25 14:00:41 -07:00
Junio C Hamano
caf217a3b8 Merge branch 'ap/maint-diff-rename-avoid-overlap'
The logic used by "git diff -M --stat" to shorten the names of
files before and after a rename did not work correctly when the
common prefix and suffix between the two filenames overlapped.

* ap/maint-diff-rename-avoid-overlap:
  tests: make sure rename pretty print works
  diff: prevent pprint_rename from underrunning input
  diff: Fix rename pretty-print when suffix and prefix overlap
2013-03-25 14:00:37 -07:00
Junio C Hamano
b03b41e24c Merge branch 'jl/submodule-deinit'
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init".  "submodule deinit" is the way to do so.

* jl/submodule-deinit:
  submodule: add 'deinit' command
2013-03-25 14:00:29 -07:00
Junio C Hamano
a8aa360017 Merge branch 'pe/pull-rebase-v-q'
Teach "git pull --rebase" to pass "-v/-q" command line options to
underlying "git rebase".

* pe/pull-rebase-v-q:
  pull: Apply -q and -v options to rebase mode as well
2013-03-25 13:58:34 -07:00
Junio C Hamano
28ed8d7be9 Merge branch 'we/submodule-update-prefix-output'
"git submodule update", when recursed into sub-submodules, did not
acccumulate the prefix paths.

* we/submodule-update-prefix-output:
  submodule update: when using recursion, show full path
2013-03-21 14:03:10 -07:00
Junio C Hamano
e9bebbb67c Merge branch 'rs/zip-compresssed-size-with-export-subst'
When export-subst is used, "zip" output recorded incorrect
size of the file.

* rs/zip-compresssed-size-with-export-subst:
  archive-zip: fix compressed size for stored export-subst files
2013-03-21 14:03:04 -07:00
Junio C Hamano
dcf0d12aed Merge branch 'rt/commit-cleanup-config'
Fix tests that contaminated their environments and affected new
tests introduced later in the sequence by containing their effects
in their own subshells.

* rt/commit-cleanup-config:
  t7502: perform commits using alternate editor in a subshell
2013-03-21 14:02:53 -07:00
Junio C Hamano
42e129f47a Merge branch 'nd/branch-error-cases'
"git branch" had more cases where it did not bother to check
nonsense command line parameters.

* nd/branch-error-cases:
  branch: segfault fixes and validation
2013-03-21 14:02:51 -07:00
Junio C Hamano
98ed062a92 Merge branch 'da/difftool-fixes'
Minor maintenance updates to difftool, and updates to its tests.

* da/difftool-fixes:
  t7800: "defaults" is no longer a builtin tool name
  t7800: modernize tests
  t7800: update copyright notice
  difftool: silence uninitialized variable warning
2013-03-21 14:02:44 -07:00
Junio C Hamano
54797b98b8 Merge branch 'bc/commit-complete-lines-given-via-m-option'
'git commit -m "$str"' when $str was already terminated with a LF
now avoids adding an extra LF to the message.

* bc/commit-complete-lines-given-via-m-option:
  Documentation/git-commit.txt: rework the --cleanup section
  git-commit: only append a newline to -m mesg if necessary
  t7502: demonstrate breakage with a commit message with trailing newlines
  t/t7502: compare entire commit message with what was expected
2013-03-21 14:02:37 -07:00
Junio C Hamano
f5715de54a Merge branch 'nd/count-garbage'
"git count-objects -v" did not count leftover temporary packfiles
and other kinds of garbage.

* nd/count-garbage:
  count-objects: report how much disk space taken by garbage files
  count-objects: report garbage files in pack directory too
  sha1_file: reorder code in prepare_packed_git_one()
  git-count-objects.txt: describe each line in -v output
2013-03-21 14:02:34 -07:00
Junio C Hamano
e4e1c54990 Merge branch 'jc/fetch-raw-sha1'
Allows requests to fetch objects at any tip of refs (including
hidden ones).  It seems that there may be use cases even outside
Gerrit (e.g. $gmane/215701).

* jc/fetch-raw-sha1:
  fetch: fetch objects by their exact SHA-1 object names
  upload-pack: optionally allow fetching from the tips of hidden refs
  fetch: use struct ref to represent refs to be fetched
  parse_fetch_refspec(): clarify the codeflow a bit
2013-03-21 14:02:27 -07:00
Junio C Hamano
5d04924e19 Merge branch 'tb/document-status-u-tradeoff'
Suggest users to look into using--untracked=no option when "git
status" takes too long.

* tb/document-status-u-tradeoff:
  status: advise to consider use of -u when read_directory takes too long
  git status: document trade-offs in choosing parameters to the -u option
2013-03-21 14:02:10 -07:00
Junio C Hamano
4d5dcd976d Merge branch 'jc/add-2.0-u-A-sans-pathspec' (early part)
* 'jc/add-2.0-u-A-sans-pathspec' (early part):
  t2200: check that "add -u" limits itself to subdirectory
2013-03-19 12:21:27 -07:00
Junio C Hamano
c2bf648b84 Merge branch 'da/downcase-u-in-usage'
* da/downcase-u-in-usage:
  contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
  contrib/examples/git-remote.perl: use a lowercase "usage:" string
  tests: use a lowercase "usage:" string
  git-svn: use a lowercase "usage:" string
  Documentation/user-manual.txt: use a lowercase "usage:" string
  templates/hooks--update.sample: use a lowercase "usage:" string
  contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
  contrib/examples: use a lowercase "usage:" string
  contrib/fast-import/import-zips.py: use spaces instead of tabs
  contrib/fast-import/import-zips.py: fix broken error message
  contrib/fast-import: use a lowercase "usage:" string
  contrib/credential: use a lowercase "usage:" string
  git-cvsimport: use a lowercase "usage:" string
  git-cvsimport: use a lowercase "usage:" string
  git-cvsexportcommit: use a lowercase "usage:" string
  git-archimport: use a lowercase "usage:" string
  git-merge-one-file: use a lowercase "usage:" string
  git-relink: use a lowercase "usage:" string
  git-svn: use a lowercase "usage:" string
  git-sh-setup: use a lowercase "usage:" string
2013-03-19 12:15:54 -07:00
Michael Haggerty
c29c46fa2e pack-refs: add fully-peeled trait
Older versions of pack-refs did not write peel lines for
refs outside of refs/tags. This meant that on reading the
pack-refs file, we might set the REF_KNOWS_PEELED flag for
such a ref, even though we do not know anything about its
peeled value.

The previous commit updated the writer to always peel, no
matter what the ref is. That means that packed-refs files
written by newer versions of git are fine to be read by both
old and new versions of git. However, we still have the
problem of reading packed-refs files written by older
versions of git, or by other implementations which have not
yet learned the same trick.

The simplest fix would be to always unset the
REF_KNOWS_PEELED flag for refs outside of refs/tags that do
not have a peel line (if it has a peel line, we know it is
valid, but we cannot assume a missing peel line means
anything). But that loses an important optimization, as
upload-pack should not need to load the object pointed to by
refs/heads/foo to determine that it is not a tag.

Instead, we add a "fully-peeled" trait to the packed-refs
file. If it is set, we know that we can trust a missing peel
line to mean that a ref cannot be peeled. Otherwise, we fall
back to assuming nothing.

[commit message and tests by Jeff King <peff@peff.net>]

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-18 08:06:28 -07:00
Junio C Hamano
1c71541ddd Merge branch 'maint'
* maint:
  t1507: Test that branchname@{upstream} is interpreted as branch
2013-03-17 15:39:43 -07:00
Kacper Kornet
617cf93182 t1507: Test that branchname@{upstream} is interpreted as branch
Syntax branchname@{upstream} should interpret its argument as a name of
a branch. Add the test to check that it doesn't try to interpret it as a
refname if the branch in question does not exist.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17 15:38:23 -07:00
Jeff King
03a8eddfd1 pack-refs: write peeled entry for non-tags
When we pack an annotated tag ref, we write not only the
sha1 of the tag object along with the ref, but also the sha1
obtained by peeling the tag. This lets readers of the
pack-refs file know the peeled value without having to
actually load the object, speeding up upload-pack's ref
advertisement.

The writer marks a packed-refs file with peeled refs using
the "peeled" trait at the top of the file. When the reader
sees this trait, it knows that each ref is either followed
by its peeled value, or it is not an annotated tag.

However, there is a mismatch between the assumptions of the
reader and writer. The writer will only peel refs under
refs/tags, but the reader does not know this; it will assume
a ref without a peeled value must not be a tag object. Thus
an annotated tag object placed outside of the refs/tags
hierarchy will not have its peeled value printed by
upload-pack.

The simplest way to fix this is to start writing peel values
for all refs. This matches what the reader expects for both
new and old versions of git.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17 12:52:20 -07:00
Peter Eisentraut
ce4c4d4ec3 pull: Apply -q and -v options to rebase mode as well
git pull passed -q and -v only to git merge, but they can be useful for
git rebase as well, so pass them there, too.

In particular, using -q shuts up the "Already up-to-date." message.
Especially, a new test script runs the same "pull --rebase" twice to
make sure both cases are quiet, when it has something to fetch and
when it is already up to date.

Signed-off-by: Peter Eisentraut <peter@eisentraut.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16 23:30:08 -07:00
Jeff King
06f15bf1f3 upload-pack: make sure "want" objects are parsed
When upload-pack receives a "want" line from the client, it
adds it to an object array. We call lookup_object to find
the actual object, which will only check for objects already
in memory. This works because we are expecting to find
objects that we already loaded during the ref advertisement.

We use the resulting object structs for a variety of
purposes. Some of them care only about the object flags, but
others care about the type of the object (e.g.,
ok_to_give_up), or even feed them to the revision parser
(when --depth is used), which assumes that objects it
receives are fully parsed.

Once upon a time, this was OK; any object we loaded into
memory would also have been parsed. But since 435c833
(upload-pack: use peel_ref for ref advertisements,
2012-10-04), we try to avoid parsing objects during the ref
advertisement. This means that lookup_object may return an
object with a type of OBJ_NONE. The resulting mess depends
on the exact set of objects, but can include the revision
parser barfing, or the shallow code sending the wrong set of
objects.

This patch teaches upload-pack to parse each "want" object
as we receive it. We do not replace the lookup_object call
with parse_object, as the current code is careful not to let
just any object appear on a "want" line, but rather only one
we have previously advertised (whereas parse_object would
actually load any arbitrary object from disk).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16 22:16:56 -07:00
Nguyễn Thái Ngọc Duy
6a38ef2ced status: advise to consider use of -u when read_directory takes too long
Introduce advice.statusUoption to suggest considering use of -u to
strike different trade-off when it took more than 2 seconds to
enumerate untracked/ignored files.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16 21:44:58 -07:00
Jeff King
7bf7a92f69 t2200: check that "add -u" limits itself to subdirectory
This behavior is due to change in the future, but let's test
it anyway. That helps make sure we do not accidentally
switch the behavior too soon while we are working in the
area, and it means that we can easily verify the change when
we do make it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-14 08:24:12 -07:00
Phil Hord
3ae851e6fb tag: --force does not have to warn when creating tags
"git tag --force" mentions what old tag object is being replaced
when it is used to update an existing tag, but it shows the same
message when creating a new one.  Stop doing that, as it does not
add any information.

Add a test for this and also to ensure --force can replace tags at
all.

Signed-off-by: Phil Hord <hordp@cisco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13 10:35:15 -07:00
Miklós Fazekas
bbd848633e git p4: avoid expanding client paths in chdir
The generic chdir() helper sets the PWD environment
variable, as that is what is used by p4 to know its
current working directory.  Normally the shell would
do this, but in git-p4, we must do it by hand.

However, when the path contains a symbolic link,
os.getcwd() will return the physical location.  If the
p4 client specification includes symlinks, setting PWD
to the physical location causes p4 to think it is not
inside the client workspace.  It complains, e.g.

    Path /vol/bar/projects/foo/... is not under client root /p/foo

One workaround is to use AltRoots in the p4 client specification,
but it is cleaner to handle it directly in git-p4.

Other uses of chdir still require setting PWD to an
absolute path so p4 features like P4CONFIG work.  See
bf1d68f (git-p4: use absolute directory for PWD env
var, 2011-12-09).

[ pw: tweak patch and commit message ]

Thanks-to: John Keeping <john@keeping.me.uk>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11 15:03:11 -07:00
Pete Wyckoff
89773db3e8 git p4 test: should honor symlink in p4 client root
This test fails when the p4 client root includes
a symlink.  It complains:

    Path /vol/bar/projects/foo/... is not under client root /p/foo

and dumps a traceback.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11 15:02:59 -07:00
Jeff King
bd54cf17a4 archive: handle commits with an empty tree
git-archive relies on get_pathspec to convert its argv into
a list of pathspecs. When get_pathspec is given an empty
argv list, it returns a single pathspec, the empty string,
to indicate that everything matches. When we feed this to
our path_exists function, we typically see that the pathspec
turns up at least one item in the tree, and we are happy.

But when our tree is empty, we erroneously think it is
because the pathspec is too limited, when in fact it is
simply that there is nothing to be found in the tree. This
is a weird corner case, but the correct behavior is almost
certainly to produce an empty archive, not to exit with an
error.

This patch teaches git-archive to create empty archives when
there is no pathspec given (we continue to complain if a
pathspec is given, since it obviously is not matched). It
also confirms that the tar and zip writers produce sane
output in this instance.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-10 22:25:22 -07:00
Jeff King
f838ce5826 test-lib: factor out $GIT_UNZIP setup
We set up the $GIT_UNZIP variable and lazy prereq in
multiple places (and the next patch is about to add another
one). Let's factor it out to avoid repeating ourselves.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-10 20:06:19 -07:00
Junio C Hamano
407929cb45 Merge branch 'maint'
* maint:
  perf: update documentation of GIT_PERF_REPEAT_COUNT
2013-03-09 11:54:05 -08:00
Antoine Pelisse
ca70c9ea72 perf: update documentation of GIT_PERF_REPEAT_COUNT
Currently the documentation of GIT_PERF_REPEAT_COUNT says the default is
five while "perf-lib.sh" uses a value of three as a default.

Update the documentation so that it is consistent with the code.

Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-09 11:13:12 -08:00
Kirill Smelkov
6cd3c05327 format-patch: RFC 2047 says multi-octet character may not be split
Even though an earlier attempt (bafc478..41dd00bad) cleaned
up RFC 2047 encoding, pretty.c::add_rfc2047() still decides
where to split the output line by going through the input
one byte at a time, and potentially splits a character in
the middle.  A subject line may end up showing like this:

     ".... fö?? bar".   (instead of  ".... föö bar".)

if split incorrectly.

RFC 2047, section 5 (3) explicitly forbids such beaviour

    Each 'encoded-word' MUST represent an integral number of
    characters.  A multi-octet character may not be split across
    adjacent 'encoded- word's.

that means that e.g. for

    Subject: .... föö bar

encoding

    Subject: =?UTF-8?q?....=20f=C3=B6=C3=B6?=
     =?UTF-8?q?=20bar?=

is correct, and

    Subject: =?UTF-8?q?....=20f=C3=B6=C3?=      <-- NOTE ö is broken here
     =?UTF-8?q?=B6=20bar?=

is not, because "ö" character UTF-8 encoding C3 B6 is split here across
adjacent encoded words.

To fix the problem, make the loop grab one _character_ at a time and
determine its output length to see where to break the output line.  Note
that this version only knows about UTF-8, but the logic to grab one
character is abstracted out in mbs_chrlen() function to make it possible
to extend it to other encodings with the help of iconv in the future.

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-09 11:11:19 -08:00
Jeff King
2cd83d10bb setup: suppress implicit "." work-tree for bare repos
If an explicit GIT_DIR is given without a working tree, we
implicitly assume that the current working directory should
be used as the working tree. E.g.,:

  GIT_DIR=/some/repo.git git status

would compare against the cwd.

Unfortunately, we fool this rule for sub-invocations of git
by setting GIT_DIR internally ourselves. For example:

  git init foo
  cd foo/.git
  git status ;# fails, as we expect
  git config alias.st status
  git status ;# does not fail, but should

What happens is that we run setup_git_directory when doing
alias lookup (since we need to see the config), set GIT_DIR
as a result, and then leave GIT_WORK_TREE blank (because we
do not have one). Then when we actually run the status
command, we do setup_git_directory again, which sees our
explicit GIT_DIR and uses the cwd as an implicit worktree.

It's tempting to argue that we should be suppressing that
second invocation of setup_git_directory, as it could use
the values we already found in memory. However, the problem
still exists for sub-processes (e.g., if "git status" were
an external command).

You can see another example with the "--bare" option, which
sets GIT_DIR explicitly. For example:

  git init foo
  cd foo/.git
  git status ;# fails
  git --bare status ;# does NOT fail

We need some way of telling sub-processes "even though
GIT_DIR is set, do not use cwd as an implicit working tree".
We could do it by putting a special token into
GIT_WORK_TREE, but the obvious choice (an empty string) has
some portability problems.

Instead, we add a new boolean variable, GIT_IMPLICIT_WORK_TREE,
which suppresses the use of cwd as a working tree when
GIT_DIR is set. We trigger the new variable when we know we
are in a bare setting.

The variable is left intentionally undocumented, as this is
an internal detail (for now, anyway). If somebody comes up
with a good alternate use for it, and once we are confident
we have shaken any bugs out of it, we can consider promoting
it further.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08 14:02:40 -08:00
Pete Wyckoff
9e7b8efb9d git p4 test: make sure P4CONFIG relative path works
This adds a test for the fix in bf1d68f (git-p4: use absolute
directory for PWD env var, 2011-12-09).  It is necessary to
set PWD to an absolute path so that p4 can find files referenced
by non-absolute paths, like the value of the P4CONFIG environment
variable.

P4 does not open files directly; it builds a path by prepending
the contents of the PWD environment variable.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-07 16:00:49 -08:00
Junio C Hamano
5d4ef1721a Merge branch 'mh/maint-ceil-absolute' into maint
* mh/maint-ceil-absolute:
  Provide a mechanism to turn off symlink resolution in ceiling paths
2013-03-07 12:49:57 -08:00
Antoine Pelisse
b174eb42d0 tests: make sure rename pretty print works
Add basic use cases and corner cases tests for
"git diff -M --summary/stat".

Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-06 13:58:56 -08:00
Junio C Hamano
c2aba155da push: --follow-tags
The new option "--follow-tags" tells "git push" to push annotated
tags that are missing from the other side and that can be reached by
the history that is otherwise pushed out.

For example, if you are using the "simple", "current", or "upstream"
push, you would ordinarily push the history leading to the commit at
your current HEAD and nothing else.  With this option, you would
also push all annotated tags that can be reached from that commit to
the other side.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05 13:39:46 -08:00
Jens Lehmann
cf41982806 submodule: add 'deinit' command
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).

Help those users by providing a 'deinit' command. This removes the
whole submodule.<name> section from .git/config (either for the given
submodule(s) or for all those which have been initialized if '.' is used)
together with their work tree. Fail if the current work tree contains
modifications (unless forced), but don't complain when either the work
tree is already removed or no settings are found in .git/config.

Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him. Also add the deinit subcommand
to the completion list.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-04 14:48:02 -08:00
William Entriken
75bf5e60e8 submodule update: when using recursion, show full path
Previously when using update with recursion, only the path for the
inner-most module was printed. Now the path is printed relative to
the directory the command was started from. This now matches the
behavior of submodule foreach.

Signed-off-by: William Entriken <github.com@phor.net>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-03 19:46:54 -08:00
Junio C Hamano
06d67b8766 Sync with 1.8.1.5 2013-03-01 13:17:18 -08:00
Thomas Rast
8b1bd02415 Make !pattern in .gitattributes non-fatal
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'.  The docs, however, always said

  The rules how the pattern matches paths are the same as in
  `.gitignore` files; see linkgit:gitignore[5].

By those rules, leading '!' means pattern negation.  So 82dce99
correctly determined that this kind of line makes no sense and should
be disallowed.

However, users who actually had a rule for files starting with a '!'
are in a bad position: before 82dce99 '!' matched that literal
character, so it is conceivable that users have .gitattributes with
such lines in them.  After 82dce99 the unescaped version was
disallowed in such a way that git outright refuses to run(!) most
commands in the presence of such a .gitattributes.  It therefore
becomes very hard to fix, let alone work with, such repositories.

Let's at least allow the users to fix their repos: change the fatal
error into a warning.

Reported-by: mathstuf@gmail.com
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-01 12:24:45 -08:00
Junio C Hamano
3e07d2683d Merge branch 'mh/maint-ceil-absolute'
An earlier workaround designed to help people who list logical
directories that will not match what getcwd(3) returns in the
GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to
stat and readlink a directory component of an element listed on it.

* mh/maint-ceil-absolute:
  Provide a mechanism to turn off symlink resolution in ceiling paths
2013-02-27 09:47:28 -08:00
René Scharfe
d3c1472fe3 archive-zip: fix compressed size for stored export-subst files
Currently ZIP archive entries of files with export-subst attribute are
broken if they are stored uncompressed.

We get the size of a file from sha1_object_info(), but this number is
likely wrong for files whose contents are changed due to export-subst
placeholder expansion.  We use sha1_file_to_archive() to get the
expanded file contents and size in that case.  We proceed to use that
size for the uncompressed size field (good), but the compressed size
field is set based on the size from sha1_object_info() (bad).

This matters only for uncompressed files because for deflated files
we use the correct value after compression is done.  And for files
without export-subst expansion the sizes from sha1_object_info() and
sha1_file_to_archive() are the same, so they are unaffected as well.

This patch fixes the issue by setting the compressed size based on the
uncompressed size only after we actually know the latter.

Also make use of the test file substfile1 to check for the breakage;
it was only stored verbatim so far.  For that purpose, set the
attribute export-subst and replace its contents with the expected
expansion after committing.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27 07:38:32 -08:00