After master.k.org upgrade, I started seeing these warning messages:
transport.c: In function 'get_refs_via_curl':
transport.c:458: error: call to '_curl_easy_setopt_err_write_callback' declared with attribute warning: curl_easy_setopt expects a curl_write_callback argument for this option
It appears that the curl header wants to enforce the function signature
for callback function given to curl_easy_setopt() to be compatible with
that of (*curl_write_callback) or fwrite. This patch seems to work the
issue around.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we match a lightweight (non-annotated tag) as the name to
output and --long was requested we do not have a tag, nor do
we have a tagged object to display. Instead we must use the
object we were passed as input for the long format display.
Reported-by: Mark Burton <markb@ordern.com>
Backtraced-by: Mikael Magnusson <mikachu@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The cmd_show loop resolves tags by showing them, then pointing the
object to the 'tagged' member. However, this object is not fully
initialized; it only contains the SHA1. (This resulted in a segfault
if there were two levels of tags.) We apply parse_object to get a
full object.
Noticed by Kalle Olavi Niemitalo on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are basically two categories of update failures for
local refs:
1. problems outside of git, like disk full, bad
permissions, etc.
2. D/F conflicts on tracking branch ref names
In either case, there should already have been an error
message. In case '1', hopefully enough information has
already been given that the user can fix it. In the case of
'2', we can hint that the user can clean up their tracking
branch area by using 'git remote prune'.
Note that we don't actually know _which_ case we have, so
the user will receive the hint in case 1, as well. In this
case the suggestion won't do any good, but hopefully the
user is smart enough to figure out that it's just a hint.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rev-parse manpage introduces the branch@{date} syntax,
and mentions the reflog specifically. However, new users may
not be familiar with the distinction between the reflog and
the commit date, so let's help them out with a "you may be
interested in --until" pointer.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After initializing the config in the newly-created repository, we
need to unset GIT_CONFIG so that the global configs are read again.
Noticed by Pieter de Bie.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original sanitization code was just taken from the
remotes2config.sh shell script in contrib.
Credit to Avery Pennarun for noticing this mistake, and Junio
for clarifying the rules for config section names:
Junio C Hamano wrote in <7vfxr23s6m.fsf@gitster.siamese.dyndns.org>:
> In
>
> [foo "bar"] baz = value
>
> foo and baz must be config.c::iskeychar() (and baz must be isalpha()), but
> "bar" can be almost anything.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ffe256f9ba ("git-svn: Speed up fetch")
introduced changes that create a temporary file for each object fetched by
svn. These files should be deleted automatically, but perl apparently
doesn't do this until the process exits (or perhaps when its garbage
collector runs).
This means that on a large fetch, especially with lots of branches, we
sometimes fill up /tmp completely, which prevents the next temp file from
being written completely. This is aggravated by the fact that a new temp
file is created for each updated file, even if that update produces a file
identical to one already in git. Thus, it can happen even if there's lots
of disk space to store the finished repository.
We weren't adequately checking for write errors, so this would result in an
invalid file getting committed, which caused git-svn to fail later with an
invalid checksum.
This patch adds a check to syswrite() so similar problems don't lead to
corruption in the future. It also unlink()'s each temp file explicitly
when we're done with it, so the disk doesn't need to fill up.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Tested-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When run in batch mode, git cat-file never frees the memory for the blob
contents it is printing. This quickly adds up and causes git-svn to be
hardly usable for imports of large svn repos, because it uses cat-file in
batch mode and cat-file's memory usage easily reaches several hundred MB
without any good reason.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-config expects a space, not '=' between option and value.
Also, quote the value since it contains globs, which some shells will not
pass through unchanged, or will abort if the glob doesn't expand.
Signed-off-by: Joey Hess <joey@kitenet.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that buf has enough space to store the trailing \0 of
the command line argument, too.
Signed-off-by: Jochen Voss <voss@seehuhn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, if there was an error while storing a local
tracking ref, the low-level functions would report an error,
but fetch's status output wouldn't indicate any problem.
E.g., imagine you have an old "refs/remotes/origin/foo/bar" but
upstream has deleted "foo/bar" in favor of a new branch
"foo". You would get output like this:
error: there are still refs under 'refs/remotes/origin/foo'
From $url_of_repo
* [new branch] foo -> origin/foo
With this patch, the output takes into account the status of
updating the local ref:
error: there are still refs under 'refs/remotes/origin/foo'
From $url_of_repo
! [new branch] foo -> origin/foo (unable to update local ref)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we call "git clone" with a url that has a rewrite rule in either
$HOME/.gitconfig or /etc/gitconfig, the URL can be different from
what the command line expects it to be.
So, let's use the URL as the remote structure has it, not the literal
string from the command line.
Noticed by Pieter de Bie.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a backport of 0a47dc110e
to 'maint' to be included in 1.5.6.2 so that older server side
can accept dashless form of request when clients are updated.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --check" should return non-zero when there was any whitespace
error but the code only paid attention to the error status of the last
new line in the patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The update-hook-example used 'test -f' to check the tag present, which
does not work if the checked reference is packed. This check has been
changed to use 'git rev-parse $tag' instead.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.
We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:
1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
creates bar, but this function just creates the leading
directories.
2. mkdir_p took a mode argument, but it was completely
ignored.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "type" and "object" fields for tags were accepted as
valid atoms, but never implemented. Consequently, they
simply returned the empty string, even for valid tags.
Noticed by Lea Wiemann.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suppose someone fetches git-svn-ified commits from another repo and then
attempts to use 'git-svn init --rewrite-root=foo bar'. Using git svn rebase
after that will fail badly:
* For each commit tried by working_head_info, rebuild is called indirectly.
* rebuild will iterate over all commits and skip all of them because the
URL does not match. Because of that no rev_map file is generated at all.
* Thus, rebuild will run once for every commit. This takes ages.
* In the end there still isn't any rev_map file and thus working_head_info
fails.
Addressing this behaviour fixes an apparently not too uncommon problem with
providing git-svn mirrors of Subversion repositories. Some repositories are
accessed using different URLs depending on whether the user has push
privileges or not. In the latter case, an anonymous URL is often used that
differs from the push URL. Providing a mirror that is usable in both cases
becomes a lot more possible with this change.
Signed-off-by: Jan Krüger <jk@jk.gs>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The AIX mkstemp will modify it's template parameter to an empty string if
the call fails. This caused a subsequent mkdir to fail.
Signed-off-by: Patrick Higgins <patrick.higgins@cexp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch serves two purposes:
1. test-parse-option.c should be a more complete
example for the parse-options API, and
2. there have been no tests for OPT_CALLBACK,
OPT_DATE, OPT_BIT, OPT_SET_INT and OPT_SET_PTR
before.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add some documentation of basics, macros and callback
implementation of the parse-options API.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an argument for an option is optional, short options don't need a
space between the option and the argument, and long options need a "=".
Otherwise, arguments are misinterpreted.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mention NEED_WORK_TREE flag and command-list.txt.
Fix "bulit-in" typo and AsciiDoc-formatting of a paragraph.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git rebase --continue" and friends gave nonsense errors when there is no
rebase in progress.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once we find the absolute paths for git_dir and work_tree, we can make
git_dir a relative path since we know pwd will be work_tree. This should
save the kernel some time traversing the path to work_tree all the time
if git_dir is inside work_tree.
Daniel's patch didn't apply for me as-is, so I recreated it with some
differences, and here are the numbers from ten runs each.
There is some IO for me - probably due to more-or-less random flushing of
the journal - so the variation is bigger than I'd like, but whatever:
Before:
real 0m8.135s
real 0m7.933s
real 0m8.080s
real 0m7.954s
real 0m7.949s
real 0m8.112s
real 0m7.934s
real 0m8.059s
real 0m7.979s
real 0m8.038s
After:
real 0m7.685s
real 0m7.968s
real 0m7.703s
real 0m7.850s
real 0m7.995s
real 0m7.817s
real 0m7.963s
real 0m7.955s
real 0m7.848s
real 0m7.969s
Now, going by "best of ten" (on the assumption that the longer numbers
are all due to IO), I'm saying a 7.933s -> 7.685s reduction, and it does
seem to be outside of the noise (ie the "after" case never broke 8s, while
the "before" case did so half the time).
So looks like about 3% to me.
Doing it for a slightly smaller test-case (just the "arch" subdirectory)
gets more stable numbers probably due to not filling the journal with
metadata updates, so we have:
Before:
real 0m1.633s
real 0m1.633s
real 0m1.633s
real 0m1.632s
real 0m1.632s
real 0m1.630s
real 0m1.634s
real 0m1.631s
real 0m1.632s
real 0m1.632s
After:
real 0m1.610s
real 0m1.609s
real 0m1.610s
real 0m1.608s
real 0m1.607s
real 0m1.610s
real 0m1.609s
real 0m1.611s
real 0m1.608s
real 0m1.611s
where I'ld just take the averages and say 1.632 vs 1.610, which is just
over 1% peformance improvement.
So it's not in the noise, but it's not as big as I initially thought and
measured.
(That said, it obviously depends on how deep the working directory path is
too, and whether it is behind NFS or something else that might need to
cause more work to look up).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to a misplaced list block separator, general hints about the config
file options got indented at the same level as the description of the last
option, making it easy to miss them.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the arguments to test_must_fail() begin with a variable assignment,
test_must_fail() attempts to execute the variable assignment as a command.
This fails, and so test_must_fail returns with a successful status value
without running the command it was intended to test.
For example, the following script:
#!/bin/sh
test_must_fail () {
"$@"
test $? -gt 0 -a $? -le 129
}
foo='wo adrian'
test_must_fail foo='yo adrian' sh -c 'echo foo: $foo'
always exits zero and prints the message:
test.sh: line 3: foo=yo adrian: command not found
Test 16 calls test_must_fail in such a way and therefore has not been
testing whether git 'do[es] not fire editor in the presence of conflicts'.
A workaround is to set and export the variable in a normal way, not
using one-shot notation. Because this would affect the remainder of
the process, the test is done inside a subshell.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we include a few uninteresting lines before the interesting ones as
context, we are only interested in seeing the surviving lines themselves
and not the deleted lines that are before them. Mark the added leading
context lines in give_context() and not show deleted lines form them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
match_explicit is called for each push refspec to try to
fully resolve the source and destination sides of the
refspec. Currently, we look at each refspec and report
errors on both the source and the dest side before aborting.
It makes sense to report errors for each refspec, since an
error in one is independent of an error in the other.
However, reporting errors on the 'dst' side of a refspec if
there has been an error on the 'src' side does not
necessarily make sense, since the interpretation of the
'dst' side depends on the 'src' side (for example, when
creating a new unqualified remote ref, we use the same type
as the src ref).
This patch lets match_explicit return early when the src
side of the refspec is bogus. We still look at all of the
refspecs before aborting the push, though.
At the same time, we clean up the call signature, which
previously took an extra "errs" flag. This was pointless, as
we didn't act on that flag, but rather just passed it back
to the caller. Instead, we now use the more traditional
"return -1" to signal an error, and the caller aggregates
the error count.
This change fixes two bugs, as well:
- the early return avoids a segfault when passing a NULL
matched_src to guess_ref()
- the check for multiple sources pointing to a single dest
aborted if the "err" flag was set. Presumably the intent
was not to bother with the check if we had no
matched_src. However, since the err flag was passed in
from the caller, we might abort the check just because a
previous refspec had a problem, which doesn't make
sense.
In practice, this didn't matter, since due to the error
flag we end up aborting the push anyway.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit af66366a9f introduced the keyword
"never" to be used with approxidate() but defined it with a fixed date
without taking care of timezone. As a result approxidate() will return
a timestamp in the future with a negative timezone.
With this patch, approxidate("never") always return 0 whatever your
timezone is.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
head -<n> was deprecated by POSIX, and as modern versions of coreutils
package don't support it at least one exports _POSIX2_VERSION=199209
it's fails on some systems.
head -n<n> is portable, but sed <n>q is even more.
Signed-off-by: Alejandro Mery <amery@geeks.cl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The data read from MERGE_RR file is kept in path-list by hanging textual
40-byte conflict signature to path of the blob that contains the
conflict. The signature is strdup'ed twice, and the second copy is given
to the path-list, leaking the first copy.
Signed-off-by: Junio C Hamano <junio@pobox.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
The parse_ref method became unused in cd1464083c, but the author
decided to leave it in. Now it gets in the way of refactoring, so
let's remove it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This eliminates the function git_cmd_str, which was used for composing
command lines, and adds a quote_command function, which quotes all of
its arguments (as in quote.c).
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was implemented as a thin wrapper around an otherwise unused
helper function parse_pack_index_file(). The code becomes simpler
and easier to read by consolidating the two.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a shared repository, we should make sure adjust_shared_perm() is called
after creating the initial fan-out directories under objects/ directory.
Earlier an logico called the function only when mkdir() failed; we should
do so when mkdir() succeeded.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before even calling this, all callers have done a "has_sha1_file(sha1)"
or "has_loose_object(sha1)" check, so there is no point in doing a
second check.
If something races with us on object creation, we handle that in the
final link() that moves it to the right place.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When initializing the struct async and struct child_process structures,
the documentation suggested "clearing" the structure with '0' instead of
'\0'. It is enough to use integer zero here.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It worked that way since commit 50f575fc (Tweak diff colors,
2006-06-22), but commit c1795bb0 (Unify whitespace checking, 2007-12-13)
changed it. This patch restores the old behaviour.
Besides Linus' arguments in the log message of 50f575fc, resetting color
before printing newline is also important to keep 'git add --patch'
happy. If the last line(s) of a file are removed, then that hunk will
end with a colored line. However, if the newline comes before the color
reset, then the diff output will have an additional line at the end
containing only the reset sequence. This causes trouble in
git-add--interactive.perl's parse_diff function, because @colored will
have one more element than @diff, and that last element will contain the
color reset. The elements of these arrays will then be copied to @hunk,
but only as many as the number of elements in @diff. As a result the
last color reset is lost and all subsequent terminal output will be
printed in color.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clone.sh was the last user of the "curl" executable. Relevant git
commands now use libcurl instead. This should be reflected in the
install requirements.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier series to rename documentation pages around did not update this
target and left check-docs broken. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we've made the loose SHA1 file reading more careful and
streamlined, we only use the old find_sha1_file() function for checking
whether a loose object file exists at all.
As such, the whole 'return stat information' part of it was just
pointless (nobody cares any more), and the naming of the function is not
really all that relevant either.
So simplify it to not do a 'stat()', but just an existence check (which
is what the callers want), and rename it to 'has_loose_object()' which
matches the use.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to do 'stat()+open()+mmap()+close()' to read the loose object
file data, which does work fine, but has a couple of problems:
- it unnecessarily walks the filename twice (at 'stat()' time and then
again to open it)
- NFS generally has open-close consistency guarantees, which means that
the initial 'stat()' was technically done outside of the normal
consistency rules.
So change it to do 'open()+fstat()+mmap()+close()' instead, which avoids
both these issues.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of creating new temporary objects in the top-level git object
directory, create them in the same directory they will finally end up in
anyway. This avoids making the final atomic "rename to stable name"
operation be a cross-directory event, which makes it a lot easier for
various filesystems.
Several filesystems do things like change the inode number when moving
files across directories (or refuse to do it entirely).
In particular, it can also cause problems for NFS implementations that
change the filehandle of a file when it moves to a different directory,
like the old user-space NFS server did, and like the Linux knfsd still
does if you don't export your filesystems with 'no_subtree_check' or if
you export a filesystem that doesn't have stable inode numbers across
renames).
This change also obviously implies creating the object fan-out
subdirectory at tempfile creation time, rather than at the final
move_temp_to_file() time. Which actually accounts for most of the size
of the patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In c13b263, http_fetch_ref got "refs/" included in the ref passed to it,
which, incidentally, makes the allocation in quote_ref_url too big, now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes single point where $GIT (which can contain full path
to git binary) with embedded spaces gave errors.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option -u stands for --update and it is a good idea to make it clear
especially because this is the only mode of operation of "git add" that
does something different from "adding". Give longer --force synonym to -f
while we are at it as well.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve the git-svn-author test to check that extra newlines aren't inserted
into commit messages as they take a round trip from git to svn and back.
We test both with and without the --add-author-from option to git-svn.
git-svn: test that svn repo doesn't have extra newlines.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git, all commits end in exactly one newline character. In svn, commits
end in zero or more newlines. Thus, when importing commits from svn into
git, git-svn always appends two extra newlines to ensure that the
git-svn-id: line is separated from the main commit message by at least one
blank line.
Combined with the terminating newline that's always present in svn commits
produced by git, you usually end up with two blank lines instead of one
between the commit message and git-svn-id: line, which is undesirable.
Instead, let's remove all trailing whitespace from the git commit on the way
through to svn.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule was invoking "die" from within resolve-relative-url, but
this does not actually cause the script to exit. Fix this by returning
the error to the caller and have the caller exit.
While we're at it, clean up the quoting on invocation of
resolve_relative_url as it was wrong.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... because we are now bisecting using a detached HEAD.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
write_sha1_from_fd() and write_sha1_to_fd() were dead code nobody called,
neither the latter's helper repack_object() was.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch allows calling:
git-instaweb -d apache2
and have the script Do The Right Thing. In particular, the auto-discovery
mechanism has been extended in order to be used for module listing as
well, and the call convention is that if the daemon is apache2/lighttpd
and the parameter to the "-d" option does not end by "-f", the "-f" is
added to the end of the option itself.
Change all backticks to $( ... ) as per Documentation/CodingGuidelines.
Signed-off-by: Flavio Poletti <flavio@polettix.it>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test did "reset --hard" (where the HEAD commit has an empty
blob at path "empty") followed by "> empty", expecting that
the index does not notice the file _changed_ since git wrote
it out upon "reset" if the redirection is done quickly enough.
There was no need to do the emptying, and it gave a wrong result
if "reset --hard" happened on time T and then ">empty" happened on
the next second T+1. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* om/remote-fix:
"remote prune": be quiet when there is nothing to prune
remote show: list tracked remote branches with -n
remote prune: print the list of pruned branches
builtin-remote: split show_or_prune() in two separate functions
remote show: fix the -n option
If we are exporting a commit which has no parents we may be doing
it to a branch that already exists, causing fast-import to assume
the branch's current revision should be the sole parent of the
new commit. This can cause `git fast-export | git fast-import`
to produce an incorrect graph for:
A-------M----o------o refs/heads/master
/
B-+
In this graph A and B are initial commits (no parents) but if A was
output first to refs/heads/master and then B is output fast-import
would assume the graph was this instead:
A-------M----o------o refs/heads/master
\ /
+-B-+
Which would cause B, M, and all later commits to have a different
SHA-1, and obviously be quite a different graph.
Sending a reset command prior to B informs fast-import to clear
the implied parent of A, allowing B to remain an initial commit.
Reported-by: Ben Lynn <benlynn@gmail.com>
Deemed-obviously-correct-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only ignore whitespace errors in t/tNNNN-*.sh and the t/tNNNN
subdirectories. Other files (like test libraries) should still be
checked.
Also fix a whitespace error in t/test-lib.sh.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The behaviour of "sed" on an incomplete line is unspecified by POSIX, and
On Solaris it apparently fails to process input that doesn't end in a LF.
Consequently constructs like
re=$(printf '%s' foo | sed -e 's/bar/BAR/g' $)
cause re to be set to the empty string. Such a construct is used in
git-submodule.sh.
Because the LF at the end of command output are stripped away by the
command substitution, it is a safe and sane change to add a LF at the end
of the printf format specifier.
Signed-off-by: Chris Ridd <chris.ridd@isode.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Higher stages store the blobs involved from their side verbatim. Removal
of uninteresting hunks are done by "diff --cc" upon demand and not stored
in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already had a hack to exclude @pxref{[URLS]} from the texi stream that
refers to nonexistent anchor.
This allows "make info" to produce gitman.info again.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unlike other manual pages (e.g. git-blame.txt), this used *NOTE:*
to show a side note headed with boldface string "NOTE". Use a paragraph
headed by [NOTE] like others instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit made it always say "Pruning $remote" but reported the
URL only when there is something to prune. Make it consistent by not
saying anything at all when there is nothing to prune.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This command is really too quiet which make it unconfortable to use.
Also implement a --dry-run option, in place of the original -n one, to
list stale tracking branches that will be pruned, but do not actually
prune them.
Add a test case for --dry-run.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allow us to add different features to each of them and keep the
code simple at the same time. Also create a get_remote_ref_states()
to avoid duplicated code.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The perl version accepted a -n flag, to show local informations only
without querying remote heads, that seems to have been lost in the C
revrite.
This restores the older behaviour and add a test case.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For CVS repositories with unusual CVSROOT, git-cvsimport would fail:
$ git-cvsimport -v -C foo -d :pserver:anon:@cvs.example.com:/ foo
AuthReply: error 0 : no such repository
This patch ensures that the path is never empty, but at least '/'.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This consolidates the common operations for closing the new temporary file
that we have written, before we move it into place with the final name.
There's some common code there (make it read-only and check for errors on
close), but more importantly, this also gives a single place to add an
fsync_or_die() call if we want to add a safe mode.
This was triggered due to Denis Bueno apparently twice being able to
corrupt his git repository on OS X due to an unlucky combination of kernel
crashes and a not-very-robust filesystem.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without [verse], the line break between the two synopsis lines does
not make it into the man page.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code forgot to convert the blob contents into work tree
representation before writing it out. Also fixes leaks -- earlier
the updated blobs were never freed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you work on a repo with core.autocrlf == true, you would expect
every text file to have CRLF EOLs. However, if you by some operation,
get a conflict, then the conflicted file has LF EOLs.
Now, of course you'd go about resolving the files conflict, and then 'git
add <file>'. When you do that, you'll get the warning saying that LF will
be replaced by CRLF. Then you commit. The end result is that you have a
workingdir with a mix of LF and CRLF files, which after some more
operations may trigger a "whole file changed" diff, due to the workingdir
file now having LF EOLs.
An LF only conflict file results in the resolved file being in LF,
the commit is in LF and a warning saying that LF will be replaced
by CRLF, and the working dir ends up with a mix of CRLF and LF files.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Attributes can be specified at three different places: the internal
table of default values, the file $GIT_DIR/info/attributes and files
named .gitattributes in the work tree. Since bare repositories don't
have a work tree, git should ignore any .gitattributes files there.
This patch makes git do that, so the only way left for a user to specify
attributes in a bare repository is the file info/attributes (in addition
to changing the defaults and recompiling).
In addition, git-check-attr is now allowed to run without a work tree.
Like any user of the code in attr.c, it ignores the .gitattributes files
when run in a bare repository. It can still read from info/attributes.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, cat-file --batch / --batch-check would silently exit if it
was passed a non-existent SHA1 on stdin. Now it prints "<SHA1>
missing" as in all other cases (and as advertised in the
documentation).
Note that cat-file --batch-check (but not --batch) will still output
"error: unable to find <SHA1>" on stderr if a non-existent SHA1 is
passed, but this does not affect parsing its stdout.
Also, type <= 0 was previously using the potentially uninitialized
type variable (relying on it being 0); it is now being initialized.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously timestamps were removed unconditionally (though this didn't
seem to break this test). Now they are only removed if $no_ts is
non-empty.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds support to compile and run git on 12 additional platforms.
The platforms are based on UNIX Systems Labs (USL)/Novell/SYS V code base.
The most common are Novell UnixWare 2.X.X, SCO UnixWare 7.X.X,
OpenServer 5.0.X, OpenServer 6.0.X, and SCO pre OSR 5 platforms.
Looking at the the various platform headers, I find:
#if defined(_KERNEL) || !defined(_POSIX_SOURCE) \
&& !defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)
which hides u_short and other typedefs that other header files on these
platforms depend on. WIth _XOPEN_SOURCE defined, sources that include
system header files that depend on the typedefs such as u_short cannot be
compiled on these platforms.
__USLC__ indicates UNIX System Labs Corperation (USLC), or a Novell-derived
compiler and/or some SysV based OS's.
__M_UNIX indicates XENIX/SCO UNIX/OpenServer 5.0.7 and prior releases
of the SCO OS's. It is used just like Apple and BSD, both of these
shouldn't have _XOPEN_SOURCE defined.
This is with suggestions and modifications from
Daniel Barkalow, Junio C Hamano, Thomas Harning, and Jeremy Maitin-Shepard.
Signed-off-by: Boyd Lynn Gerber <gerberb@zenez.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Dynamically sized arrays are gcc and C99 construct. Using them hurts
portability to older compilers, although using them is nice in this case
it is not desirable. This patch removes the only use of the construct
in stop_progress_msg(); the function is about writing out a single line
of a message, and the existing callers of this function feed messages
of only bounded size anyway, so use of dynamic array is simply overkill.
Signed-off-by: Boyd Lynn Gerber <gerberb@zenez.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The OPTIONS section of a documentation file contains a list
of the options a git command accepts.
Currently there are several variants to describe the case that
different options (almost) do the same in the OPTIONS section.
Some are:
-f, --foo::
-f|--foo::
-f | --foo::
But AsciiDoc has the special form:
-f::
--foo::
This patch applies this form to the documentation of the whole git suite,
and removes useless em-dash prevention, so \--foo becomes --foo.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also split the "-c or -C <commit>" item into two separate items.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When interactively supplying addresses to send an email to with
send-email, whitespace after the separation comma (as in 'list, jc')
wasn't ignored. This meant that resolving of the alias ' jc' would
fail, sending an email only to list. With this patch, the optional
trailing whitespace is ignored.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also add a few more hints for how to setup and configure gitweb as described
[jc: with a fix from Mike Hommey]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch fixes the SYNOPSIS in git-commit.txt:
* --amend could be used in conjunction with -c/-C/-F/-m;
it is not mutually exclusive with them.
* -m and -F are not alternative options to -c/-C;
you can reuse authorship from a commit (-c/-C)
but change the message (-m/-F).
Furthermore, for long-option consistency --author <author>
is changed to --author=<author>.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git rebase -i already supports 'p', 'e' and 's' as aliases for 'pick',
'edit' and 'squash', but one could know it only by reading the source
code. If a user rebases a lot, it's quite handy, so mention these short
forms as well.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The n_refs variable is no longer really used in this function, so there
is no reason to keep it.
It was introduced in 27dedf0c and the code that really used it was
removed in 7914053.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit aa1dbc9 (Update http-push functionality, 2006-03-07)
borrowed some code from rev-list.c.
This copy and paste made sense back then, because mark_edges_uninteresting(),
and its helper mark_edge_parents_uninteresting(), accessed a file scope
static variable "revs" in rev-list.c, and http-push.c did not have nor care
about such a variable.
But these days they are already properly libified and live in list-objects.c
and they take "revs" as as an argument. Make use of them and lose 20 or
so lines.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, merge commits were printed with 'M' instead of '*'. This
had the potential to confuse users when not all parents of the merge
commit were included in the log output.
As Junio has pointed out, merge commits can almost always be easily
identified from the log message, anyway.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Particularly for the "alternates" file, if one will be created, we
want a path that doesn't depend on the current directory, but we want
to retain any symlinks in the path as given and any in the user's view
of the current directory when the path was given.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the "git" man page describes the "git" command at the end-user
level, it seems better to move it to man section 1.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man format:
diffcore.txt -> gitdiffcore.txt (man section 7)
repository-layout.txt -> gitrepository-layout.txt (man section 5)
Other documents that reference the above ones are changed accordingly.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change teaches the graph API that only the first parent of each
commit is interesting when "--first-parent" was specified.
This change also consolidates the graph parent walking logic into two
new internal functions, first_interesting_parent() and
next_interesting_parent(). A simpler fix would have been to simply
break at the end of the 2 existing for loops when
graph->revs->first_parent_only is set. However, this change seems
nicer, especially if we ever need to add any new loops over the parent
list in the future.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git's main usage pages did not show "git help" as a way to get more
information on a specific subcommand. This patch adds an info line after
the list of git commands currently printed by "git", "git help", "git
--help" and "git help --all".
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier "blob_plain" view sent "charset=utf-8" only when gitweb
guessed the content type to be text by reading from it, and not when
the MIME type was obtained from /etc/mime.types, or when gitweb
couldn't guess mimetype and used $default_blob_plain_mimetype.
This fixes the bug by always add charset info from
$default_text_plain_charset (if it is defined) to "raw" (a=blob_plain)
output for 'text/plain' blobs.
Generating information for Content-Type: header got separated into
blob_contenttype() subroutine; adding charset info in a special case
was removed from blob_mimetype(), which now should return mimetype
only.
While at it cleanup code a bit: put subroutine parameter
initialization first, make error message more robust (when $file_name
is not defined) if more cryptic, remove unnecessary '"' around
variable ("$var" -> $var).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All functions in strbuf.h are documented, except launch_editor().
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The builtin-clone now does the http commit walking and the tree unpacking
in the same process, and the commit walker leaves the in-core objects in a
funny state. When forgetting the data read from the tree object, the
object should be marked "not parsed yet" for later users.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The log family and git-rev-list share the same set of options that come
from revision walking machinery, but they both have options unique to
them. Notably, --header, --timestamp, --stdin and --quiet apply only to
rev-list. Exclude them from the git-log documentation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The double slashes "//" result from url./$TRASH/. expansion and the
current directory, which even in cygwin contains "/" as first
character. In cygwin such strings have special meaning: UNC path.
Accessing an UNC path built for test purpose usually fails.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One particular test wants to check the behaviour of the command
when these variables are not set, but the later tests should have
the reliable committer identity for repeatable tests.
Move the "unset" of the variables inside a subshell in the test
that wants to unset them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cat-file --batch/--batch-check only flushes stdout when the object
exists, but not when it doesn't ("<object> missing"). This makes
bidirectional pipes hang.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The scripted version of git-commit internally used git-commit-tree which
omitted duplicated parents given from the command line. This prevented a
nonsensical octopus merge from getting created even when you said "git
merge A B" while you are already on branch A.
However, when git-commit was rewritten in C, this sanity check was lost.
This resurrects it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the upstream argument to rebase (the first argument) was relative to
HEAD and the name of the branch to rebase (the second argument) was given,
the upstream would have been interpreted relative to the second argument.
In particular, this command
git rebase -i HEAD topic
would always finish with "Nothing to do". (a1bf91e fixed the same issue
for non-interactive rebase.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old description was misleading and logically impossible. It claimed that
the ancestors of the original commit would be re-written to have the multiple
emitted ids as parents. Not only would this modify existing objects, but it
would create a cycle. What this actually does is pass the multiple emitted ids
to the newly-created children to use as parents.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix search form generation to not modify $cgi->param(...)'s.
In git_header_html() we used to use $cgi->hidden(-name => "a") etc. to
generate hidden fields; unfortunately to use this form it is required
to modify $cgi->param("a") etc., which makes href(-replay,...) use
wrong replay values. This for example made the "next" link on the
bottom of the page has a=search instead of a=$action, and thus fails to
get you to the next page.
Because in CGI the value of a hidden field is "sticky", there is no
way to modify it short of modifying $cgi->param(...). Therefore it
got replaced by generating <input type="hidden" ...> element [semi]
directly.
Alternate solution would be for href(-replay,...) to use values saved
in global variables, such as $action etc., instead of (re)reading them
from $cgi->param($symbol).
The bad link was reported by Kai Blin through
http://bugs.debian.org/481902
Reported-by: Kai Blin <kai.blin@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit dbe48256b4, which
caused mis-encoding of non-ASCII author/committer names when the
git-status mode is used to create commits.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/remote:
Make "git-remote rm" delete refs acccording to fetch specs
Make "git-remote prune" delete refs according to fetch specs
Remove unused remote_prefix member in builtin-remote
When a pack gets corrupted, its SHA1 checksum will fail. However, this
is more useful to let the test go on in order to find the actual
problem location than only complain about the SHA1 mismatch and
bail out.
Also, it is more useful to compare the stored pack SHA1 with the one in
the index file instead of the computed SHA1 since the computed SHA1
from a corrupted pack won't match the one stored in the index either.
Finally a few code and message cleanups were thrown in as a bonus.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'jc/checkout':
checkout: "best effort" checkout
unpack_trees(): allow callers to differentiate worktree errors from merge errors
checkout: consolidate reset_{to_new,clean_to_new}()
checkout: make reset_clean_to_new() not die by itself
If config is called in array context, it is supposed to return all
values set for the given option key. This works for all cases except
if there is no value set at all. In that case, it wrongly returns
(undef) instead of (). This fixes the return statement so that it
returns undef in scalar context but an empty array in array context.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They now point to more specific/appropriate targets.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man format:
core-tutorial.txt -> gitcore-tutorial.txt
glossary.txt -> gitglossary.txt
But as the glossary is included in the user manual and as the new
gitglossary man page cannot be included as a whole in the user manual,
the actual glossary content is now in its own "glossary-content.txt"
new file. And this file is included by both the user manual and the
gitglossary man page.
Other documents that reference the above ones are changed accordingly
and sometimes improved a little too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation of hash_object incorrectly states that it accepts a
file handle -- in fact it doesn't, and there is even a TODO comment
for this. This fixes the documentation.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an octopus merge is printed, several lines are printed before it to
move over existing branch lines to its right. This is needed to make
room for the children of the octopus merge. For example:
| | | |
| | \ \
| | \ \
| | \ \
| M---. \ \
| |\ \ \ \ \
However, this step isn't necessary if there are no branch lines to the
right of the octopus merge. Therefore, skip this step when it is not
needed, to avoid printing extra lines that don't really serve any
purpose.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change improves the way merge commits are displayed, to eliminate a
few visual artifacts. Previously, merge commits were displayed as:
| M \
| |\ |
As pointed out by Teemu Likonen, this didn't look nice if the rightmost
branch line was displayed as '\' on the previous line, as it then
appeared to have an extra space in it:
| |\
| M \
| |\ |
This change updates the code so that branch lines to the right of merge
commits are printed slightly differently depending on how the previous
line was displayed:
| |\ | | | | | /
| M \ | M | | M |
| |\ \ | |\ \ | |\ \
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If url://repo/trunk is the current Git branch, prop_walk strips trunk
from the path name. That is useful as, for example "git svn show-ignore"
should not return results like
trunk/foo
but
foo
if svn:ignore for trunk includes foo.
The problem now is that prop_walk strips trunk from the path and then
calls itself recursively. But now trunk is missing in the path and
get_dir fails, because it is called for a non existing path.
The attached patch fixed the problem, by adding the previously stipped
$self->{path} in the recursive call. I tested it with my current
git-svn repository for the commands show-ignore and show-external.
Patch was submitted through
http://bugs.debian.org/477393
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with multiple branches in an svn repository, it can be
useful to verify the svn repository and local tracking branch that will
be used for the rebase operation.
Signed-off-by: Seth Falcon <seth@userprimary.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Given an SVN repo file:///tmp/svntest/repo, trying to commit changes
to a file proj/trunk/foo.txt in that repo with this command line
git svn commit-diff -r2 HEAD^ HEAD file:///tmp/svntest/repo/proj/trunk
gave the error message
Filesystem has no item: File not found: transaction '2-6', path
'/proj/trunk/proj/trunk/foo.txt'
This fixes the duplication.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A remote may be configured to fetch into tracking branches that
don't match its name. A user may have created a remote by hand
that will fetch to a different tracking branch namespace:
[remote "alt"]
url = git://repo.or.cz/alt-git.git
fetch = refs/heads/*:refs/remotes/origin/*
When deleting remote alt we should clean up the refs whose names
start with "refs/remotes/origin/", even though the remote itself
was named alt by the user.
To avoid deleting refs used by another remote we only clear refs
that are unique to this remote. This prevents `git prune rm alt`
from removing the refs used by say origin if alt was just using a
different URL for the same repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A remote may be configured to fetch into tracking branches that
do not match the remote name. For example a user may have created
extra remotes that will fetch to the same tracking branch namespace,
but from different URLs:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/*:refs/remotes/origin/*
[remote "alt"]
url = git://repo.or.cz/alt-git.git
fetch = refs/heads/*:refs/remotes/origin/*
When running `git remote prune alt` we expect stale branches to
be removed from "refs/remotes/origin/*" and not from the unused
namespace of "refs/remotes/alt/*".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not sure when this became unused, but no code references it,
other than to populate the strbuf with an initial value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, some tests will fail because they compare command output
of subprocesses (such as git) with $PWD -- but subprocesses have the
physical path as their working directory, whereas $PWD contains the
symlinked path. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running git-reset in a non-interactive setting, the -q switch
works for everything except the progress updates. This squelches it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch moves the am test cases in t4150-am.sh and the
am subdirectory test cases from t/t4150-am-subdir.sh into
t/4151-am.sh.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add t/t4151-am.sh that does basic testing of git-am functionality,
including:
* am applies patch correctly
* am changes committer and keeps author
* am --signoff adds Signed-off-by: line
* am stays in branch
* am --signoff does not add Signed-off-by: line if already there
* am without --keep removes Re: and [PATCH] stuff
* am --keep really keeps the subject
* am -3 falls back to 3-way merge
* am pauses on conflict
* am --skip works
* am --resolved works
* am takes patches from a Pine mailbox
* am fails on mail without patch
* am fails on empty patch
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the pack-files are now always created stably on disk, there is no
need to sync() before pruning lose objects or old stale pack-files.
[jc: with Nico's clean-up]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This means that we can depend on packs always being stable on disk,
simplifying a lot of the object serialization worries. And unlike loose
objects, serializing pack creation IO isn't going to be a performance
killer.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Alter the description of <repository> in OPTIONS section to
explicitly state that a 'remote name' is accepted.
Rewrite REMOTES section to more directly identify the
different kinds of remote-name permitted.
Signed-off-by: John J. Franey <jjfraney@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Other signals are also common, for example SIGTERM and SIGHUP.
This patch modifies the lock file mechanism to catch more signals.
It also modifies http-push.c which was missing SIGTERM.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately the list is not complete, but includes the essential ones.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Testing if gitweb handles filenames with spaces, filenames with plus
sign ('+') which encodes spaces in CGI parameters (in URLs), and
filenames with Unicode characters should be handled by gitweb tests.
Those files are remainder of the time when gitweb was project on its
own, not a part of git (with its testsuite).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a cache entry has been marked as CE_VALID, the user has
promised us that any change in the work tree does not matter.
Just mark the entry as up-to-date, and continue.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous documentation didn't make it clear that the
"assume unchanged" was on per file basis, and not a global
flag.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When unpack_trees() returned an error while switching branches, we used to
stop right there, exiting without writing the index out or switching HEAD.
This is Ok when unpack_trees() returned an error because it detected
untracked files or locally modified paths that could be overwritten by
branch switching, because that error return is done before we start to
modify the work tree. But it is undesirable if unpack_trees() already
started to update the work tree and a failure is returned because some but
not all paths are updated in the work tree, perhaps because a directory
that some files need to go in was read-only by mistake, or a file that
will be overwritten by branch switching had a mandatory lock on it and we
failed to unlink it.
This changes the behaviour upon such an error to complete the branch
switching; the files updated in the work tree will hopefully be much more
consistent with the index and HEAD derived from the switched-to branch.
We still issue error messages, and exit the command with non-zero status,
so scripted callers need to notice it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of uniformly returning -1 on any error, this teaches
unpack_trees() to return -2 when the merge itself is Ok but worktree
refuses to get updated.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is unfortunate that "git init --bare" does not work and the only reason
why "init" did not learn its own "--bare" option is because "git --bare
init" already does the job (and as an option to the git 'potty', it is
more generic solution).
This teaches "git init" its own "--bare" option, so that both "git --bare init"
and "git init --bare" works mostly the same way.
[jc: rewrote the log message and added test]
Signed-off-by: Luciano Rocha <strange@nsk.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead, have its error percolate up through the callchain and let it be
the exit status of the main command. No semantic changes yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git checkout -- paths..." cannot update work tree for whatever
reason, checkout_entry() correctly issued an error message for the path to
the end user, but the command ignored the error, causing the entire
command to succeed. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Geoffrey Irving noticed that git-cherry talks about comparing commits without
hinting how they are compared.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems simpler and safer to use the BISECT_START file everywhere
to decide if we are bisecting or not, instead of using it in some
places and BISECT_NAMES in other places.
In commit 6459c7c678 (Nov 18 2007,
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.),
we decided to use BISECT_NAMES but code changed a lot and we now
have to check BISECT_START first in the "bisect_start" function
anyway.
This patch also makes things a little bit safer by creating
the BISECT_START file first and deleting it last, and also by
adding checks in "bisect_clean_state".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit 633f43e (Remove redundant code, eliminate one static
variable, 2008-05-24) had a thinko (perhaps an eyeno) that broke
sha1_pack_index_name() function. One symptom of this was that the http
walker is now completely broken.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent "git-svn optimization" series introduced Git::cat_blob() subroutine
whose interface was broken in that it returned the size of the blob but
signalled an error by returning 0. You can never use an empty blob with
such an interface.
This fixes the interface to return a negative value to signal an error.
Reported by Björn Steinbrink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are broken filesystems that cannot have a file whose name is "nul"
anywhere on it. Rename the test file to make ourselves more portable.
Noticed by Mark Levedahl.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we use an unsupported transport (e.g., http when curl
support is not compiled in), transport_get reports an error
to the user, but we still get a transport object. We need to
manually check and abort the clone process at that point, or
we end up with a segfault.
Noticed by Thomas Rast.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/diff-no-no-index:
git diff --no-index: default to page like other diff frontends
git-diff: allow --no-index semantics a bit more
"git diff": do not ignore index without --no-index
diff-files: do not play --no-index games
tests: do not use implicit "git diff --no-index"
Even when inside a git work tree, if two paths are given and at least one
is clearly outside the work tree, it cannot be a request to diff a tracked
path anyway; allow such an invocation to use --no-index semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-gui after clicking either on 'Create New Repository' or
'Open Existing Repository' the form elements aren't centered like
they are pretty much everywhere else in the app. At least when ran
on a mac, haven't checked on other platforms.
Using grid instead of pack seems to fix this.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch adds an option to make hg-to-git quiet by default. Note:
it only suppresses those messages that would be printed when everything
was up-to-date.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the hook gets invoked with identical old and new ids there
is no change taking place. We probably should not have been
called, but instead of failing silently allow the no-op.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a user or group ACL file does not exist in the current tip
revision of the acl repository we will get an error from cat-file
when we ask for that blob as it cannot be resolved. A quick look
at the history by rev-list can tell us if there is a path there
or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Listing all files in a branch during branch creation is silly;
the user's file-level ACLs probably don't mean anything at this
point. We now treat the base case of 0{40} as an empty diff,
as this happens only when the user is creating the branch and
there are file level ACLs that diff against the old value of
the branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This draws the currently checked-out head with a yellow circle, as
suggested by Linus Torvalds, and fixes various places in the code
where we assumed that the current head always had a branch. Now we
can display the fake commits for local changes on a detached head.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* as/graph:
get_revision(): honor the topo_order flag for boundary commits
Fix output of "git log --graph --boundary"
log --graph --left-right: show left/right information in place of '*'
graph API: don't print branch lines for uninteresting merge parents
graph API: fix graph mis-alignment after uninteresting commits
* js/mailinfo:
mailsplit: minor clean-up in read_line_with_nul()
mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths
mailsplit and mailinfo: gracefully handle NUL characters
* jc/add-n-u:
Make git add -n and git -u -n output consistent
"git-add -n -u" should not add but just report
Conflicts:
builtin-add.c
builtin-mv.c
cache.h
read-cache.c
* db/clone-in-c:
Add test for cloning with "--reference" repo being a subset of source repo
Add a test for another combination of --reference
Test that --reference actually suppresses fetching referenced objects
clone: fall back to copying if hardlinking fails
builtin-clone.c: Need to closedir() in copy_or_link_directory()
builtin-clone: fix initial checkout
Build in clone
Provide API access to init_db()
Add a function to set a non-default work tree
Allow for having for_each_ref() list extra refs
Have a constant extern refspec for "--tags"
Add a library function to add an alternate to the alternates file
Add a lockfile function to append to a file
Mark the list of refs to fetch as const
Conflicts:
cache.h
t/t5700-clone-reference.sh
* jc/apply-whitespace:
builtin-apply: do not declare patch is creation when we do not know it
builtin-apply: accept patch to an empty file
builtin-apply: typofix
* ar/batch-cat:
change quoting in test t1006-cat-file.sh
builtin-cat-file.c: use parse_options()
git-svn: Speed up fetch
Git.pm: Add hash_and_insert_object and cat_blob
Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
git-hash-object: Add --stdin-paths option
Add more tests for git hash-object
Move git-hash-object tests from t5303 to t1007
git-cat-file: Add --batch option
git-cat-file: Add --batch-check option
git-cat-file: Make option parsing a little more flexible
git-cat-file: Small refactor of cmd_cat_file
Add tests for git cat-file
* cc/bisect:
bisect: use a detached HEAD to bisect
bisect: trap critical errors in "bisect_start"
bisect: fix left over "BISECT_START" file when starting with junk rev
bisect: add test cases to check that "git bisect start" is atomic
* ap/svn:
git-svn: add test for --add-author-from and --use-log-author
git-svn: add documentation for --add-author-from option.
git-svn: Add --add-author-from option.
git-svn: add documentation for --use-log-author option.
* js/cvsexportcommit:
cvsexportcommit: introduce -W for shared working trees (between Git and CVS)
cvsexportcommit: chomp only removes trailing whitespace
Conflicts:
git-cvsexportcommit.perl
* js/ignore-submodule:
Ignore dirty submodule states during rebase and stash
Teach update-index about --ignore-submodules
diff options: Introduce --ignore-submodules
* mo/cvsserver:
Documentation: Fix skipped section level
git-cvsserver: add ability to guess -kb from contents
implement gitcvs.usecrlfattr
git-cvsserver: add mechanism for managing working tree and current directory
The function fgets() has a big problem with NUL characters: it reads
them, but nobody will know if the NUL comes from the file stream, or
was appended at the end of the line.
So implement a custom read_line_with_nul() function.
Noticed by Tommy Thorn.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If locks are not cleaned up the repository is inaccessible for 10 minutes.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This did not cause any problems, because remove_lock_file_on_signal is
only registered for SIGINT.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now get_revision() sorts the boundary commits when topo_order is set.
Since sort_in_topological_order() takes a struct commit_list, it first
places the boundary commits into revs->commits.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously the graphing API wasn't aware of the revs->boundary flag, and
it always assumed that commits marked UNINTERESTING would not be
displayed. As a result, the boundary commits were printed at the end of
the log output, but they didn't have any branch lines connecting them to
their children in the graph.
There was also another bug in the get_revision() code that caused
graph_update() to be called twice on the first boundary commit. This
caused the graph API to think that a commit had been skipped, and print
a "..." line in the output.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the --graph option, the graph already outputs 'o' instead of '*'
for boundary commits. Make it emit '<' or '>' when --left-right is
specified.
(This change also disables the '^' prefix for UNINTERESTING commits.
The graph code currently doesn't print anything special for these
commits, since it assumes no UNINTERESTING, non-BOUNDARY commits are
displayed. This is potentially a bug if UNINTERESTING non-BOUNDARY
commits can actually be displayed via some code path.)
[jc: squashed the left-right change from Dscho and Adam's fixup into one]
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the graphing code printed lines coming out of a merge commit
for all of its parents, even if some of them were uninteresting. Now it
only prints lines for interesting commits.
For example, for a merge commit where only the first parent is
interesting, the code now prints:
* merge commit
* interesting child
instead of:
M merge commit
|\
* interesting child
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The graphing code had a bug that caused it to output branch lines
incorrectly after ignoring an uninteresting commit. When computing how
to match up the branch lines from the current commit to the next one, it
forgot to take into account that it needed to initially start with 2
empty spaces where the missing commit would have gone.
So, instead of drawing this,
| * | <- Commit with uninteresting parent
| /
* |
It used to incorrectly draw this:
| * | <- Commit with uninteresting parent
* |
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man page format:
cvs-migration.txt -> gitcvs-migration.txt
tutorial.txt -> gittutorial.txt
tutorial-2.txt -> gittutorial-2.txt
These new man pages are put in section 7, and other documents that reference
the above ones are change accordingly.
[jc: with help from Nanako to clean things up]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even if "foo" and/or "bar" does not exist in index, "git diff foo bar"
should not change behaviour drastically from "git diff foo bar baz" or
"git diff foo". A feature that "sometimes works and is handy" is an
unreliable cute hack.
"git diff foo bar" outside a git repository continues to work as a more
colourful alternative to "diff -u" as before.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Being able to say "git diff A B" outside a git repository and getting a
colourful version of "diff -u A B" may be nice, but such a cute hack
should not give bogus results to scripts that want to give two paths,
either or both of which happen to have been removed from the work tree,
to "git diff-files".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done. We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".
Rather use test_cmp for that purpose.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix bug introduced by "gitk: Fix "wrong # coordinates" error on reload"
gitk: Fix bug where current row number display stops working
gitk: Move es.po where it belongs
gitk: Fix "wrong # coordinates" error on reload
* bc/repack:
Documentation/git-repack.txt: document new -A behaviour
let pack-objects do the writing of unreachable objects as loose objects
add a force_object_loose() function
builtin-gc.c: deprecate --prune, it now really has no effect
git-gc: always use -A when manually repacking
repack: modify behavior of -A option to leave unreferenced objects unpacked
Conflicts:
builtin-pack-objects.c
* sp/ignorecase:
t0050: Fix merge test on case sensitive file systems
t0050: Add test for case insensitive add
t0050: Set core.ignorecase case to activate case insensitivity
t0050: Test autodetect core.ignorecase
git-init: autodetect core.ignorecase
* maint:
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
Add missing "short" alternative to --date in rev-list-options.txt
git-show.txt: Not very stubby these days.
Clarify repack -n documentation
log.date config variable sets the default date-time mode for the log
command. Setting log.date value is similar to using git log's --date
option.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output format from "git add -n $path" lists path to blobs that are going
to be added on a single line, separated with SP. On the other hand, the
suggested "git add -u -n" shows one path per line, like "add '<file>'\n".
Of course, these two are inconsistent.
Plain "git add -n" can afford to only say names of paths, as all it does
is to add (update). However, "git add -u" needs to be able to express
"remove" somehow. So if we need to have them formatted the same way, we
need to unify with the "git add -n -u" format. Incidentally, this is
consistent with how 'update-index' says it.
This changes the output from "git add -n $paths" but as a general
principle, output from Porcelain commands is a fair game for improvements
and not for script consumption.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We were spending a lot of time forking/execing git-cat-file and
git-hash-object. We now maintain a global Git repository object in order to use
Git.pm's more efficient hash_and_insert_object and cat_blob methods.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These functions are more efficient ways of executing `git hash-object -w` and
`git cat-file blob` when you are dealing with many files/objects.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
command_bidi_pipe hands back the stdin and stdout file handles from the
executed command. command_close_bidi_pipe closes these handles and terminates
the process.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a more appropriate location according to t/README.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This provides additional warning to users when attempting to
commit to a detached HEAD. It is configurable in color.status.nobranch.
Signed-off-by: Chris Parsons <chris@edendevelopment.co.uk>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first test in this series tests "git clone -l -s --reference B A C",
where repo B is a superset of repo A (A has one commit, B has the same
commit plus another). In this case, all objects to be cloned are already
present in B.
However, we should also test the case where the "--reference" repo is a
_subset_ of the source repo (e.g. "git clone -l -s --reference A B C"),
i.e. some objects are not available in the "--reference" repo, and will
have to be found in the source repo.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In this case, the reference repository has some useful loose objects,
but not all useful objects, and we make sure that we can find the
objects we fetch from the repository we're cloning in the new
repository, instead of potentially being distracted by the reference
repository.
Doing the wrong thing in a builtin-clone implementation would lead to
this looking for an object in the wrong place, not finding it (because
it's only in the right place), and crashing.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing fails during "pull --rebase", you cannot just clean up the
working directory and call "pull --rebase" again, since the remote branch
was already fetched.
Therefore, die early when the working directory is dirty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix chop_str not to cut in middle of utf8 multibyte chars. Without
this fix at least author name in short log may cut in middle of a
multibyte char. When the result comes to esc_html to_utf8 is called
again, which doesn't find valid utf8 and decodes using
$fallback_encoding making it even worse.
This also have the nice side effect that it actually tries to show the
first 10 _characters_, not the number of characters that happened to fit
into 10 bytes.
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git bisect" was first written, it was not possible to
checkout a detached HEAD. The detached feature appeared latter.
That's why before this patch the "git bisect" process used a
"bisect" branch to checkout new revisions to be tested (and also
a "new-bisect" one to check if the checkouts could work).
This patch makes "git bisect" checkout revisions to be tested on
a detached HEAD. This simplifies the code a bit.
The tests to check that "git bisect" does not start if a
"bisect" or a "new-bisect" branch exists are removed as they
are not relevant any more.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, when using "git bisect start" with mistaken revs
or when the checkout of the branch we want to test failed, we exited
after having written files like ".git/BISECT_START",
".git/BISECT_NAMES" and after having written "refs/bisect/bad" and
"refs/bisect/good-*" refs.
With this patch we trap all errors that can happen when writing the
new state and when we are in "bisect_next". So that we can try to
clean up everything in case of problems, using "bisect_clean_state".
This patch also contains a "bisect_write" cleanup to make it exit
on error and return 0 otherwise.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, when using for example:
$ git bisect start <stuff1> <stuff2>
with <stuff1> or <stuff2> that cannot be parsed as a revision, we
could leave a ".git/BISECT_START" file, from a previous
"git bisect start", alone.
This patch makes sure that it does not happen by removing the
"BISECT_START" file in "bisect_clean_state" and then always writing
it again at the end of "bisect_start".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds some test cases to check that "git bisect start"
doesn't leave us in a bad state, especially when it fails.
These test cases show that "git bisect start" is not atomic when it
fails and leave some files like .git/BISECT_START, and in some
cases some refs, over.
The test failures should be fixed in latter commits.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the user has put nowinsymlinks into their CYGWIN environment
variable any symlinks created by a Cygwin process (e.g. ln -s)
will not have the ".lnk" suffix. In this case workdir is still
a workdir, but our detection of looking for "info.lnk" fails
as the symlink is actually a normal file called "info".
Instead we just always use Cygwin's test executable to see if
info/exclude is a file. If it is, we assume from there on it
can be read by git-ls-files --others and is thus safe to use
on the command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commit 94503a66c5 ("gitk: Fix "wrong #
coordinates" error on reload") was correct as far as it went, but
introduced a problem because it didn't also clear out boldrows and
boldnamerows in clear_display. This resulted in Tcl errors after
scrolling through the graph for a while if some rows were highlighted.
This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
With xmlto 0.0.18 it seems to demand that no section levels are
skipped. The commit 'implement gitcvs.usecrlfattr' (8a06a63297)
one such skip, which here is removed by increasing the level of the
offender.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ar/add-unreadable:
Add a config option to ignore errors for git-add
Add a test for git-add --ignore-errors
Add --ignore-errors to git-add to allow it to skip files with read errors
Extend interface of add_files_to_cache to allow ignore indexing errors
Make the exit code of add_file_to_index actually useful
* np/pack:
pack-objects: fix early eviction for max depth delta objects
pack-objects: allow for early delta deflating
pack-objects: move compression code in a separate function
pack-objects: clean up write_object() a bit
pack-objects: simplify the condition associated with --all-progress
pack-objects: remove some double negative logic
pack-objects: small cleanup
* jk/maint-send-email-compose:
send-email: rfc2047-quote subject lines with non-ascii characters
send-email: specify content-type of --compose body
Conflicts:
t/t9001-send-email.sh
Due to 065096c (git-send-email.perl: Handle shell metacharacters in
$EDITOR properly, 2008-05-04) which is a backward incompatible change (but
it makes handling of EDITOR consistent with other parts of the system),
the test script t9001 had to be adjusted.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a given project the directory used with the -w option is almost always
the same each time. Let it be specified with 'cvsexportcommit.cvsdir' so
it's not necessary to manually add it with -w each time.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Acked-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitcli(5) already documents them, and there are no options named
--no-no-stat, --no-no-summary and --no-no-log.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that it stops trying hardlinks if any fail.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of the test is not really to test the ability of the
filesystem to keep the given x-bit, but to check is merge-recursive
correctly handles it.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patterns to the case statement could never be matched, so the hook
was a noop. This patch also replaces the non-portable use of in-place sed.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Often new Git users want to know what commands git-gui uses to make
changes, so they can learn the command line interface by mimicking
what git-gui does in response to GUI actions. Showing the direct
commands being executed is easy enough to implement but this is of
little value to end-users because git-gui frequently directly calls
plumbing, not porcelain.
Since the code is already written and tested, its fairly harmless
to include. It may not help a new end-user, but it can help with
debugging git-gui or reverse-engineering its logic to further make
changes to it or implement another GUI for Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The display of the current row number would stop working if the user
clicked on a line, or if selectedline got unset for any other reason,
because the trace on it got lost when it was unselected. This fixes
it by changing the places that unset selectedline to set it to the
empty string instead, and the places that tested for it being set or
unset to compare it with the empty string. Thus it never gets unset
now. This actually simplified the code in a few places since it can
be compared for equality with a row number now without first testing
if it is set.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The plumbing output is sacred as it is an API. We _could_ change it if it
is broken in such a way that it cannot convey necessary information fully,
but we just do not _reword_ for the sake of rewording. If somebody does
not like it, s/he is complaining too late. S/he should have been here in
early May 2005 and make the language used by the API closer to what humans
read. S/he wasn't here. Too bad, and it is too late.
And people who complain should look at a bigger picture. Look at what was
suggested by one of them and think for five seconds:
$ git checkout mytopic
-fatal: Entry 'frotz' not uptodate. Cannot merge.
+fatal: Entry 'frotz' has local changes. Cannot merge.
If you do not see something wrong with this output, your brain has already
been rotten with use of git for too long a time. Nobody asked us to
"merge" but why are we talking about "Cannot merge"?
This patch introduces a mechanism to allow Porcelains to specify messages
that are different from the ones that is given by the underlying plumbing
implementation of read-tree, so that we can reword the message Porcelains give
without disrupting the output from the plumbing.
$ git-checkout pu
error: You have local changes to 'Makefile'; cannot switch branches.
There are other places that ask unpack_trees() to n-way merge, detect
issues and let it issue error message on its own, but I did this as a
demonstration and replaced only one message.
Yes I know about C99 structure initializers. I'd love to use them but we
try to be nice to compilers without it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exit with error if cd into the "trash directory" failed (error
already reported, so just exit).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So not to leak file descriptors, close the directory after opening it.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the Tk error "wrong # coordinates: expected 0 or 4, got 2"
that sometimes occurred when reloading. The problem was that we didn't
unset the variables containing the canvas item id numbers for the
displayed rows when we cleared the canvases. Thus make_secsel would
think it had something to do when it didn't.
Thanks to Michele Ballabio for finding a way to trigger the bug
reliably.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When we see no context nor deleted line in the patch, we used to declare
that the patch creates a new file. But some people create an empty file
and then apply a patch to it. Similarly, a patch that delete everything
is not a deletion patch either.
This commit corrects these two issues. Together with the previous commit,
it allows a diff between an empty file and a line-ful file to be treated
as both creation patch and "add stuff to an existing empty file",
depending on the context. A new test t4126 demonstrates the fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On a case sensitive filesystem, "git reset --hard" might refuse to
overwrite a file whose name differs only by case, even if
core.ignorecase is set. It is not clear which circumstances cause this
behavior. This commit simply works around the problem by removing
the case changing file before running "git reset --hard".
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
NO_MKDTEMP is required to build, FREAD_READS_DIRECTORIES and the definition
of _LARGE_FILES fix test suite failures and INTERNAL_QSORT is required for
adequate performance.
Tested on AIX v5.3 Maintenance Level 06
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A patch from a foreign SCM (or plain "diff" output) often have both
preimage and postimage filename on ---/+++ lines even for a patch that
creates a new file. However, when there is a filename for preimage, we
used to insist the file to exist (either in the work tree and/or in the
index). When we cannot be sure by parsing the patch that it is not a
creation patch, we shouldn't complain when if there is no such a file.
This commit fixes the logic.
Refactor the code that validates the preimage file into a separate
function while we are at it, as it is getting rather big.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The in-place mode of sed used in t7502-commit is a non-POSIX extension.
That call of sed is replaced by a more portable version using a temporary file.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a submodule is not initialized and you do not want to change the
defaults from .gitmodules anyway, you can now say
$ git submodule update --init <name>
When "update" is called without --init on an uninitialized submodule,
a hint to use --init is printed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add paragraph for the -A option, and describe the new behaviour
that makes unreachable objects loose.
Signed-off-by: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is a cmd_merge() function in fast-import that will conflict with
builtin-merge's cmd_merge() function. To keep it consistent, rename all
cmd_*() function to parse_*()
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change "brower.konqueror.path" to "browser.konqueror.path" in
documentation.
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git config' has a '-f' option that takes the file to parse.
Using it rather than the environment variable seems more logical
and simplified.
Signed-off-by: Imran M Yousuf <imyousuf@smartitengineering.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If "gitcvs.allbinary" is set to "guess", then any file that has
not been explicitly marked as binary or text using the "crlf" attribute
and the "gitcvs.usecrlfattr" config will guess binary based on the contents
of the file.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If gitcvs.usecrlfattr is set to true, git-cvsserver will consult
the "crlf" for each file to determine if it should mark the file
as binary (-kb).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are various reasons git-cvsserver needs to manipulate the current
directory, and this patch attempts to clarify and validate such changes:
1. Temporary empty working directory (with index) for certain operations
that require an index file to work.
2. Use a temporary directory with temporary file names for doing
merges of user's dirty sandbox state with latest changes in
repository.
3. Coming up soon: Set up an index and either a valid or empty
working directory when calling git-check-attr to decide
if a file should be marked binary (-kb).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a CVS checkout, it is easy to import the CVS history by
calling "git cvsimport". However, interacting with the CVS repository
using "git cvsexportcommit" was cumbersome, since that script assumes
separate working directories for Git and CVS.
Now, you can call cvsexportcommit with the -W option. This will
automatically discover the GIT_DIR, and it will check out the parent
commit before exporting the commit.
The intended workflow is this:
$ CVSROOT=$URL cvs co module
$ cd module
$ git cvsimport
hack, hack, hack, making two commits, cleaning them up using rebase -i.
$ git cvsexportcommit -W -c -p -u HEAD^
$ git cvsexportcommit -W -c -p -u HEAD
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing or stashing, chances are that you do not care about
dirty submodules, since they are not updated by those actions anyway.
So ignore the submodules' states.
Note: the submodule states -- as committed in the superproject --
will still be stashed and rebased, it is _just_ the state of the
submodule in the working tree which is ignored.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like with the diff machinery, update-index should sometimes just
ignore submodules (e.g. to determine a clean state before a rebase).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option --ignore-submodules can now be used to ignore changes in
submodules.
Why? Sometimes it is not interesting when a submodule changed.
For example, when reordering some commits in the superproject, a dirty
submodule is usually totally uninteresting. So we will use this option
in git-rebase to test for a dirty working tree.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit fef3a7cc(cvsexportcommit: be graceful when "cvs status"
reorders the arguments), caution was taken to get the status even
for files with leading or trailing whitespace.
However, the author of that commit missed that chomp() removes only
trailing newlines. With help of the mailing list, the author realized
his mistake and provided this patch.
The idea is that we do not want to rely on a certain layout of the
output of "cvs status". Therefore we only call it with files that are
unambiguous after stripping leading and trailing whitespace.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Somewhere in the process of finishing up builtin-clone, the update of
the working tree was lost. This was due to not using the option "merge"
for unpack_trees().
Breakage noticed by Kevin Ballard.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://repo.or.cz/git-gui:
git-gui: Delete branches with 'git branch -D' to clear config
git-gui: Setup branch.remote,merge for shorthand git-pull
git-gui: Update German translation
git-gui: Don't use '$$cr master' with aspell earlier than 0.60
git-gui: Report less precise object estimates for database compression
Clarifies the git-prune man page, documenting that it only
prunes unpacked objects.
Signed-off-by: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.kernel.org/pub/scm/gitk/gitk: (44 commits)
gitk: Add a progress bar for checking out a head
gitk: Show current row number and total number of rows
gitk: Allow users to view diffs in external diff viewer
gitk: Synchronize highlighting in file view for 'f' and 'b' commands
gitk: Make updates go faster
gitk: Disable "Reset %s branch to here" when on a detached head
gitk: German translation again updated
gitk: Update German translation
gitk: Makefile/install: force permissions when installing files and dirs
gitk: Initial Swedish translation.
gitk: Spanish translation of gitk
gitk: Fix handling of tree file list with special chars in names
gitk: Reorganize processing of arguments for git log
gitk: Fix problem with target row not being in scroll region
gitk: Avoid a crash in selectline if commitinfo($id) isn't set
gitk: Fix some corner cases in computing vrowmod and displayorder
gitk: Correct a few strings and comments to say "git log"
gitk: Don't filter view arguments through git rev-parse
gitk: Fix problems with target row stuff
gitk: Handle updating with path limiting better
...
* sb/committer:
commit: Show committer if automatic
commit: Show author if different from committer
Preparation to call determine_author_info from prepare_to_commit
* bd/tests:
Rename the test trash directory to contain spaces.
Fix tests breaking when checkout path contains shell metacharacters
Don't use the 'export NAME=value' in the test scripts.
lib-git-svn.sh: Fix quoting issues with paths containing shell metacharacters
test-lib.sh: Fix some missing path quoting
Use test_set_editor in t9001-send-email.sh
test-lib.sh: Add a test_set_editor function to safely set $VISUAL
git-send-email.perl: Handle shell metacharacters in $EDITOR properly
config.c: Escape backslashes in section names properly
git-rebase.sh: Fix --merge --abort failures when path contains whitespace
Conflicts:
t/t9115-git-svn-dcommit-funky-renames.sh
* mv/format-cc:
Add tests for sendemail.cc configuration variable
git-send-email: add a new sendemail.cc configuration variable
git-format-patch: add a new format.cc configuration variable
git_config() only had a function parameter, but no callback data
parameter. This assumes that all callback functions only modify
global variables.
With this patch, every callback gets a void * parameter, and it is hoped
that this will help the libification effort.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ccc1297226 changed the behavior
of 'git repack -A' so unreachable objects are stored as loose objects.
However it did so in a naive and inn efficient way by making packs
about to be deleted inaccessible and feeding their content through
'git unpack-objects'. While this works, there are major flaws with
this approach:
- It is unacceptably sloooooooooooooow.
In the Linux kernel repository with no actual unreachable objects,
doing 'git repack -A -d' before:
real 2m33.220s
user 2m21.675s
sys 0m3.510s
And with this change:
real 0m36.849s
user 0m24.365s
sys 0m1.950s
For reference, here's the timing for 'git repack -a -d':
real 0m35.816s
user 0m22.571s
sys 0m2.011s
This is explained by the fact that 'git unpack-objects' was used to
unpack _every_ objects even if (almost) 100% of them were thrown away.
- There is a black out period.
Between the removal of the .idx file for the redundant pack and the
completion of its unpacking, the unreachable objects become completely
unaccessible. This is not a big issue as we're talking about unreachable
objects, but some consistency is always good.
- There is no way to easily set a sensible mtime for the newly created
unreachable loose objects.
So, while having a command called "pack-objects" to perform object
unpacking looks really odd, this is probably the best compromize to be
able to solve the above issues in an efficient way.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is meant to force the creation of a loose object even if it
already exists packed. Needed for the next commit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch tries to restore "old" copies of some
environment variables by using the construct:
unset var
test -z "$old_var" || var="$old_var" && export var
This is just wrong. AND-list and OR-list operators && and || have equal
precedence and they bind left to right. The second term, var="$old"
assignment always succeeds, so we always end up exporting var.
On bash and dash, exporting an unset variable has no effect. However, on
some shells (such as FreeBSD's /bin/sh), the shell exports the empty
value.
This manifested itself in this case as git-filter-branch setting
GIT_INDEX_FILE to the empty string, which in turn caused its call to
git-read-tree to fail, leaving the working tree pointing at the original
HEAD instead of the rewritten one.
To fix this, we change the short-circuit logic to better match the intent:
test -z "$old_var" || {
var="$old_var" && export var
}
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using /bin/sh from FreeBSD 6.1, the value of $? is lost
when calling a function inside the 'trap' action. This
resulted in clone erroneously indicating success when it
should have reported failure.
As a workaround, we save the value of $? before calling any
functions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
Update the programs which used the function (as add_file_to_cache).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
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>
This adds a minimalistic set of tests to recently added --add-author-from
option and existing --use-log-author option to git-svn.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In add_parents_to_list, if any parent of a revision had already been
SEEN, the current code would continue with the next parent, skipping
the test for --first-parent. This patch inverts the test for SEEN so
that the test for --first-parent is always performed.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that git checkout reports progress when checking out files, we
can use that to provide a progress bar in gitk. We re-use the green
progress bar (formerly used when reading stuff in) for that.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* maint:
wt-status.h: declare global variables as extern
builtin-commit.c: add -u as short name for --untracked-files
git-repack: re-enable parsing of -n command line option
* 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>
Add should recognize if a file is added with a different case and add
the file using its original name.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Case insensitive file handling is only active when
core.ignorecase = true. Hence, we need to set it to give the tests
in t0050 a chance to succeed. Setting core.ignorecase explicitly
allows to test some aspects of case handling even on case sensitive file
systems.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Verify if core.ignorecase is automatically set to 'true' during
repository initialization if the file system is case insensitive,
and unset or 'false' otherwise.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already detect if symbolic links are supported by the filesystem.
This patch adds autodetect for case-insensitive filesystems, such
as VFAT and others.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that repack -A will leave unreferenced objects unpacked, there is
no reason to use the -a option to repack (which will discard unreferenced
objects). The unpacked unreferenced objects will not be repacked by a
subsequent repack, and will eventually be pruned by git-gc based on the
gc.pruneExpire config option.
The previous behavior of the -A option was to retain any previously
packed objects which had become unreferenced, and place them into the newly
created pack file. Since git-gc, when run automatically with the --auto
option, calls repack with the -A option, this had the effect of retaining
unreferenced packed objects indefinitely. To avoid this scenario, the
user was required to run git-gc with the little known --prune option or
to manually run repack with the -a option.
This patch changes the behavior of the -A option so that unreferenced
objects that exist in any pack file being replaced, will be unpacked into
the repository. The unreferenced loose objects can then be garbage collected
by git-gc (i.e. git-prune) based on the gc.pruneExpire setting.
Also add new tests for checking whether unreferenced objects which were
previously packed are properly left in the repository unpacked after
repacking.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn blame produced output in the format of git blame; in environments
where there are scripts that read the output of svn blame, it's useful
to be able to use them with the output of git-svn. The git-compatible
format is still available using the new "--git-format" option.
This also fixes a bug in the initial git-svn blame implementation; it was
bombing out on uncommitted local changes.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When run from the command line, ECMerge does not automatically use the same
settings for a merge / diff that it would use when starting the GUI and loading
files manually. In the first case the built-in factory defaults would be used,
while in the second case the settings the user has specified in the GUI would
be used, which can be misleading. Specifying the "--default" command line
option changes this behavior so that always the user specfified GUI settings
are used.
Signed-off-by: Sebastian Schuberth <sschuberth@visageimaging.com>
Tested-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new option --no-binary to git-format-patch so that no binary
changes are included in the generated patches, only notices that those
files changed. This generate patches that cannot be applied, but still
is useful for generating mails for code review purposes.
See also: commit e47f306d4b, where --binary
option was turned on by default.
Signed-off-by: Caio Marcelo de Oliveira Filho <cmarcelo@gmail.com>
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>
Also fix an underallocation in walker.c::interpret_target().
Signed-off-by: Krzysztof Kowalczyk <kkowalczyk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds a couple of fields in the bar just below the upper panes
that show the row number of the currently selected commit, and how
many rows are displayed in total. The latter increments as commits
are read in, and thus functions to show that progress is being made.
This therefore also removes the code that showed progress using a
green oscillating bar in the progress bar window (which some people
disliked).
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit sequence used to do
if (file_exists(p->path))
add_file_to_cache(p->path, 0);
where both "file_exists()" and "add_file_to_cache()" needed to do a
lstat() on the path to do their work.
This cuts down 'lstat()' calls for the partial commit case by two
for each path we know about (because we do this twice per path).
Just move the lstat() to the caller instead (that's all that
"file_exists()" really does), and pass the stat information down to the
add_to_cache() function.
This essentially makes 'add_to_index()' the core function that adds a path
to the index, getting the index pointer, the pathname and the stat
information as arguments. There are then shorthand helper functions that
use this core function:
- 'add_to_cache()' is just 'add_to_index()' with the default index
- 'add_file_to_cache/index()' is the same, but does the lstat() call
itself, so you can pass just the pathname if you don't already have the
stat information available.
So old users of the 'add_file_to_xyzzy()' are essentially left unchanged,
and this just exposes the more generic helper function that can take
existing stat information into account.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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
* lt/case-insensitive:
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
This allows gitk to run an external diff viewer such as meld.
Right-click on a file in the file list view gives "External diff"
popup menu entry, which launches the selected external diff tool.
The menu entry is only active in "Patch" mode, not in "Tree" mode.
The program to run to display the diff is configurable through
Edit/Preference/External diff tool. The program is run with two
arguments, being the names of files containing the two versions to
diff. Gitk will create temporary directories called
.gitk-tmp.<pid>/<n> to place these files in, and remove them when
it's finished.
If the file doesn't exist in one or other revision, gitk will supply
/dev/null as the name of the file on that side of the diff. This may
need to be adjusted for Windows or MacOS.
[paulus@samba.org - cleaned up and rewrote some parts of the patch.]
Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is based on a patch by Eric Raible <raible@gmail.com>, but does
things a bit more simply.
Previously, 'b', backspace, and delete all did the same thing.
This changes 'b' to perform the inverse of 'f'. And both of
them now highlight the filename of the currently diff.
This makes it easier to review and navigate the diffs associated
with a particular commit using only f, b, and space because the
filename of the currently display diff will be dynamically
highlighted.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* cc/help:
documentation: web--browse: add a note about konqueror
documentation: help: add info about "man.<tool>.cmd" config var
help: use "man.<tool>.cmd" as custom man viewer command
documentation: help: add "man.<tool>.path" config variable
help: use man viewer path from "man.<tool>.path" config var
Some systems define fopen as a macro based on compiler settings.
The previous technique for reverting to the system fopen function
by merely undefining fopen is inadequate in this case. Instead,
avoid defining fopen entirely when compiling this source file.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we are deleting a local branch from refs/heads/ we need to
make sure any associated configuration stored in .git/config is
also removed (such as branch.$name.remote and branch.$name.merge).
The easiest way to do this is to use git-branch as that automatically
will look for and delete configuration keys as necessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When creating new branches if branch.autosetupmerge is not set, or
is set to true or always and we have been given a remote tracking
branch as the starting point for a new branch we want to create the
necessary configuration options in .git/config for the new branch
so that a no argument git-pull on the command line pulls from the
remote repository's branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This goes back to the method of doing updates where we translate the
revisions we're given to SHA1 ids and then remove the ones we've asked
for before or that we've already come across. This speeds up updates
enormously in most cases since it means git log doesn't have to traverse
large parts of the tree. We used to do this, but it had bugs, and commit
468bcaedbb (gitk: Don't filter view
arguments through git rev-parse) went to the slower method to avoid the
bugs.
In order to do this properly, we have to parse the command line and
understand all the flag arguments. So this adds a parser that checks
all the flag arguments. If there are any we don't know about, we
disable the optimization and just pass the whole lot to git log
(except for -d/--date-order, which we remove from the list).
With this we can then use git rev-parse on the non-flag arguments to
work out exactly what SHA1 ids are included and excluded in the list,
which then enables us to ask for just the new ones when updating.
One wrinkle is that we have to turn symmetric diff arguments (of the
form a...b) back into symmetric diff form so that --left-right still
works, as git rev parse turns a...b into a b ^merge_base(a,b).
This also updates a couple of copyright notices.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Before this patch, there were no "git bisect run" example.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git gui' has a number of options that can be specified using the
options dialog. Sometimes it is convenient to be able to specify these
from the command line, therefor document these options.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Shawn O. Pearce <speace@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch in "git-add.txt" and "git-format-patch.txt", the
commands used in the examples were "git-CMD" instead of "git CMD".
This patch fixes that.
In "git-pull.txt" only the last example had the code sample in an
asciidoc "Listing Block", and in the other two files, none.
This patch fixes that by putting all code samples in listing
blocks.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Honour the setgid and umask when re-creating the objects directory
at the destination.
cpio in copy-pass mode aims to copy file permissions which causes this
problem and cannot be disabled. Be explicit by copying the directory
structure first, honouring the permissions at the destination, then copy
the files with 0444 permissions. This also avoids bugs in some versions
of cpio.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To warn the user in case he/she might be using an unintended
committer identity.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
That would help reassure anybody while committing other's changes.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder functions definitions such that determine_author_info is
defined before prepare_to_commit. No code changes.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--batch is similar to --batch-check, except that the contents of each object is
also printed. The output's form is:
<sha1> SP <type> SP <size> LF
<contents> LF
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option allows multiple objects to be specified on stdin. For each
object specified, a line of the following form is printed:
<sha1> SP <type> SP <size> LF
If the object does not exist in the repository, a line of the following form is
printed:
<object> SP missing LF
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I separated the logic of parsing the arguments from the logic of fetching and
outputting the data. cat_one_file now does the latter.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/lstat:
diff-files: mark an index entry we know is up-to-date as such
write_index(): optimize ce_smudge_racily_clean_entry() calls with CE_UPTODATE
* 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
This change improves the calculation of the amount of horizontal
padding, so that there is always exactly 1 space of padding.
Previously, most commits had 3 spaces of padding, but commits that
didn't have any children in the graph had only 1 space of padding.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option causes a text-based representation of the history to be
printed to the left of the normal output.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new API allows the commit history to be displayed as a text-based
graphical representation.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change allows parent rewriting to be performed without causing
the log and rev-list commands to print the parents.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When having a svn:ignore that ignores the .gitignore file the -f
option to git add must be used to avoid git complaining about adding
an ignored file and hence stop the process of creating .gitignores.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In recent versions GNU's git has been renamed to gnuit, document this
while talking about how to resolve the conflict.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to help prevent regressions in the future, rename the trash directory
for all tests to contain spaces. This patch also corrects two failures that
were caused or exposed by this change.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the remainder of the issues where the test script itself is at
fault for failing when the git checkout path contains whitespace or other
shell metacharacters.
The majority of git svn tests used the idiom
test_expect_success "title" "test script using $svnrepo"
These were changed to have the test script in single-quotes:
test_expect_success "title" 'test script using "$svnrepo"'
which unfortunately makes the patch appear larger than it really is.
One consequence of this change is that in the verbose test output the
value of $svnrepo (and in some cases other variables, too) is no
longer expanded, i.e. previously we saw
* expecting success:
test script using /path/to/git/t/trash/svnrepo
but now it is:
* expecting success:
test script using "$svnrepo"
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This form is not portable across all shells, so replace instances of:
export FOO=bar
with:
FOO=bar
export FOO
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, this function correctly handles cases where the pwd contains
spaces, quotes, and other troublesome metacharacters.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the git-send-perl semantics for launching an editor when
$GIT_EDITOR (or friends) contains shell metacharacters to match
launch_editor() in builtin-tag.c. If we use the current approach
(sh -c '$0 $@' "$EDITOR" files ...), we see it fails when $EDITOR has
shell metacharacters:
$ sh -x -c '$0 $@' "$VISUAL" "foo"
+ "$FAKE_EDITOR" foo
"$FAKE_EDITOR": 1: "$FAKE_EDITOR": not found
Whereas builtin-tag.c will invoke sh -c "$EDITOR \"$@\"".
Thus, this patch changes git-send-email.perl to use the same method as the
C utilities, and additionally updates t/t9001-send-email.sh to test for
this bug.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If an element of the configuration key name other than the first or last
contains a backslash, it is not escaped on output, but is treated as an
escape sequence on input. Thus, the backslash is lost when re-loading
the configuration.
This patch corrects this by having backslashes escaped properly, and
introduces a new test for this bug.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also update t/t3407-rebase-abort.sh to expose the bug.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option adds a From: line (based on the commit's author information)
at the beginning of the body of the commit log message when sending to
svn, if a From: or Signed-off-by: header does not exist.
This, combined with --use-log-author, can retain the author field of commits
through a round trip from git to svn and back.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks to Johannes Schindelin for various comments and improvements,
including supporting cloning full bundles.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The caller first calls set_git_dir() to specify the GIT_DIR, and then
calls init_db() to initialize it. This also cleans up various parts of
the code to account for the fact that everything is done with GIT_DIR
set, so it's unnecessary to pass the specified directory around.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function may only be used before the work tree is used.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These refs can be anything, but they are most likely useful as
pointing to objects that you know are in the object database but don't
have any regular refs for. For example, when cloning with --reference,
the refs in this repository should be listed as objects that we have,
even though we don't have refs in our newly-created repository for
them yet.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The refspec refs/tags/*:refs/tags/* is sufficiently common and generic
to merit having a constant instead of generating it as needed.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is in the core so that, if the alternates file has already been
read, the addition can be parsed and put into effect for the current
process.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This takes care of copying the original contents into the replacement
file after the lock is held, so that concurrent additions can't miss
each other's changes.
[jc: munged to drop mmap in favor of copy_file.]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fetching the objects doesn't actually modify the list in any of the
code paths, so this will allow code that fetches the entire (const)
list of available refs to just pass the list in directly.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch provides a way to specify "push matching heads" using a
special refspec ":". This is useful because it allows "push = +:"
as a way to specify that matching refs will be pushed but, in addition,
forced updates will be allowed, which was not possible before.
Signed-off-by: Paolo Bonzini <bonzini@gnu.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>
The function is about checking for removed work tree item, so name it
accordingly to avoid future confusion.
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 'depth' variable doesn't reflect the actual maximum depth used
when other objects already depend on the current one.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the delta data is cached in memory until it is written to a pack
file on disk, it is best to compress it right away in find_deltas() for
the following reasons:
- we have to compress that data anyway;
- this allows for caching more deltas with the same cache size limit;
- compression is potentially threaded.
This last point is especially relevant for SMP run time. For example,
repacking the Linux repo on a quad core processor using 4 threads with
all default settings produce the following results before this change:
real 2m27.929s
user 4m36.492s
sys 0m3.091s
And with this change applied:
real 2m13.787s
user 4m37.486s
sys 0m3.159s
So the actual execution time stayed more or less the same but the
wall clock time is shorter.
This is however not a good thing to do when generating a pack for
network transmission. In that case, the network is most likely to
throttle the data throughput, so it is best to make find_deltas()
faster in order to start writing data ASAP since we can afford
spending more time between writes to compress the data
at that point.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Parsing !no_reuse_delta everywhere makes my brain spend extra
cycles wondering each time.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In many cases, the warning ends up as clutter, because the
diff is being done "behind the scenes" from the user (e.g.,
when generating a commit diffstat), and whether we show
renames or not is not particularly interesting to the user.
However, in the case of a merge (which is what motivated the
warning in the first place), it is a useful hint as to why a
merge with renames might have failed.
This patch makes the warning optional based on the code
calling into diffcore. We default to not showing the
warning, but turn it on for merges.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current rename limit default of 100 was arbitrarily
chosen. Testing[1] has shown that on modern hardware, a
limit of 200 adds about a second of computation time, and a
limit of 500 adds about 5 seconds of computation time.
This patch bumps the default limit to 200 for viewing diffs,
and to 500 for performing a merge. The limit for generating
git-status templates is set independently; we bump it up to
200 here, as well, to match the diff limit.
[1]: See <20080211113516.GB6344@coredump.intra.peff.net>
Signed-off-by: Jeff King <peff@peff.net>
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>
This eliminates a special case in the show_log() function, to help
simplify the terminator semantics. Now show_log() always prints a
newline after the log entry when use_terminator is set, even if the log
message is empty.
This change should only affect the --pretty=tformat output, since that
was the only way to trigger this special case.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we are on a detached head - since gitk does not display where
we are - reset has no sense, so disable the relevant line on the
context menu, and point out to the user that we are on a detached head.
Otherwise, a reset from gitk when on a detached head returns the
error:
can't read "headids()": no such element in array
can't read "headids()": no such element in array
while executing
"removehead $headids($name) $name"
(procedure "movehead" line 4)
invoked from within
"movehead $newhead $mainhead"
(procedure "readresetstat" line 20)
invoked from within
"readresetstat file4"
("eval" body line 1)
invoked from within
"eval $script"
(procedure "dorunq" line 9)
invoked from within
"dorunq"
("after" script)
[paulus@samba.org: changed menu item to "Detached head: can't reset"]
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The msg-files msgs/*.msg used to be installed with mode 755 although
they're not executables. With this commit, files are forced to be
installed with mode 644, directories and executables with mode 755.
Signed-off-by: Paul Mackerras <paulus@samba.org>
I copied the Italian translation and translated the strings
to Spanish starting from there. This incorporates suggestions
from Wincent Colaiuta and Carlos Rica.
Signed-off-by: Santiago Gala <sgala@apache.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When using git-cvsimport, the author is inferred from the cvs commit,
e.g. cvs commit logname is foobaruser, then the author field in git
results in:
Author: foobaruser <foobaruser>
Which is not perfect, but perfectly acceptable given the circumstances.
The default git-svn import however, results in:
Author: foobaruser <foobaruser@acf43c95-373e-0410-b603-e72c3f656dc1>
When using mixes of imports, from CVS and SVN into the same git
repository, you'd like to harmonise the imports to the format cvsimport
uses.
git-svn supports an experimental option --use-log-author which currently
results in the same logentry as without that option when no From: or
Signed-off-by: is found in the logentry ($email currently ends up empty,
and hence is generated again).
This patches harmonises the result with cvsimport, and makes
git-svn --use-log-author produce:
Author: foobaruser <foobaruser>
Signed-off-by: Stephen R. van den Berg <srb@cuci.nl>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most users should be using git-gc instead of directly
calling prune. For those who really do want more information
on pruning, let's point them at git-fsck, which goes into
slightly more detail on reachability.
And since we're pointing users there, let's make sure
reflogs are mentioned in git-fsck(1).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
xread() and xwrite() return ssize_t values as their native POSIX
counterparts read(2) and write(2).
To be consistent, read_in_full() and write_in_full() should also return
ssize_t values.
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>
The command
git svn clone (URL of an empty SVN repo here)
works, creates an empty git repository. I can perform the initial
commit there, but then, "git svn dcommit" says :
Use of uninitialized value in concatenation (.) or string at .../git-svn line 414.
Committing to ...
Unable to determine upstream SVN information from HEAD history
I guess a correct management of the initial commit in git-svn would be
hard to implement, but at least, the error message can be improved.
First step is something like the patch below, and better would be for
"git svn clone" to warn that it won't be able to do much with the
cloned repo.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
make git status act similar to git log and git diff by presenting long
output in a pager.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
cvsimport: always pass user data to "system" as a list
fix reflog approxidate parsing bug
Fix use after free() in builtin-fetch
fetch-pack: do not stop traversing an already parsed commit
Use "=" instead of "==" in condition as it is more portable
Some projects prefer to always CC patches to a given mailing list. In
these cases, it's handy to configure that address once.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some projects prefer to always CC patches to a given mailing list. In
these cases, it's handy to configure that address once.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The purpose of --first-parent is to view the tree without looking at
side branche. This is accomplished by pretending there are no other
parents than the first parent when encountering a merge.
The current code marks the other parents as seen, which means that the tree
traversal will behave differently depending on the order merges are handled.
When a fast forward is artificially recorded as a merge,
-----
/ \
D---E---F---G master
the current first-parent code considers E to be seen and stops the
traversal after showing G and F.
Signed-off-by: Stephen R. van den Berg <srb@cuci.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The resulting data is zero terminated after the read loop, but
the subsequent loop that scans for '\n' will overrun the buffer.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Alex Riesen pointed out that displaying a commit in 'tree' mode fails
if some files have names with special characters such as '{' or '}' in
them, due to the fact that we treat the line returned from git ls-tree
as a Tcl list at one point.
This fixes it by doing what I originally intended but didn't quite
get right. We split the line from git ls-tree at the first tab and
treat the part before the tab as a list (which is OK since it doesn't
have special characters in it) and the part after the tab as the
filename.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Before this patch something like:
$ git rev-parse --verify <good-rev> <junk>
worked whatever junk was as long as <good-rev> could be parsed
correctly.
This patch makes "git rev-parse --verify" error out when passed
any junk after a good rev.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently "git rev-parse --verify <something>" is often used with
its error output redirected to /dev/null. This patch makes it
easier to do that.
The -q|--quiet option is designed to work the same way as it does
for "git symbolic-ref".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael G. Noll said in comments to the "Switching my code repository from
Subversion (SVN) to git" article (http://tinyurl.com/37v67l) in his "My
digital moleskine" blog, that one of the things he is missing in gitweb
from SVN::Web is an RSS feed with news/information of the current view
(including RSS feed for single file or directory).
This is not exactly true, as since refactoring feed generation in af6feeb
(gitweb: Refactor feed generation, make output prettier, add Atom feed,
2006-11-19), gitweb can generate feeds (RSS or Atom) for history of a
given branch, history limited to a given directory, or history of a given
file. Nevertheless this required handcrafting the URL to get wanted RSS
feed.
This commit makes gitweb select feed links in the HTML header and in
page footer depending on current view (action). It is more elaborate,
and I guess more correct, than simple patch adding $hash ('h')
parameter to *all* URLs, including feed links, by Jean-Baptiste Quenot
Subject: [PATCH] gitweb: Add hash parameter in feed URL when a hash
is specified in the current request
Message-ID: <ae63f8b50803211138y6355fd11pa64cda50a1f53011@mail.gmail.com>
If $hash ('h') or $hash_base ('hb') parameter is a branch name
(i.e. it starts with 'refs/heads/'; all generated URLs use this form
to discriminate between tags and heads), it is used in feed URLs; if
$file_name ('f') is defined, it is used in feed URLs. Feed title is
set according to the kind of web feed: it is either 'log' for generic
feed, 'log of <branch>', 'history of <filename>' for generic history
(using implicit or explicit HEAD, i.e. current branch) or 'history of
<filename> on <branch>'.
There are special cases: 'heads' and 'forks' views should use OPML
providing list of available feeds; 'tags' probably also should use
OPML; there is no web feed equivalent to 'search' view. Currently all
those cases fallback to (show) default feed. Such feed link uses
"generic" class, and is shown in slightly lighter color for
distinction.
Currently feed can have but one starting point, and does not support
negative (exclude) commit arguments. Therefore for now for *diff
views it is chosen that feed follow the "to" part: to-name, to-commit
for 'blobdiff', 'treediff' and 'commitdiff' views.
Generating parameters for href() for feed link was separated
(refactored) into get_feed_info() subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git add *" is actually fundamentally different from "git add .", and
yeah, you should generally use the latter.
The reason? The argument list is actually something different from what
you think it is. For git, it's a "pathspec", so what actualy happens is
that in *both* cases, it will really traverse the whole tree, and then
match every file it finds against the pathspec.
So think of the arguments not as a file list, but as a random bunch of
patterns to match against the files you have!
Which is why the cost is actually approximately O(n*m), where "n" is the
size of the working tree, and "m" is the number of pathspecs.
So the reason "git add ." is fast is actually that "m" in that case is
just 1 (just one trivial pattern), and then "git add *" is slow because
"m" is large (lots of complicated patterns). In both cases, 'n' is the
same (== the whole set of files in your working tree).
Anyway, here's a trivial patch that doesn't change this fundamental fact,
but that avoids doing anything *expensive* until we've done some cheap
initial tests. It may or may not help your test-case, but it's pretty
simple and it matches the other git optimizations in this area (ie
"conceptually handle the general case, but optimize the simple cases where
we can exit early")
Notice how this patch doesn' actually change the fundamental O(n^2)
behaviour, but it makes it much cheaper by generally avoiding the
expensive 'fnmatch' and 'strlen/strncmp' when they are obviously not
needed.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes a struct ref able to represent a symref, and makes http.c
able to recognize one, and makes transport.c look for "HEAD" as a ref
in the list, and makes it dereference symrefs for the resulting ref,
if any.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies a few things, makes a few things slightly more
complicated, but, more importantly, allows that, when struct ref can
represent a symref, http_fetch_ref() can return one.
Incidentally makes the string that http_fetch_ref() gets include "refs/"
(if appropriate), because that's how the name field of struct ref works.
As far as I can tell, the usage in walker:interpret_target() wouldn't have
worked previously, if it ever would have been used, which it wouldn't
(since the fetch process uses the hash instead of the name of the ref
there).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This note explains how to work around the fact that we try to use
kfmclient to launch konqueror.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch also describes the current behavior for "konqueror" and
how to modify it using "man.<tool>.cmd" if needed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently "git help -m GITCMD" is restricted to a set of man viewers
defined at compile time. You can subvert the "man.<tool>.path" to
force "git help -m" to use a different man, viewer, but if you have a
man viewer whose invocation syntax does not match one of the current
tools then you would have to write a wrapper script for it.
This patch adds a git config variable "man.<tool>.cmd" which allows a
more flexible man viewer choice.
If you run "git help -m GITCMD" with the "man.viewer" config variable
set to an unrecognized tool then it will query the "man.<tool>.cmd"
config variable. If this variable exists, then the specified tool will
be treated as a custom man viewer and it will be run in a shell with
the man page name of the GITCMD added as extra parameter.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch documents the "man.<tool>.path" configuration
variable.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch implements reading values from "man.<tool>.path"
configuration variables, and using these values as pathes to
the man viewer <tool>s when lauching them.
This makes it possible to use different version of the tools
than the one on the current PATH, or maybe a custom script.
In this patch we also try to launch "konqueror" using
"kfmclient" even if a path to a konqueror binary is given
in "man.konqueror.path".
The "man_viewer_list" becomes a simple string list to simplify
things for the following patches.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I often find myself pulling patches off of other peoples trees using
cherry-pick, and following it with an immediate 'git commit --amend -s'
command. Eliminate the need for a double commit by allowing signoff on a
cherry-pick or revert.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This moves the scanning of the argument list for each view into a
new function, parseviewargs, which is called from start_rev_list.
This also makes the date mode and the merge mode be per-view rather
than global. In merge mode, we work out the list of relevant files
in a new function called from start_rev_list, so it will be updated
on File->Reload. Plus we now do that after running the argscmd, so
if we have one and it generates a -d or --merge option they will be
correctly handled now.
The other thing this does is to make errors detected in start_rev_list
not be fatal. Now instead of doing exit 1 we just pop up and error
window and put "No commits selected" in the graph pane.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* 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
Apparently aspell 0.50 does not recognize "$$cr master" as a command,
but instead tries to offer suggestions for how to correctly spell
the word "cr". This is not quite what we are after when we want
the name of the current dictionary.
Instead of locking up git-gui waiting for a response that may never
come back from aspell we avoid sending this command if the binary
we have started claims to be before version 0.60.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 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
* maint:
post-receive-email: fix accidental removal of a trailing space in signature line
Escape project names before creating pathinfo URLs
Escape project name in regexp
bash: Add completion for git diff --base --ours --theirs
diff-options.txt: document the new "--dirstat" option
After typing 'git remote ', the subcommand options were not shown. Fix it
by adding the missing __gitcomp call.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the similar patch from David Kågedal [1], "this will make
it a little less posix-dependent and more efficient." However, there
are two other areas that need to replaced, namely
git-run-command-region and git-run-hooks. This patch implements the
changes of [1] onto those Emacs Lisp functions.
If unpatched, using the git port "msysgit" on Windows will require
defadvice changes as shown at [2] (also explained at 4msysgit.git
[3]).
I have tested git-run-command-region on msysgit, because this is
always called by git-commit (via git-commit-tree <- git-do-commit <-
git-commit-file). However, I could not test git-run-hooks because it
currently does not work on the Emacs Windows port. The latter reports
the hooks files as a+rw and a-x, despite msysgit and cygwin chmod
setting on the respective files.
References:
[1] f27e558643
[2] http://groups.google.com/group/msysgit/browse_thread/thread/b852fef689817707
[3] http://repo.or.cz/w/git/mingw/4msysgit.git?a=commit;h=3c30e5e87358eba7b6d7dcd6301ae8438f0c30ea
Signed-off-by: Clifford Caoile <piyo@users.sourceforge.net>
Acked-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
These options filter the output from git branch to only include branches
whose tip is either merged or not merged into HEAD.
The use-case for these options is when working with integration of branches
from many remotes: `git branch --no-merged -a` will show a nice list of merge
candidates while `git branch --merged -a` will show the progress of your
integration work.
Also, a plain `git branch --merged` is a quick way to find local branches
which you might want to delete.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
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
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>
* 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:
git clean: Add test to verify directories aren't removed with a prefix
git clean: Don't automatically remove directories when run within subdirectory
git-submodule - possibly use branch name to describe a module
On startup, git-gui warns if there are many loose objects. It does so by
saying, e.g., that there are "approximately 768 loose objects". But isn't
"768" a very accurate number? Lets say "750", which (while still being a
very precise number) sounds much more like an estimation.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The earlier one botched the return value logic between config_bool and
config_bool_and_int. The former should normalize between 0 and 1 while
the latter should give back full range of integer values.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit teaches 'git commit/status' show a new 'Modified submodules'
section, which is an output from:
git submodule summary --cached --for-status --summary-limit <limit>
just before the 'Untracked files' section.
The <limit> is given by the config variable status.submodulesummary
to limit the submodule summary size. status.submodulesummary is a
bool/int variable with value:
- false or 0 by default to disable the summary, or
- positive number to limit the summary size, or
- true or negative number to unlimit the summary size.
Also mention status.submodulesummary in the documentation.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --for-status option is mainly used by builtin-status/commit.
It adds 'Modified submodules:' line at top and '# ' prefix to all
following lines.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This does not make any difference when running diff-files alone, but if
you internally run run_diff_files() and then run other operations further
on the index, we do not have to run lstat(2) again on entries we already
have checked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When writing the index out, we need to check the work tree again to see if
an entry whose timestamp indicates that it could be "racily clean", in
order to smudge it if it is stat-clean but with modified contents.
However, we can skip this step for entries marked with CE_UPTODATE,
which are known to be the really clean (i.e. the one we already have
checked when we prepared the index). This will reduce lstat(2) calls
necessary in git-status.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are the command line option equivalents of the 'merge.log' config
variable.
The patch also updates documentation and bash completion accordingly, and
adds a test.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are new synonyms to the '--(no-)summary' option and the
'merge.summary' config variable, but are consistent with the soon to be
added 'merge --(no-)log' options. The 'merge.summary' config variable and
'--(no-)summary' options are still accepted, but are advertised to be
removed in the future.
'merge.log' takes precedence over 'merge.summary' if they are both set
inconsistently.
Update documentation and tests accordingly.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This variable has the same effect, as 'merge.diffstat'.
Also mention it in the documentation.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option has the same effect as '--(no-)summary' (i.e. whether to
show a diffsat at the end of the merge or not), and it is consistent
with the '--stat' option of other git commands.
Documentation, tests, and bash completion are updaed accordingly, and the
old --summary option is marked as being deprected.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Include the new file from config.txt and git-merge.txt.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new function can be used by config parsers to tell if a variable
is simply set, set to 1, or set to "true".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
bisect: fix bad rev checking in "git bisect good"
revision.c: make --date-order overriddable
git-submodule: Avoid 'fatal: cannot describe' message
Force the medium pretty format on calls to git log
Fix section about backdating tags in the git-tag docs
Document option --only of git commit
Documentation/git-request-pull: Fixed a typo ("send" -> "end")
Users are not often aware of the fact that "git bisect -h" can give
them a long usage description, as "git bisect" seems to accept only
dashless subcommands like "start", "good", ...
That's why this patch adds a "git bisect help" subcommand that just
calls "git bisect -h". This new subcommand is also fully documented
in the short usage string (that "git bisect" gives), in the long
usage string and in the man page (that "git help bisect" gives).
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This attached patch introduces a single bit "use_terminator" in "struct
rev_info", which is normally false (i.e. most formats use separator
semantics) but by flipping it to true, you can ask for terminator
semantics just like oneline format does.
The function get_commit_format(), which is what parses "--pretty=" option,
now takes a pointer to "struct rev_info" and updates its commit_format and
use_terminator fields. It used to return the value of type "enum
cmit_fmt", but all the callers assigned it to rev->commit_format.
There are only two cases the code turns use_terminator on. Obviously, the
traditional oneline format (--pretty=oneline) is one of them, and the new
case is --pretty=tformat:... that acts like --pretty=format:... but flips
the bit on.
With this, "--pretty=tformat:%H %s" acts like --pretty=oneline.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many other commands use the "no arguments" form to show a
list (e.g., git-branch, git-tag). While we did show all
remotes for just "git remote", we displayed a usage error
for "git remote show" with no arguments. This is
counterintuitive, since by giving it _more_ information, we
get _less_ result.
The usage model can now be thought of as:
- "git remote show <remote>": show a remote
- "git remote show": show all remotes
- "git remote": assume "show"; i.e., shorthand for "git remote show"
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, a fetch like:
git fetch git://some/url
would show no ref status output (just the object downloading
status, if there was any), leading to some confusion.
With this patch, we now show the usual ref table, with
remote refs going into FETCH_HEAD. Previously this output
was shown only if "-v"erbose was specified.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-fetch: fix status output when not storing tracking ref
core-tutorial.txt: Fix showing the current behaviour.
git-archive: ignore prefix when checking file attribute
Fix documentation syntax of optional arguments in short options.
It disables git-gc --auto when you are running Linux and you are
not on AC.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If such a hook is available and exits with a non-zero status, then
git-gc --auto won't run.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we pick 'mi' between 'lo' and 'hi' at 50%, which was what the
simple binary search did, we are halving the search space
whether the entry at 'mi' is lower or higher than the target.
The previous patch was about picking not the middle but closer
to 'hi', when we know the target is a lot closer to 'hi' than it
is to 'lo'. However, if it turns out that the entry at 'mi' is
higher than the target, we would end up reducing the search
space only by the difference between 'mi' and 'hi' (which by
definition is less than 50% --- that was the whole point of not
using the simple binary search), which made the search less
efficient. And the risk of overshooting becomes very high, if
we try to be too precise.
This tweaks the selection of 'mi' to be a bit closer to the
middle than we would otherwise pick to avoid the problem.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of counting added and removed lines (and mixing the byte size
reported for binary files in the result), summarize the extent of damage
the same way as we count similarity for rename detection.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when looking for a packed object from the pack idx, a
simple binary search is used.
A conventional binary search loop looks like this:
unsigned lo, hi;
do {
unsigned mi = (lo + hi) / 2;
int cmp = "entry pointed at by mi" minus "target";
if (!cmp)
return mi; "mi is the wanted one"
if (cmp > 0)
hi = mi; "mi is larger than target"
else
lo = mi+1; "mi is smaller than target"
} while (lo < hi);
"did not find what we wanted"
The invariants are:
- When entering the loop, 'lo' points at a slot that is never
above the target (it could be at the target), 'hi' points at
a slot that is guaranteed to be above the target (it can
never be at the target).
- We find a point 'mi' between 'lo' and 'hi' ('mi' could be
the same as 'lo', but never can be as high as 'hi'), and
check if 'mi' hits the target. There are three cases:
- if it is a hit, we have found what we are looking for;
- if it is strictly higher than the target, we set it to
'hi', and repeat the search.
- if it is strictly lower than the target, we update 'lo'
to one slot after it, because we allow 'lo' to be at the
target and 'mi' is known to be below the target.
If the loop exits, there is no matching entry.
When choosing 'mi', we do not have to take the "middle" but
anywhere in between 'lo' and 'hi', as long as lo <= mi < hi is
satisfied. When we somehow know that the distance between the
target and 'lo' is much shorter than the target and 'hi', we
could pick 'mi' that is much closer to 'lo' than (hi+lo)/2,
which a conventional binary search would pick.
This patch takes advantage of the fact that the SHA-1 is a good
hash function, and as long as there are enough entries in the
table, we can expect uniform distribution. An entry that begins
with for example "deadbeef..." is much likely to appear much
later than in the midway of a reasonably populated table. In
fact, it can be expected to be near 87% (222/256) from the top
of the table.
This is a work-in-progress and has switches to allow easier
experiments and debugging. Exporting GIT_USE_LOOKUP environment
variable enables this code.
On my admittedly memory starved machine, with a partial KDE
repository (3.0G pack with 95M idx):
$ GIT_USE_LOOKUP=t git log -800 --stat HEAD >/dev/null
3.93user 0.16system 0:04.09elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+55588minor)pagefaults 0swaps
Without the patch, the numbers are:
$ git log -800 --stat HEAD >/dev/null
4.00user 0.15system 0:04.17elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+60258minor)pagefaults 0swaps
In the same repository:
$ GIT_USE_LOOKUP=t git log -2000 HEAD >/dev/null
0.12user 0.00system 0:00.12elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+4241minor)pagefaults 0swaps
Without the patch, the numbers are:
$ git log -2000 HEAD >/dev/null
0.05user 0.01system 0:00.07elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+8506minor)pagefaults 0swaps
There isn't much time difference, but the number of minor faults
seems to show that we are touching much smaller number of pages,
which is expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The presence of a .git directory used to be good enough evidence that
GIT-VERSION-GEN could use 'git describe' to get a version number. But
now .git might as well be a file so the test must be extended to cater for
such setups.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-submodule tries to detect 'active' submodules, it checks for the
existence of a directory named '.git'. This isn't good enough now that .git
can be a file pointing to the real $GIT_DIR so the tests are changed to
reflect this.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When .git in a submodule is a file, resolve_gitlink_ref() needs to pick up
the real GIT_DIR of the submodule from that file.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch allows .git to be a regular textfile containing the path of
the real git directory (prefixed with "gitdir: "), which can be useful on
platforms lacking support for real symlinks.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This expands on the previous patch, and allows "git add" to sanely handle
a filename that has changed case, keeping the case in the index constant,
and avoiding aliases.
In particular, if you have an index entry called "File", but the
checked-out tree is case-corrupted and has an entry called "file"
instead, doing a
git add .
(or naming "file" explicitly) will automatically notice that we have an
alias, and will replace the name "file" with the existing index
capitalization (ie "File").
However, if we actually have *both* a file called "File" and one called
"file", and they don't have the same lstat() information (ie we're on a
case-sensitive filesystem but have the "core.ignorecase" flag set), we
will error out if we try to add them both.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies the matching case of "I already have this file and it is
up-to-date" and makes it do the right thing in the face of
case-insensitive aliases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is immaterial on sane filesystems, but if you have a broken (aka
case-insensitive) filesystem, and the objective is to remove the file
'abc' and replace it with the file 'Abc', then we must make sure to do
the removal first.
Otherwise, you'd first update the file 'Abc' - which would just
overwrite the file 'abc' due to the broken case-insensitive filesystem -
and then remove file 'abc' - which would now brokenly remove the just
updated file 'Abc' on that broken filesystem.
By doing removals first, this won't happen.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we find an unexpected file, see if that filename perhaps exists in a
case-insensitive way in the index, and whether the file matches that. If
so, ignore it as a known pre-existing file of a different name.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
..and start using it for directory entry traversal (ie "git status" will
not consider entries that match an existing entry case-insensitively to
be a new file)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now nobody uses it, but "index_name_exists()" gets a flag so
you can enable it on a case-by-case basis.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows verify_absent() in unpack_trees() to use the hash chains
rather than looking it up using the binary search.
Perhaps more importantly, it's also going to be useful for the next phase,
where we actually start looking at the cache entry when we do
case-insensitive lookups and checking the result.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's really totally separate functionality, and if we want to start
doing case-insensitive hash lookups, I'd rather do it when it's
separated out.
It also renames "remove_index_entry()" to "remove_name_hash()", because
that really describes the thing better. It doesn't actually remove the
index entry, that's done by "remove_index_entry_at()", which is something
very different, despite the similarity in names.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mk/unpack-careful:
t5300: add test for "index-pack --strict"
receive-pack: allow using --strict mode for unpacking objects
unpack-objects: fix --strict handling
t5300: add test for "unpack-objects --strict"
unpack-objects: prevent writing of inconsistent objects
* fl/send-email-outside:
send-email: Don't require to be called in a repository
Git.pm: Don't require repository instance for ident
Git.pm: Don't require a repository instance for config
var: Don't require to be in a git repository.
The earlier one did not correctly propagate GITWEB_CONFIG_SYSTEM from
Makefile to generated gitweb.cgi script.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for creating a new tag object and retaining the tag message,
author, and date when rewriting tags. The gpg signature, if one exists,
will be stripped.
This adds nearly proper tag name filtering to filter-branch. Proper tag
name filtering would include the ability to change the tagger, tag date,
tag message, and _not_ strip a gpg signature if the tag did not change.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
From a distribution point of view, configuration files for applications
should reside in /etc/. On the other hand it's convenient for multiple
instances of gitweb (e.g. virtual web servers on a single machine) to have
a per-instance configuration file, just as gitweb currently supports
through the file gitweb_config.perl next to the cgi.
To support both at runtime, this commit introduces GITWEB_CONFIG_SYSTEM as
a system-wide configuration file which will be used as a fallback if the
config file sprecified throug GITWEB_CONFIG does not exist.
See also
http://bugs.debian.org/450592
Signed-off-by: Gerrit Pape <pape@smarden.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the 'p'atch command, instead of just throwing out any mode
change, present it to the user in the same way that we show hunks.
This way, the mode change can be staged independently from the changes
to the contents.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a path is examined in the patch subcommand, any mode changes in
the file are given to use in the diff header by git-diff. If no hunks
are staged, then we throw out that header and do not touch the
path. But if _any_ hunks are staged, we use the header, and the mode
is changed together with the contents.
Since the 'p'atch command should just be dealing with hunks that are
shown to the user, it makes sense to just ignore mode changes
entirely. We do squirrel away the mode, though, since the next patch
will allow users to select the mode update separately.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds a %xXX format which inserts two hexdigits after %x as a byte
value in the resulting string. This can be used to add a NUL byte or any
other byte that can make machine parsing easier. It is also necessary to
use fwrite to print out the data since printf will terminate if you feed
it a NUL.
Signed-off-by: Govind Salinas <blix@sophiasuchtig.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "git rebase [--onto O] A B" to omit an unnecessary checkout
of branch B before it goes on.
"git-rebase" originally was about rebasing the current branch to somewhere
else, and when the extra parameter to name which branch to rebase was
added, it defined the semantics to the safest but stupid "first switch to
the named branch and then operate exactly the same way as if we were
already on that branch".
But the first thing the real part of "rebase" does is to reset the work
tree and the index to the "onto" commit. Which means the "rebase that
branch" form switched the work tree to the tip of the branch only to
immediately switch again to another commit. This was wasteful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We might not have some configuration variables available, but if the
user doesn't care about that, neither should we. Still use the
repository if it is available, though.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git var doesn't require to be called in a repository anymore,
so don't require it either.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git config itself doesn't require to be called in a repository,
so don't add arbitrary restrictions.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git var works fine even when not called in a git repository. So
don't require it.
This will make it possible to remove this pre-condition for some
other git commands as well.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since we limit the rate at which we do updates to the canvas scrolling
regions, it's possible to get into selectline for a row that is
outside the currently-set scrolling region. When this happens,
selectline can't scroll to show the selected line, and as a
consequence, drawvisible chooses some other bogus row to be the
target row.
This fixes it by calling setcanvscroll from selectline in this case.
We also set selectedline (and currentid) before calling drawvisible
so that drawvisible makes the right choice of target row.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Occasionally I see a crash in selectline with commitinfo($id) not
set. This makes sure it is set by calling getcommit $id if it isn't.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This adds test for indexing packs with --strict option, basically the same
as c0e809e (t5300: add test for "unpack-objects --strict") has done for
unpack-objects.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a configuration variable receive.fsckobjects is set,
receive-pack runs unpack-objects with --strict mode to check all
received objects.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier attempt (which was reverted) called added_object() (by the way,
the function should be renamed to resolve_dependents() --- it is called
when we have a complete object data, and is responsible to resolve pending
deltified objects that use this object as their delta base object) without
updating obj_list[nr].sha1 with the correct value.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds test for unpacking deltified objects with --strict option.
- unpacking full trees with --strict should pass;
- unpacking only trees with --strict should be rejected due to
missing blobs;
- unpacking only trees with --strict into an existing
repository with necessary blobs should succeed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces a strict mode, which ensures that:
- no malformed object will be written
- no object with broken links will be written
The patch ensures this by delaying the write of all non blob object.
These object are written, after all objects they link to are written.
An error can only result in unreferenced objects.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
First, insertfakerow and removefakerow weren't updating vrowmod,
and hence displayorder was not getting updated when it needed to,
in the case where the fake row was being inserted into or removed
from the last arc. The comparison of varctok vs vtokmod was moved
into modify_arc for these cases (and for the call in rewrite_commit)
to avoid duplicating the extra code needed. Second, the logic in
update_arcrows didn't end up truncating displayorder and unsetting
cached_commitrow if the first modified row was in the last arc.
This fixes these problems.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Previously we passed the arguments indicating what commits the user
wants to view through git rev-parse to get a list of IDs (positive and
negative), then gave that to git log. This had a couple of problems,
notably that --merge and --left-right didn't get handled properly.
Instead we now just pass the original arguments to git log. When doing
an update, we append --not followed by the list of commits we have seen
that have no children, since we have got (or will get) their ancestors
from the first git log. If the first git log isn't finished yet, we
might get some duplicates from the second git log, but that doesn't
cause any problem.
Also get rid of the unused vnextroot variable.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Occasionally the target row stuff would scroll the display to some
uninteresting commit while reading. There were two problems: one
was that drawvisible would set targetrow even if there was no target
previously and no row selected, and the other was that it was possible
for the target row to get pushed down past numcommits, if drawvisible
was called after rows were added but before layoutmore got run.
The first problem is fixed by just not setting targetrow/id unless
there is a selected row or they were set previously.
The second problem is fixed by updating numcommits immediately new
rows are added. This leads to a simplification of layoutmore and
chewcommits but also means that some of the things that were done in
layoutmore now need to be done elsewhere, since layoutmore can no
longer use numcommits to know how much it has seen previously.
Hence the changes to getcommits, initlayout and setcanvscroll.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When updating the graph, gitk uses a git log command with commit
limiting in order to get just the new commits. When path limiting
is also in effect, git log rewrites the parents of the commits it
outputs in order to represent just the subgraph that modifies the
listed paths, but it doesn't rewrite the parents on the boundary
of the graph. The result is that when updating, git log does not
give gitk the information about where the new commits join in to
the existing graph.
This solves the problem by explicitly rewriting boundary parents
when updating. If we are updating and are doing path limiting,
then when gitk finds an unlisted commit (one where git log puts a
"-" in front of the commit ID to indicate that it isn't actually
part of the graph), then gitk will execute:
git rev-list --first-parent --max-count=1 $id -- paths...
which returns the first ancestor that affects the listed paths.
(Currently gitk executes this synchronously; it could do it
asynchronously, which would be more complex but would avoid the
possibility of the UI freezing up if git rev-list takes a long time.)
Then, if the result is a commit that we know about, we rewrite the
parents of the children of the original commit to point to the new
commit. That is mostly a matter of adjusting the parents and children
arrays and calling fix_reversal to fix up the graph.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Because we weren't fixing up vlastins when moving an arc from one
place to another, it was possible for us later to decide to move
an arc to the wrong place, and end up with an arc disconnected from
the rest of the graph. This fixes it by updating vlastins when
necessary.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes a bug in updating the graph after we have cherry-picked
a commit in gitk and then added some new stuff externally. First,
we weren't updating viewincl with the new head added by the cherry-
pick. Secondly, getcommitlines was doing bad things if it saw a
commit that was already in the graph (was already in an arc). This
fixes both things. If getcommitlines sees a commit that is already
in the graph, it ignores it unless it was not listed before and is
listed now. In that case it doesn't assign it a new arc now, and
doesn't re-add the commit to its arc.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When there are N deleted paths and M created paths, we used to
allocate (N x M) "struct diff_score" that record how similar
each of the pair is, and picked the <src,dst> pair that gives
the best match first, and then went on to process worse matches.
This sorting is done so that when two new files in the postimage
that are similar to the same file deleted from the preimage, we
can process the more similar one first, and when processing the
second one, it can notice "Ah, the source I was planning to say
I am a copy of is already taken by somebody else" and continue
on to match itself with another file in the preimage with a
lessor match. This matters to a change introduced between
1.5.3.X series and 1.5.4-rc, that lets the code to favor unused
matches first and then falls back to using already used
matches.
This instead allocates and keeps only a handful rename source
candidates per new files in the postimage. I.e. it makes the
memory requirement from O(N x M) to O(M).
For each dst, we compute similarlity with all sources (i.e. the
number of similarity estimate computations is still O(N x M)),
but we keep handful best src candidates for each dst.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The insertrow/removerow functions were really only suitable for
inserting/removing a fake row such as the ones used for showing
the local changes. When used to insert a real new row from a
cherry-pick, they left things in an inconsistent state which then
caused various strange layout errors.
This renames insertrow/removerow to insertfakerow/removefakerow
and adds a new insertrow that does actually go to all the trouble
of creating a new arc and setting it up. This is more work but
keeps things consistent.
This also fixes a bug where cherrypick was not setting mainheadid,
and one where selectline wasn't always resulting in targetrow/id
being set to the selected row/id. Also insert/removefakerow now
adjust numcommits and call setcanvscroll.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Some of the stuff that commit 31c0eaa8cc
added to drawvisible isn't appropriate to do when we have no commits,
and this was causing a Tcl error if gitk was invoked in such a fashion
that no commits were selected. This fixes it by bailing out of
drawvisible early if there are no commits displayed.
Bug reported by Johannes Sixt.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes a bug where changing the commit range or file list for an
existing view and then clicking OK would cause gitk to go into an
infinite loop. The problem was that newviewok was invoking reloadcommits
via "run reloadcommits", but reloadcommits wasn't explicitly returning
0, and whatever it was returning was causing dorunq to run it over
and over again. This fixes it by making reloadcommits return 0.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This makes gitk select the new commit when cherry-picking, and select
the new checked-out head when resetting or checking out a branch.
This feels more natural because the user is usually more interested
in that commit now than whatever was selected before.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Instead of selecting the first commit that appears, this makes gitk
select the currently checked out head, if the user hasn't explicitly
selected some other commit by the time it appears. If the head hasn't
appeared by the time the graph is complete, then we select the first
real commit.
This applies both for graph updates and when the graph is being read
in initially.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The make_disporder function has an optimization where it assumed that
if displayorder was already long enough and the first entry in it for
a particular arc was non-null, then the whole arc was present. This
turns out not to be true in some circumstances, since we can add a
commit to an arc (which truncates displayorder to the previous end of
that arc), then call make_disporder for later arcs (which will pad
displayorder with null elements), then call make_disporder for the
first arc - which won't update the null elements.
This fixes it by changing the optimization to check the last element
for the arc instead of the first.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Despite the name, the --revs-only flag to git rev-parse doesn't make
it output only revision IDs. It makes it output only arguments that
are suitable for giving to git rev-list. So make start_rev_list and
updatecommits cope with arguments output by git rev-parse that aren't
revision IDs. This way we won't get an error when an argument such as
"-300" has been given to gitk and the view is updated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This means that we don't have to keep clearing them out whenever we
change the row numbers for some commits.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When a fake row is added, we add its (fake) ID to the children list
for its (fake) parent. If renumbervarc were to then renumber the
parent it would incorrectly use the fake child. This avoids the
problem by adding a last_real_child procedure which won't return
a fake ID, and using it in renumbervarc. For symmetry this also adds
a first_real_child procedure and uses it in ordertoken.
Signed-off-by: Paul Mackerras <paulus@samba.org>
First, findmore would sometimes get a Tcl error due to relying on
varcorder and vrownum having valid values for the rows being searched,
but they may not be valid unless update_arcrows is called, so this
makes findmore call update_arcrows if necessary.
Secondly, in the "touching paths" and "adding/removing string" modes,
findmore was treating fhighlights($row) == -1 as meaning the row
matches, whereas it only means that we haven't received an answer from
the external git diff-tree process about it yet. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* Make sure targetrow is never >= numcommits
* Don't try to do anything about the target row if the targetid is
no longer in the view; it'll just cause Tcl errors
* In insertrow, increment targetrow if we are inserting the fake
commit at or before the target row
* In removerow, if we are removing the target row, make it the next
one instead.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Since commits come in out of order and get sorted as we see them,
we can have commits coming in and being placed before the commits
that are visible in the graph display pane. Previously we just
displayed a certain range of row numbers, meaning that when
incoming commits were placed before the displayed range, the
displayed commits were displaced downwards. This makes it so
that we keep the same set of commits displayed, unless the user
explicitly scrolls the pane, in which case it scrolls as expected.
We do this by having a "target" commit which we try to keep in the
same visible position. If commits have come in before it we scroll
the canvases by the number of rows that it has moved in the display
order.
This also fixes a bug in rowofcommit where it would test
cached_commitrow before possibly calling update_arcrows, which is
where cached_commitrow gets invalidated if things have changed.
Now we call update_arcrows if necessary first.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When updating the display, if the checked-out head has moved on and
isn't currently shown, and there are local changes, we could try to
insert a fake row with a parent that isn't displayed, leading to a
Tcl error. This is because we check whether the checked-out head
is displayed before rereading the references (which is when we discover
that the head has moved). This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* Fixed a bug that occasionally resulted in Tcl "can't use empty string
as argument to incr" errors - rowofcommit was sometimes not calling
update_arcrows when it needed to.
* Fixed a "no such element in array" error when removing a fake row,
by unsetting currentid and selectedline in removerow if the row we
are removing is the currently selected row.
* Made the "update commits" function always do "reread references".
* Made dodiffindex et al. remove the fake row(s) if necessary.
* Fixed a bug where clicking on a row in the graph display pane didn't
account for horizontal scrolling of the pane.
* Started changing things that cached information based on row numbers
to use commit IDs instead -- this converts the "select line" items
that are put into the history list to use "select by ID" instead.
* Simplified redrawtags a bit, and fixed a bug where it would use the
mainfont for working out how far it extends to the right in the graph
display pane rather than the actual font (which might be bold).
* Fixed a bug where "reread references" wouldn't notice if the currently
checked-out head had changed.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This restores date mode, which lists commits by date, as far as possible
given the constraint that parents come after all their children. To
implement this in the new framework, we (1) only join a new commit onto
an existing arc if the arc is the last arc created, (2) treat arcs as
seeds unless they have a child arc that comes later, and (3) never
decrease the token value for an arc.
This means we get lots of "seeds", which exposed some quadratic behaviour
in adding and removing seeds. To fix this, we add a vbackptr array, which
points to the arc whose vleftptr entry points to us, and a vlastins array,
which shows where in an arc's vdownptr/vleftptr list we last inserted a
parent, which acts as a hint of a good place to start looking for where to
insert a new child.
This also ensures the children array elements stay in sorted order at all
times. We weren't resorting the children lists when reassigning tokens
in renumbervarc. Since the children lists are now always sorted, we don't
have to search through all elements to find the one with the highest token;
we can just use the last element.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* Add/remove fake commits (for local changes) when updating the view
even if nothing else has changed.
* Get rid of unused getdbg variable.
* Get rid of vseeds and uat.
* Fix bug where removerow would throw a "no such element in array" error.
* Clear out cached highlights when line numbers change.
* Make dodiffindex remove the fake commit rows if they currently exist
but there are now no local changes.
Signed-off-by: Paul Mackerras <paulus@samba.org>
First, update_arcrows was being overly aggressive in trimming
displayorder, resulting in calls to rowofcommit sometimes trimming off
commits that layoutrows had asked for in make_disporder and was relying
on having present. This adds a vrowmod($view) variable that lets
update_arcrows be more precise in trimming off the invalid bits of
displayorder (and it also simplifies the check in make_disporder).
This modifies modify_arc and its callers so that vrowmod($view) is
updated appropriately.
Secondly, we were sometimes calling idcol with $i==-1, which resulted
in a call to ordertoken with the null string. This fixes it by
forcing $i to 0 if it is less than zero.
This also fixes a possible infinite recursion with rowofcommit and
update_arcrows calling each other ad infinitum.
Signed-off-by: Paul Mackerras <paulus@samba.org>
First, if we invalidate the layout for all rows (i.e. from row 0 on),
we were calling undolayout with an empty string as the argument.
Second, the comparison in make_disporder that tests if we need to
call update_arcrows was the wrong way around.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Instead of computing ordertok values and arc row numbers in
getcommitlines, this defers computing them until they are needed.
So getcommitlines no longer calls update_arcrows; instead it gets
called from rowofcommit and make_disporder. Things that modify arcs
now call modify_arc instead of setting vtokmod/varcmod directly,
and modify_arc does the undolayout that used to be in update_arcrows.
Also, idcol and make_idlist now use a new ordertoken function instead
of the ordertok variable. ordertoken uses ordertok as a cache, but
can itself compute the ordering tokens from scratch. This means that
the ordering tokens (and hence the layout of the graph) is once again
determined by the topological ordering we put on the graph, not on the
order in which we see the commits from git log, which improves the
appearance of the graph.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If the user specified multiple revisions arguments on the command
line or for a view, we were passing the whole list of arguments to
git rev-parse as a single argument, and thus git rev-parse didn't
interpret it as revisions. This fixes it by adding an eval so the
arguments get passed to git rev-parse as separate arguments.
Signed-off-by: Paul Mackerras <paulus@samba.org>
We weren't setting vtokmod and varcmod in renumbervarc, so after a
call to renumbervarc we sometimes weren't reassigning row numbers to
all the arcs whose row numbers had changed. This fixes it.
This also collapses layoutmore and showstuff into one procedure and
gets rid of the phase variable.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This very large patch implements code to organize the commits from
git log into "arcs" (sequences of commits where each pair of adjacent
commits are the only parent and child of each other), and orders the
arcs so as to get a topological ordering of the commits. This means
we can use git log without --topo-order and display the commits as we
get them, incrementally, which makes the cold-cache start up time much
faster, particularly on unpacked repos.
One beneficial effect of this is that the File->Update menu item now
just adds any new commits to the existing graph instead of rereading
the whole thing from scratch, which is much faster. (If you do want
to reread the whole graph from scratch you can use File->Reload.)
At an implementation level, this means that the displayorder and
parentlist lists are no longer fully valid at all times, and the
commitrow array has gone. New procedures commitinview and commitonrow
replace the commitrow array, and make_disporder ensures that
displayorder and parentlist are valid for a range of rows.
The overall time to load the kernel repository has gone up a bit, from
~9 seconds to ~11 seconds on my G5, but I think that is worth it given
that the time to get a window up with commits displayed in it has gone
from ~3 seconds to under 1 second.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 10:33:01 +11:00
513 changed files with 19034 additions and 5566 deletions
@ -102,4 +102,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the linkgit:git[7] suite
Part of the linkgit:git[1] suite
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.