Brought to you thanks to coccinelle:
---8<----
@@
expression *E;
@@
(
E ==
- 0
+ NULL
|
E !=
- 0
+ NULL
|
E =
- 0
+ NULL
)
@@
identifier f;
type T;
@@
T *f(...) {
<...
- return 0;
+ return NULL;
...>
}
--->8----
There are a lot more hits in compat/nedmallox and compat/regex but these
are borrowed code we rather do not want to maintain our own forks for,
and this patch refrains from touching them.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace remaining git-XXX calls with git XXX.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Acked-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hopefully makes the relationship between threading options of
format-patch and send-email easier to grasp.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also mention deprecated aliases that do not appear in the send-email
manpage.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "action" parameters for these two tests were supplied incorrectly for
the way the tests were implemented. The tests check whether a program
which calls hstrerror() or basename() successfully links when -lresolv or
-lgen are used, respectively. A successful linking would result in
NEEDS_RESOLV or NEEDS_LIBGEN being unset, and failure would result in
setting the respective variable.
Aside from that issue, the tests did not handle the case where neither
library was necessary for accessing the functions in question. So solve
both of these issues by re-working the two tests so that their form is like
the NEEDS_SOCKET test which attempts to link with just the c library, and
if it fails then assumes that the additional library is necessary and sets
the appropriate variable.
Also an entry in the config.mak.in file is necessary for the NEEDS_LIBGEN
variable to appear in the config.mak.autogen file with the value assigned
by the configure script. Without it, the generated shell script would
contain a snippet like this:
for ac_lib in ; do
...
which is incorrect.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Trailing whitespace and no newline fix
diff --cc: a lost line at the beginning of the file is shown incorrectly
combine-diff.c: fix performance problem when folding common deleted lines
If a patch adds a new line to the end of a file and this line ends with
one trailing whitespace character and has no newline, then
'--whitespace=fix' currently does not remove that trailing whitespace.
This patch fixes this by removing the check for trailing whitespace at
the end of the line at a hardcoded offset which does not take the
eventual absence of newline into account.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When combine-diff inspected the diff from one parent to the merge result,
it misinterpreted a header in the form @@ -l,k +0,0 @@.
This hunk header means that K lines were removed from the beginning of the
file, so the lost lines must be queued to the sline that represents the
first line of the merge result, but we incremented our pointer incorrectly
and ended up queuing it to the second line, which in turn made the lossage
appear _after_ the first line.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a deleted line in a patch with the parent we are looking at, the
append_lost() function finds the same line among a run of lines that were
deleted from the same location by patches from parents we previously
checked. This is so that patches with two parents
@@ -1,4 +1,3 @@ @@ -1,4 +1,3 @@
one one
-two -two
three three
-quatro -fyra
+four +four
can be coalesced into this sequence, reusing one line that describes the
removal of "two" for both parents.
@@@ -1,4 -1,4 +1,3 @@@
one
--two
three
- quatro
-frya
++four
While reading the second patch (that removes "two" and then "fyra"), after
finding where removal of the "two" matches, we need to find existing
removal of "fyra" (if exists) in the removal list, but the match has to
happen after all the existing matches (in this case "two"). The code used
a naïve O(n^2) algorithm to compute this by scanning the whole removal
list over and over again.
This patch remembers where the next scan should be started in the existing
removal list to avoid this.
Noticed by Linus Torvalds.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a rebase with --onto, the correct test for whether we can skip
rewriting a commit is if it is already on top of $ONTO, not $UPSTREAM.
Without --onto, this distinction does not exist and the behavior does
not change.
In a situation with two merged branches on a common base X:
X---o---o---o---M
\ /
x---x---x---x
Y
if we try to move the branches from their base on X to be based on Y,
so as to get
X
Y---o'--o'--o'--M'
\ /
x'--x'--x'--x'
then we fail. The command `git rebase -p --onto Y X M` moves only the
first-parent chain, like so:
X
\
x---x---x---x
\
Y---o'--o'--o'--M'
because it mistakenly drops the other branch(es) x---x---x---x from
the TODO file. This tests and fixes this behavior.
Signed-off-by: Greg Price <price@ksplice.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mishandling of http(s) in need of escaping was causing
t9118-git-svn-funky-branch-names to fail when SVN_HTTPD_PORT
was defined.
This bug was exposed in (but not caused by)
commit 0b2af457a4
(Fix branch detection when repository root is inaccessible)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Some unrelated tests were developed simultaneously and resulted
in test numbers conflicting. To avoid difficulty when referring
to tests via the "tXXXX" convention, rename the newer tests.
Suggested by Marc Branchaud.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If the message said "we will be changing the default in the future, so
this is to warn people who want to keep the current default what to do",
it would have made some sense, but as it stands, the message is merely an
unsolicited advertisement for a new feature, which it is not helpful at
all. Squelch it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --no-walk' sorts commits by commit time whereas 'git show' does
not (it leaves them as given on the command line). Document this by two
tests so that we never forget why ba1d450 (Tentative built-in "git
show", 2006-04-15) introduced it and 8e64006 (Teach revision machinery
about --no-walk, 2007-07-24) exposed it as an option argument.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder tests introduced in fef3a7cc and 54d5cc0e so an intermittent but
unimportant failure on the CVS side related to the former does not interfere
with what is actually being tested.
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Tested-by: Tommy Nordgren <tommy.nordgren@comhem.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we switch branches with "checkout -f", unpack_trees() feeds two
cache_entries to oneway_merge() function in its src[] array argument. The
zeroth entry comes from the current index, and the first entry represents
what the merge result should be, taken from the tree recorded in the
commit we are switching to.
When we have a blob (either regular file or a symlink) in the index and in
the work tree at path "foo", and the switched-to tree has "foo/bar",
i.e. "foo" becomes a directory, src[0] is obviously that blob currently
registered at "foo". Even though we do not have anything at "foo" in the
switched-to tree, src[1] is _not_ NULL in this case.
The unpack_trees() machinery places a special marker df_conflict_entry
to signal that no blob exists at "foo", but it will become a directory
that may have somthing underneath it (namely "foo/bar"), so a usual 3-way
merge can notice the situation.
But oneway_merge() codepath failed to notice this and passed the special
marker directly to merged_entry(). This happens to remove the "foo" in
the end because the df_conflict_entry does not have any name (hence the
"error" message) and its addition in add_index_entry() is rejected, but it
is wrong.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
When we fall back to a standard for_each_reflog_ent() after failing to find
the nth branch switch (or if we had a short reflog) with the call to
for_each_recent_reflog_ent(), we do not need to free the memory allocated
for our strbuf's since a strbuf_reset() will be performed in
grab_nth_branch_switch() before assigning to the entry.
Plus, the strbuf_release() negates the non-zero hint we initially gave to
strbuf_init() just above these lines.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 650d30d8a1.
Some mailing lists are configured add prefix "[listname] " to all their
messages, and also people hand-edit subject lines, be it an output from
format-patch or a patch generated by some other means.
We cannot stop people from mucking with the subject line, and with the
change, there always will be need for hand editing the subject when that
happens. People have depended on the leading [bracketed string] removal.
In our 'oneway_merge()' we always do an 'lstat()' to see if we might
need to mark the entry for updating.
But we really shouldn't need to do that when the cache entry is already
marked as being ce_uptodate(), and this makes us do unnecessary lstat()
calls if we have index preloading enabled.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not that anybody should ever get it, but somebody did (probably because
of a flaky filesystem, but whatever). And each time I see an error
message that I haven't seen before, I decide that next time it will look
better.
So this makes us write more relevant information about exactly which
file ended up having issues with a missing object. Which will tell
whether it was a tree object, for example, or just a regular file in the
index (and which one).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, I ended up doing
git show HEAD~5..
as an odd way of asking for a log. I realize I should just have used "git
log", but at the same time it does make perfect conceptual sense. After
all, you _could_ have done
git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4
and saying "git show HEAD~5.." is pretty natural. It's not like "git show"
only ever showed a single commit (or other object) before either! So
conceptually, giving a commit range is a very sensible operation, even
though you'd traditionally have used "git log" for that.
However, doing that currently results in an error
fatal: object ranges do not make sense when not walking revisions
which admittedly _also_ makes perfect sense - from an internal git
implementation standpoint in 'revision.c'.
However, I think that asking to show a range makes sense to a user, while
saying "object ranges no not make sense when not walking revisions" only
makes sense to a git developer.
So on the whole, of the two different "makes perfect sense" behaviors, I
think I originally picked the wrong one. And quite frankly, I don't really
see anybody actually _depending_ on that error case. So why not change it?
So rather than error out, just turn that non-walking error case into a
"silently turn on walking" instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... so it's available for git log, shortlog and gitk.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-scm.com is now the "official" Git project page, having taken over
from git.or.cz, so update the default link accordingly. This saves a
redirect when people hit git.or.cz.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SVN allows uppercase A-F characters in repositories. Although
`svnadmin' does not create UUIDs with uppercase by default, it
is possible to change the UUID of a SVN repository and SVN
itself will make no attempt to normalize them.
Thanks to Esben Skovenborg for discovering this issue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
For the case of multiple projects sharing a single SVN repository, it is
common practice to create the standard SVN directory layout within a
subdirectory for each project. In such setups, access control is often
used to limit what projects a given user may access. git-svn failed to
detect branches (e.g. when passing --stdlayout to clone) because it
relied on having access to the root directory in the repository. This
patch solves this problem by making git-svn use paths relative to the
given repository URL instead of the repository root.
Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
This makes get_log more safe to use because callers cannot run into path
clobbering any more. The additional overhead will not affect performance
since the critical calls from the fetch loop need the path duplication
anyway and the rest of the call sites is not performance critical.
Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
quickfetch() calls rev-list to check whether the objects we are about to
fetch are already present in the repo (if so, we can skip the object fetch).
However, when there are many (~1000) refs to be fetched, the rev-list
command line grows larger than the maximum command line size on some systems
(32K in Windows). This causes rev-list to fail, making quickfetch() return
non-zero, which unnecessarily triggers the transport machinery. This somehow
causes fetch to fail with an exit code.
By using the --stdin option to rev-list (and feeding the object list to its
standard input), we prevent the overflow of the rev-list command line,
which causes quickfetch(), and subsequently the overall fetch, to succeed.
However, using rev-list --stdin is not entirely straightforward: rev-list
terminates immediately when encountering an unknown object, which can
trigger SIGPIPE if we are still writing object's to its standard input.
We therefore temporarily ignore SIGPIPE so that the fetch process is not
terminated.
The patch also contains a testcase to verify the fix (note that before
the patch, the testcase would only fail on msysGit).
Signed-off-by: Johan Herland <johan@herland.net>
Improved-by: Johannes Sixt <j6t@kdbg.org>
Improved-by: Alex Riesen <raa.lkml@gmail.com>
Tested-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 003b33a8 recently added a call to basename(). On IRIX 6.5, this
function resides in libgen and -lgen is required for the linker.
Update configure.ac too.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't define _XOPEN_SOURCE
Do define _SGI_SOURCE
Defining _XOPEN_SOURCE prevents many of the common functions and macros
from being defined. _Not_ setting _XOPEN_SOURCE, and instead setting
_SGI_SOURCE, provides all of the XPG4, XPG5, BSD, POSIX functions and
declarations, _BUT_ provides a horribly broken snprintf(). SGI does have
a working snprintf(), but it is only provided when _NO_XOPEN5 evaluates
to zero, and this only happens if _XOPEN_SOURCE is defined which, as
mentioned above, prevents many other common functions and defines.
The broken snprintf will be worked around with SNPRINTF_RETURNS_BOGUS in
the Makefile in a later patch.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The c99 MIPSpro Compiler version 7.4.4m on IRIX 6.5 does not properly
initialize run-time initialized arrays. An array which is initialized with
fewer elements than the length of the array should have the unitialized
elements initialized to zero. This compiler only initializes the remaining
elements when the last element is a static parameter. So work around it
by adding a "NULL" initialization parameter.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lt/dir-cleanup:
Make index preloading check the whole path to the file
Export thread-safe version of 'has_symlink_leading_path()'
Prepare symlink caching for thread-safety
Avoid using 'lstat()' to figure out directories
Avoid doing extra 'lstat()'s for d_type if we have an up-to-date cache entry
Simplify read_directory[_recursive]() arguments
Add 'fill_directory()' helper function for directory traversal
For some reason there still are people who use the old style layout
to put everything in $(bindir). The previous commit breaks the install
for them, because it tries to unconditionally remove git from execdir
and cp/ln from bindir --- oops.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses the new thread-safe 'threaded_has_symlink_leading_path()'
function to efficiently verify that the whole path leading up to the
filename is a proper path, and does not contain symlinks.
This makes 'ce_uptodate()' a much stronger guarantee: it no longer just
guarantees that the 'lstat()' of the path would match, it also means
that we know that people haven't played games with moving directories
around and covered it up with symlinks.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The threaded index preloading will want it, so that it can avoid
locking by simply using a per-thread symlink/directory cache.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This doesn't actually change the external interfaces, so they are still
thread-unsafe, but it makes the code internally pass a pointer to a
local 'struct cache_def' around, so that the core code can be made
thread-safe.
The threaded index preloading will want to verify that the paths leading
up to a pathname are all real directories.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we have an up-to-date index entry for a file in that directory, we
can know that the directories leading up to that file must be
directories. No need to do an lstat() on the directory.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a git command executes a subcommand, it uses the "git
foo" form, which relies on finding "git" in the PATH.
Normally this should not be a problem, since the same "git"
that was used to invoke git in the first place will be
found. And if somebody invokes a "git" outside of the PATH
(e.g., by giving its absolute path), this case is already
covered: we put that absolute path onto the front of PATH.
However, if one is using "sudo", then sudo will execute the
"git" from the PATH, but pass along a restricted PATH that
may not contain the original "git" directory. In this case,
executing a subcommand will fail.
To solve this, we put the "git" wrapper itself into the
execdir; this directory is prepended to the PATH when git
starts, so the wrapper will always be found.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On filesystems without d_type, we can look at the cache entry first.
Doing an lstat() can be expensive.
Reported by Dmitry Potapov for Cygwin.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stop the insanity with separate 'path' and 'base' arguments that must
match. We don't need that crazy interface any more, since we cleaned up
handling of 'path' in commit da4b3e8c28.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the users of "read_directory()" actually want a much simpler
interface than the whole complex (but rather powerful) one.
In fact 'git add' had already largely abstracted out the core interface
issues into a private "fill_directory()" function that was largely
applicable almost as-is to a number of callers. Yes, 'git add' wants to
do some extra work of its own, specific to the add semantics, but we can
easily split that out, and use the core as a generic function.
This function does exactly that, and now that much simplified
'fill_directory()' function can be shared with a number of callers,
while also ensuring that the rather more complex calling conventions of
read_directory() are used by fewer call-sites.
This also makes the 'common_prefix()' helper function private to dir.c,
since all callers are now in that file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
