The output of 'tar tv' varies from system to system. In
particular, the t5000 was expecting to parse the date from
something like:
-rw-rw-r-- root/root 0 2008-05-13 04:27 file
but FreeBSD's tar produces this:
-rw-rw-r-- 0 root root 0 May 13 04:27 file
Instead of relying on tar's output, let's just extract the
file using tar and stat the result using perl.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On some shells (notably /bin/sh on FreeBSD 6.1), the
construct
foo && ! bar | baz
is true if
foo && baz
whereas for most other shells (such as bash) is true if
foo && ! baz
We can work around this by specifying
foo && ! (bar | baz)
which works everywhere.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lt/core-optim:
Optimize symlink/directory detection
Avoid some unnecessary lstat() calls
is_racy_timestamp(): do not check timestamp for gitlinks
diff-lib.c: rename check_work_tree_entity()
diff: a submodule not checked out is not modified
Add t7506 to test submodule related functions for git-status
t4027: test diff for submodule with empty directory
Make git-add behave more sensibly in a case-insensitive environment
When adding files to the index, add support for case-independent matches
Make unpack-tree update removed files before any updated files
Make branch merging aware of underlying case-insensitive filsystems
Add 'core.ignorecase' option
Make hash_name_lookup able to do case-independent lookups
Make "index_name_exists()" return the cache_entry it found
Move name hashing functions into a file of its own
Make unpack_trees_options bit flags actual bitfields
Before this patch, when "git rev-parse --verify" was passed at least one
good rev and then anything, it would output something for the good rev
even if it would latter exit on error.
With this patch, we only output something if everything is ok.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, something like:
$ git rev-parse --verify HEAD --default master
did not work, while:
$ git rev-parse --default master --verify HEAD
worked.
This patch fixes that, so that they both work (assuming
HEAD and master can be parsed).
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch documents the current behavior of "git rev-parse --verify".
This command is tested both with and without the "--quiet" and
"--default" options.
This shows some problems with the current behavior that will be fixed
in latter patches:
- in case of errors, there should be no good rev output on
stdout,
- with "--default" one test case is broken
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change cd67e4d4 introduced a new configuration parameter that told
pull to automatically perform a rebase instead of a merge. This
change provides a configuration option to enable this feature
automatically when creating a new branch.
If the variable branch.autosetuprebase applies for a branch that's
being created, that branch will have branch.<name>.rebase set to true.
Signed-off-by: Dustin Sallings <dustin@spy.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this, git svn clone -s http://svn.gnome.org/svn/gtk+
is successful.
Also modified the funky rename test for this, which _does_
include escaped '+' signs for HTTP URLs. SVN seems to accept
either "+" or "%2B" in filenames and directories (just not the
main URL), so I'll leave it alone for now.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* py/diff-submodule:
is_racy_timestamp(): do not check timestamp for gitlinks
diff-lib.c: rename check_work_tree_entity()
diff: a submodule not checked out is not modified
Add t7506 to test submodule related functions for git-status
t4027: test diff for submodule with empty directory
Before this patch no error was printed when "git rev-list --bisect-vars"
failed. This can happen when bad and good revs are mistaken.
This patch prints an error message on stderr that describe the likely
failure cause.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lh/git-file:
Teach GIT-VERSION-GEN about the .git file
Teach git-submodule.sh about the .git file
Teach resolve_gitlink_ref() about the .git file
Add platform-independent .git "symlink"
* lh/branch-merged:
Add tests for `branch --[no-]merged`
git-branch.txt: compare --contains, --merged and --no-merged
git-branch: add support for --merged and --no-merged
If a branch named "bisect" or "new-bisect" already was created in the
repo by other means than git bisect, doing a git bisect used to override
the branch without a warning. Now if the branch "bisect" or
"new-bisect" already exists, and it was not created by git bisect itself,
git bisect start fails with an appropriate error message. Additionally,
if checking out a new bisect state fails due to a merge problem, git
bisect cleans up the temporary branch "new-bisect".
The accidental override has been noticed by Andres Salomon, reported
through
http://bugs.debian.org/478647
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because we do not even check the timestamp to determie if a gitlink
is up to date or not, triggering the racy-timestamp check for gitlinks
does not make sense.
This fixes the recently added test in t7506.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
948dd34 (diff-index: careful when inspecting work tree items, 2008-03-30)
made the work tree check careful not to be fooled by a new directory that
exists at a place the index expects a blob. For such a change to be a
typechange from blob to submodule, the new directory has to be a
repository.
However, if the index expects a submodule there, we should not insist the
work tree entity to be a repository --- a simple directory that is not a
full fledged repository (even an empty directory would do) should be
considered an unmodified subproject, because that is how a superproject
with a submodule is checked out sparsely by default.
This makes the function check_work_tree_entity() even more careful not to
report a submodule that is not checked out as removed. It fixes the
recently added test in t4027.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of rename limiting is to bound the amount of time
we spend figuring out inexact renames. Currently we use a
single value, diff.renamelimit, for all situations. However,
it is probably the case that a user is willing to spend more
time finding renames during a merge than they are while
looking at git-log.
This patch provides a way of setting those values separately
(though for backwards compatibility, merge still falls back
on the diff renamelimit).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a nice side effect it also fixes t2002-checkout-cache-u.sh on FreeBSD 4,
/bin/sh of which has problems interpreting "! command" construction.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone [options] $src $dst excess-garbage" simply ignored
excess-garbage without giving any diagnostic message. Fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
remote: create fetch config lines with '+'
push: allow unqualified dest refspecs to DWIM
doc/git-gc: add a note about what is collected
t5516: remove ambiguity test (1)
Linked glossary from cvs-migration page
write-tree: properly detect failure to write tree objects
Since git-remote always uses remote tracking branches, it
should be safe to always force updates of those branches.
I.e., we should generate
fetch = +refs/heads/*:refs/remotes/$remote/*
instead of
fetch = refs/heads/*:refs/remotes/$remote/*
This was the behavior of the perl version, which seems to
have been lost in the C rewrite.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, a push like:
git push remote src:dst
would go through the following steps:
1. check for an unambiguous 'dst' on the remote; if it
exists, then push to that ref
2. otherwise, check if 'dst' begins with 'refs/'; if it
does, create a new ref
3. otherwise, complain because we don't know where in the
refs hierarchy to put 'dst'
However, in some cases, we can guess about the ref type of
'dst' based on the ref type of 'src'. Specifically, before
complaining we now check:
2.5. if 'src' resolves to a ref starting with refs/heads
or refs/tags, then prepend that to 'dst'
So now this creates a new branch on the remote, whereas it
previously failed with an error message:
git push master:newbranch
Note that, by design, we limit this DWIM behavior only to
source refs which resolve exactly (including symrefs which
resolve to existing refs). We still complain on a partial
destination refspec if the source is a raw sha1, or a ref
expression such as 'master~10'.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test tried to push into a remote with ambiguous refs in
remotes/$x/master and remotes/$y/master. However, the remote
never actually tells us about the refs/remotes hierarchy, so
we don't even see this ambiguity.
The test happened to pass because we were simply looking for
failure, and the test fails for another reason: the dst
refspec does not exist and does not begin with refs/, making
it invalid.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tomasz Fortuna reported that "git commit" does not error out properly when
it cannot write tree objects out. "git write-tree" shares the same issue,
as the failure to notice the error is deep in the logic to write tree
objects out recursively.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Amend git-push refspec documentation
git-gc --prune is deprecated
svn-git: Use binmode for reading/writing binary rev maps
diff options documentation: refer to --diff-filter in --name-status
Don't force imap.host to be set when imap.tunnel is set
git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc
git-svn bug with blank commits and author file
archive.c: format_subst - fixed bogus argument to memchr
copy.c: copy_fd - correctly report write errors
gitattributes: Fix subdirectory attributes specified from root directory
This patch adds a remote.*.mirror configuration option that,
when set, automatically puts git-push in --mirror mode for that
remote.
Furthermore, the option is set automatically by `git remote
add --mirror'.
The code in remote.c to parse remote.*.skipdefaultupdate
had a subtle problem: a comment in the code indicated that
special care was needed for boolean options, but this care was
not used in parsing the option. Since I was touching related
code, I did this fix too.
[jc: and I further fixed up the "ignore boolean" code.]
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
gitweb: Fix 'history' view for deleted files with history
Document that WebDAV doesn't need git on the server, and works over SSL
git-remote: reject adding remotes with invalid names
am: POSIX portability fix
When asked for history of a file which is not present in given branch
("HEAD", i.e. current branch, or given by transient $hash_hase ('hb')
parameter), but is present deeper in the history (meaning that "git
rev-list --full-history $hash_base -- $file_name" is not empty), and
there is no $hash ('h') parameter set for a file, gitweb would spew
multiple of "Use of uninitialized value" warnings, and some links
would be missing. This commit fixes this bug.
This bug occurs in the rare cases when "git log -- <path>" is empty
and "git log --full-history -- <path>" is not, or to be more exact in
the cases when full-history starts later than given branch. It can
happen if you are using handcrafted gitwb URL, or if you follow
generic 'history' link or bookmark for a file which got deleted.
Gitweb tried to get file type ('tree', or 'blob', or even 'commit')
from the commit we start searching from (where the file was not
present), and not among found commits. This was the cause of "Use of
uninitialized value" warnings.
This commit also add tests for such situation to t9500 test.
While we are it, return HTTP error if there is _no_ history; it means
that file or directory was not found (for given branch). Also error
out if type of item could not be found: it should not happen now, but
better be sure.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This can happen if the arguments to git-remote add is switched by the
user, and git would only show an error if fetching was also requested.
Fix it by using the refspec parsing engine to check if the requested
name can be parsed as a remote before add it.
Also cleanup so that the "remote.<name>.url" config name buffer is only
initialized once.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git init --shared=0xxx, where '0xxx' is an octal number, will create
a repository with file modes set to '0xxx'. Users with a safe umask
value (0077) can use this option to force file modes. For example,
'0640' is a group-readable but not group-writable regardless of
user's umask value. Values compatible with old Git versions are written
as they were before, for compatibility reasons. That is, "1" for
"group" and "2" for "everybody".
"git config core.sharedRepository 0xxx" is also handled.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally git-rebase was implemented in terms of "format-patch" piped
to "am -3", to strike balance between speed (because it avoids a rather
expensive read-tree/merge-recursive machinery most of the time) and
flexibility (the magic "-3" allows it to fall back to 3-way merge as
necessary). However, this combination has one flaw when dealing with a
nonstandard commit log message format that has more than one lines in the
first paragraph.
This teaches "git am --rebasing" to take advantage of the fact that the
mbox message "git rebase" prepares for it records the original commit
object name, to get the log message from the original commit object
instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-bisect: make "start", "good" and "skip" succeed or fail atomically
git-am: cope better with an empty Subject: line
Ignore leading empty lines while summarizing merges
bisect: squelch "fatal: ref HEAD not a symref" misleading message
builtin-apply: Show a more descriptive error on failure when opening a patch
Clarify documentation of git-cvsserver, particularly in relation to git-shell
* maint-1.5.4:
git-bisect: make "start", "good" and "skip" succeed or fail atomically
git-am: cope better with an empty Subject: line
Ignore leading empty lines while summarizing merges
bisect: squelch "fatal: ref HEAD not a symref" misleading message
builtin-apply: Show a more descriptive error on failure when opening a patch
Clarify documentation of git-cvsserver, particularly in relation to git-shell
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
