It does not matter if the only refs you push are directly
underneath heads and tags, but we forgot to make sure we have
leading directories so pushing tags/v0.99/1 would not have
worked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier one conflated update and post-update hooks for no
good reason. Correct that ugly hack. Now post-update hooks
will take the list of successfully updated refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
send-pack had a confusing misfeature that "send-pack --all
master" updated all refs, while "send-pack --all" did not do
anything. Make --all and explicit refs mutually exclusive, and
make sure "send-pack --all" updates all refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current shortlog list is backward making it look odd.
This reverses it so things appear more logically.
[jc: Nico says that this restores the short-log behaviour from
the BK days.]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Things have slowly but surely started to settle down, and the
http transport finally can natively grok packed repositories.
To give Pasky a good anchor point, hoping that he can start
split off the core part from Cogito, here is the 0.99.3, which
will be accompanied with its own tag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge-cache reporting failed merge program is undesirable for
Cogito, since it emits its own more appropriate error message in that
case. However, I want to show other possible git-merge-cache error
messages. So -q will just silence this particular error.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A few sparse warnings have crept in again since I checked last time:
undeclared variables with global scope.
Fix them by marking the private variables properly "static".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some implementations of wc pad the line number with white space, which
expr does not grok as a number.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a few typos.
Adapt to git-http-pull not borking on packed repositories.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Yes, push does not lock, but that does not mean it is not
meant for multi-user repository. It just ought to perform
correctly without using locks.
- Let's not pretend we know _the_ right way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds support to http-pull for finding the list of pack files
available on the server, downloading the index files for those pack
files, and downloading pack files when they contain needed objects not
available individually. It retains the index files even if the pack
files were not needed, but downloads the list of pack files once per
run if an object is not found separately.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds support for reading an uninstalled index, and installing a
pack file that was added while the program was running, as well as
functions for determining where to put the file.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just before updating a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha1
is called if executable. The hook can decline the ref to be
updated by exiting with a non-zero status, or allow it to be
updated by exiting with a zero status. The mechanism also
allows e.g sending of a mail with pushed commits on the remote
repository.
Documentation update with an example hook is included.
jc: The credits of the basic idea and initial implementation go
to Josef, but I ended up rewriting major parts of his patch, so
bugs are all mine. Also I changed the semantics for the hook
from his original version (which were post-update hook) so that
the hook can optionally decline to update the ref, and also can
be used to implement the overall cleanups. The latter was
primarily to implement a suggestion from Linus that calling
update-server-info should be made optional.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Old libcurl has curl_easy_setopt(), and http-pull requires it; it just
doesn't have one of the options.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
which is a list of "fake commit parent records". Each line of
this file is a commit ID, followed by parent commit IDs, all
40-byte hex SHA1 separated by a single SP in between. The
records override the parent information we would normally read
from the commit objects, allowing both adding "fake" parents
(i.e. grafting), and pretending as if a commit is not a child of
some of its real parents (i.e. cauterizing).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This counts the number of unpacked object files and disk space
consumed by them, to help you decide when it is a good time to
repack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Implement fetching from a packed repository over http/https
using the dumb server support files.
I consider some parts of the logic should be in a separate C
program, but it appears to work with my simple tests. I have
backburnered it for a bit too long for my liking, so let's throw
it out in the open and see what happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Specifically this should fix the following errors:
wrong # args: should be "startdiff ids" (fix from Junio Hamano)
can't read "filelines(....)": no such element in array
can't unset "treepending": no such variable
This patch implements Linus' idea that if you are not interested in
pulling by HTTP, you can now say
NO_CURL=1 make
to compile everything except git-http-pull (thus not needing curl at all).
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Sat, 30 Jul 2005, Linus Torvalds wrote:
>
> Yup, it's git-merge-base, and it is confused by the same thing that
> confused git-rev-list.
Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
somebody else can come up with a better one. I think this one ends up
being quite a bit more expensive than the old one (it will look up _all_
common parents that have a child that isn't common, and then select the
newest one of the bunch), but I haven't really thought it through very
much.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds a new "git bisect" command.
- "git bisect start"
start bisection search.
- "git bisect bad <rev>"
mark some version known-bad (if no arguments, then current HEAD)
- "git bisect good <revs>..."
mark some versions known-good (if no arguments, then current HEAD)
- "git bisect reset <branch>"
done with bisection search and go back to your work (if
no arguments, then "master").
The way you use it is:
git bisect start
git bisect bad # Current version is bad
git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
# tested that was good
When you give at least one bad and one good versions, it will
bisect the revision tree and say something like:
Bisecting: 675 revisions left to test after this
and check out the state in the middle. Now, compile that kernel, and boot
it. Now, let's say that this booted kernel works fine, then just do
git bisect good # this one is good
which will now say
Bisecting: 337 revisions left to test after this
and you continue along, compiling that one, testing it, and depending on
whether it is good or bad, you say "git bisect good" or "git bisect bad",
and ask for the next bisection.
Until you have no more left, and you'll have been left with the first bad
kernel rev in "refs/bisect/bad".
Oh, and then after you want to reset to the original head, do a
git bisect reset
to get back to the master branch, instead of being in one of the bisection
branches ("git bisect start" will do that for you too, actually: it will
reset the bisection state, and before it does that it checks that you're
not using some old bisection branch).
Not really any harder than doing series of "quilt push" and "quilt pop",
now is it?
[jc: This patch is a rework based on what Linus posted to the
list. The changes are:
- The original introduced four separate commands, which was
three too many, so I merged them into one with subcommands.
- Since the next thing you would want to do after telling it
"bad" and "good" is always to bisect, this version does it
automatically for you.
- I think the termination condition was wrong. The original
version checked if the set of revisions reachable from next
bisection but not rechable from any of the known good ones
is empty, but if the current bisection was a bad one, this
would not terminate, so I changed it to terminate it when
the set becomes a singleton or empty.
- Removed the use of shell array variable.
]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document new (and not-so-new) flags of git-rev-list.
Signed-off-By: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Separate the process of building the commands to compilation and
linkage. This makes it more consistent with the library objects, is the
traditional thing to do, and significantly speeds up the subsequent
rebuilds, especially for us the people who develop git on 300MHz
notebooks.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When built with NO_OPENSSL, rev-list --merge-order does not
work, causing t6001 test to fail. Detect that and skip this
test to allow continuing to the rest of the tests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Support for completely OpenSSL-less builds. FSF considers distributing GPL
binaries with OpenSSL linked in as a legal problem so this is trouble
e.g. for Debian, or some people might not want to install OpenSSL
anyway. If you
make NO_OPENSSL=1
you get completely OpenSSL-less build, disabling --merge-order and using
Mozilla's SHA1 implementation.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The Makefile rules were massively reordered so that they are actually
logically grouped now. Captions were added to separate the sections. No
rule contents was touched during the process.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove about one gazillion of explicit dependency rules with few lines
describing the general dependency pattern and then the exceptions. This
noticably shortens the Makefile and makes it easier to touch it.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Describe variables which make itself takes and adjusts compilation
accordingly (MOZILLA_SHA1, NO_OPENSSL, PPC_SHA1), and make adding
defines more convenient through the $DEFINES variable. $COPTS includes
-g as well now and is not overriden if it was already declared in the
environment. Also, $CFLAGS is appended to rather than reset, so that if
there was already a $CFLAGS environment variable, it's appended to. Some
more variables are also made overridable through the environment. Renamed
$bin to $bindir which is the name commonly used for this.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
All usage strings are now declared as static const char [].
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Simple whitespace-related tidyups ensuring style consistency.
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I have reviewed all occurrences of mmap() in git and fixed three types
of errors/defects:
1) The result is not checked.
2) The file descriptor is closed if mmap() succeeds, but not when it
fails.
3) Various casts applied to -1 are used instead of MAP_FAILED, which is
specifically defined to check mmap() return value.
[jc: This is a second round of Pavel's patch. He fixed up the problem
that close() potentially clobbering the errno from mmap, which
the first round had.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pasky and others raised many valid points on the problems
initial exclude pattern enhancement work had. Based on the
list discussion, rework the exclude logic to use "last match
determines its fate" rule, and order the list by exclude-from
(the fallback default pattern file), exclude-per-directory
(shallower to deeper, so deeper ones can override), and then
command line exclude patterns.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This corner-case was triggered by a kernel commit that was not in date
order, due to a misconfigured time zone that made the commit appear three
hours older than it was.
That caused git-rev-list to traverse the commit tree in a non-obvious
order, and made it parse several of the _parents_ of the misplaced commit
before it actually parsed the commit itself. That's fine, but it meant
that the grandparents of the commit didn't get marked uninteresting,
because they had been reached through an "interesting" branch.
The reason was that "mark_parents_uninteresting()" (which is supposed to
mark all existing parents as being uninteresting - duh) didn't actually
traverse more than one level down the parent chain.
NORMALLY this is fine, since with the date-based traversal order,
grandparents won't ever even have been looked at before their parents (so
traversing the chain down isn't needed, because the next time around when
we pick out the parent we'll mark _its_ parents uninteresting), but since
we'd gotten out of order, we'd already seen the parent and thus never got
around to mark the grandparents.
Anyway, the fix is simple. Just traverse parent chains recursively.
Normally the chain won't even exist (since the parent hasn't been parsed
yet), so this is not actually going to trigger except in this strange
corner-case.
Add a comment to the simple one-liner, since this was a bit subtle, and I
had to really think things through to understand how it could happen.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Darrin Thompson noticed when he was showing off GIT to others
that the use of filenames "a" and "b" in the tutorial example
was unnecessarily confusing, especially with our "patch -p1"
prefix a/ and b/, without giving us any patch. I was very
tempted to change them back to l/ and k/ prefixes, but decided
to restrain myself and update the tutorial instead ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some newer features of libcurl are used which are not strictly necessary
for http-pull. Use them only if libcurl is new enough to know about them.
[jc: I just reworked #ifdef sprinkled all over the code into a
single section that defines a set of macros.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we see if the result is quite similar to one of the parents, and
if it is, display the result as a diff from that parent. If the result
is similar to more than one parent, pick the one that it's most
similar to.
On older Mac OS X (10.2.8), no socklen_t is defined, and therefore
daemon.c does not compile. However, Mac OS X 10.4 seems to define
socklen_t differently.
Also, linking fails due to some symbols defined in libssl (not just
libcrypto).
[jc: I am tentatively dropping the socklen_t part of the patch
because I am waiting for confirmation on the server side IPV6
patch from Yoshifuji-san]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Test t6002 unnecessarily fails when bc is a bit older than average.
Signed-off-by: Johannes.Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-prune-script still contained that non-portable option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano