Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Dec 26, 2009
  1. @gitster

    Merge branch 'jc/1.7.0-push-safety'

    gitster authored
    * jc/1.7.0-push-safety:
      Refuse deleting the current branch via push
      Refuse updating the current branch in a non-bare repository via push
Commits on Nov 21, 2009
  1. @gitster

    Merge branch 'sp/smart-http'

    gitster authored
    * sp/smart-http: (37 commits)
      http-backend: Let gcc check the format of more printf-type functions.
      http-backend: Fix access beyond end of string.
      http-backend: Fix bad treatment of uintmax_t in Content-Length
      t5551-http-fetch: Work around broken Accept header in libcurl
      t5551-http-fetch: Work around some libcurl versions
      http-backend: Protect GIT_PROJECT_ROOT from /../ requests
      Git-aware CGI to provide dumb HTTP transport
      http-backend: Test configuration options
      http-backend: Use http.getanyfile to disable dumb HTTP serving
      test smart http fetch and push
      http tests: use /dumb/ URL prefix
      set httpd port before sourcing lib-httpd
      t5540-http-push: remove redundant fetches
      Smart HTTP fetch: gzip requests
      Smart fetch over HTTP: client side
      Smart push over HTTP: client side
      Discover refs via smart HTTP server when available
      http-backend: more explict LocationMatch
      http-backend: add example for gitweb on same URL
      http-backend: use mod_alias instead of mod_rewrite
      ...
    
    Conflicts:
    	.gitignore
    	remote-curl.c
Commits on Nov 16, 2009
  1. @gitster

    Merge branch 'fc/doc-fast-forward'

    gitster authored
    * fc/doc-fast-forward:
      Use 'fast-forward' all over the place
    
    Conflicts:
    	builtin-merge.c
Commits on Nov 5, 2009
  1. @spearce @gitster

    Add stateless RPC options to upload-pack, receive-pack

    spearce authored gitster committed
    When --stateless-rpc is passed as a command line parameter to
    upload-pack or receive-pack the programs now assume they may
    perform only a single read-write cycle with stdin and stdout.
    This fits with the HTTP POST request processing model where a
    program may read the request, write a response, and must exit.
    
    When --advertise-refs is passed as a command line parameter only
    the initial ref advertisement is output, and the program exits
    immediately.  This fits with the HTTP GET request model, where
    no request content is received but a response must be produced.
    
    HTTP headers and/or environment are not processed here, but
    instead are assumed to be handled by the program invoking
    either service backend.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 25, 2009
  1. @felipec @gitster

    Use 'fast-forward' all over the place

    felipec authored gitster committed
    It's a compound word.
    
    Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 21, 2009
  1. @gitster

    receive-pack: run "gc --auto --quiet" and optionally "update-server-i…

    gitster authored
    …nfo"
    
    Introduce two new configuration variables, receive.autogc (defaults to
    true) and receive.updateserverinfo (defaults to false).  When these are
    set, receive-pack runs "gc --auto --quiet" and "update-server-info"
    respectively after it finishes receiving data from "git push" and updating
    refs.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Acked-by: Nicolas Pitre <nico@fluxnic.net>
Commits on Jul 29, 2009
  1. @gitster

    Refuse deleting the current branch via push

    gitster authored
    This makes git-push refuse deleting the current branch by default.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    Refuse updating the current branch in a non-bare repository via push

    gitster authored
    This makes git-push refuse pushing into a non-bare repository to update
    the current branch by default.  To help people who are used to be able to
    do this (and later "reset --hard" it in some other way), an error message
    is issued when this refusal is triggered, instructing how to resurrect the
    old behaviour.
    
    Hosting sites that do not give the users direct access to customize their
    repositories (e.g. repo.or.cz, gitorious, github etc.) may further want to
    explicitly set the configuration variable to "refuse" for their customers'
    repositories.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jul 6, 2009
  1. @gitster

    receive-pack: remove unnecessary run_status report

    Johannes Sixt authored gitster committed
    The function run_status was used to report failures after a hook was run.
    By now, the only thing that the function itself reported was the exit code
    of the hook (if it was non-zero). But this is redundant because it can be
    expected that the hook itself will have reported a suitable error.
    
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    run_command: report failure to execute the program, but optionally don't

    Johannes Sixt authored gitster committed
    In the case where a program was not found, it was still the task of the
    caller to report an error to the user. Usually, this is an interesting case
    but only few callers actually reported a specific error (though many call
    sites report a generic error message regardless of the cause).
    
    With this change the error is reported by run_command, but since there is
    one call site in git.c that does not want that, an option is added to
    struct child_process, which is used to turn the error off.
    
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @gitster

    run_command: report system call errors instead of returning error codes

    Johannes Sixt authored gitster committed
    The motivation for this change is that system call failures are serious
    errors that should be reported to the user, but only few callers took the
    burden to decode the error codes that the functions returned into error
    messages.
    
    If at all, then only an unspecific error message was given. A prominent
    example is this:
    
       $ git upload-pack . | :
       fatal: unable to run 'git-upload-pack'
    
    In this example, git-upload-pack, the external command invoked through the
    git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
    report the real cause. In fact, this very error message is copied to the
    syslog if git-daemon's client aborts the connection early.
    
    With this change, system call failures are reported immediately after the
    failure and only a generic failure code is returned to the caller. In the
    above example the error is now to the point:
    
       $ git upload-pack . | :
       error: git-upload-pack died of signal
    
    Note that there is no error report if the invoked program terminated with
    a non-zero exit code, because it is reasonable to expect that the invoked
    program has already reported an error. (But many run_command call sites
    nevertheless write a generic error message.)
    
    There was one special return code that was used to identify the case where
    run_command failed because the requested program could not be exec'd. This
    special case is now treated like a system call failure with errno set to
    ENOENT. No error is reported in this case, because the call site in git.c
    expects this as a normal result. Therefore, the callers that carefully
    decoded the return value still check for this condition.
    
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jul 5, 2009
  1. @gitster

    run_command: return exit code as positive value

    Johannes Sixt authored gitster committed
    As a general guideline, functions in git's code return zero to indicate
    success and negative values to indicate failure. The run_command family of
    functions followed this guideline. But there are actually two different
    kinds of failure:
    
    - failures of system calls;
    
    - non-zero exit code of the program that was run.
    
    Usually, a non-zero exit code of the program is a failure and means a
    failure to the caller. Except that sometimes it does not. For example, the
    exit code of merge programs (e.g. external merge drivers) conveys
    information about how the merge failed, and not all exit calls are
    actually failures.
    
    Furthermore, the return value of run_command is sometimes used as exit
    code by the caller.
    
    This change arranges that the exit code of the program is returned as a
    positive value, which can now be regarded as the "result" of the function.
    System call failures continue to be reported as negative values.
    
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 22, 2009
  1. @gitster

    receive-pack: do not send error details to the client

    Johannes Sixt authored gitster committed
    If the objects that a client pushes to the server cannot be processed for
    any reason, an error is reported back to the client via the git protocol.
    We used to send quite detailed information if a system call failed if
    unpack-objects is run. This can be regarded as an information leak. Now we
    do not send any error details like we already do in the case where
    index-pack failed.
    
    Errors in system calls as well as the exit code of unpack-objects and
    index-pack are now reported to stderr; in the case of a local push or via
    ssh these messages still go to the client, but that is OK since these forms
    of access to the server assume that the client can be trusted. If
    receive-pack is run from git-daemon, then the daemon should put the error
    messages into the syslog.
    
    With this reasoning a new status report is added for the post-update-hook;
    untrusted (i.e. daemon's) clients cannot observe its status anyway, others
    may want to know failure details.
    
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 9, 2009
  1. @gitster

    Simplify some instances of run_command() by using run_command_v_opt().

    Johannes Sixt authored gitster committed
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on May 18, 2009
  1. @gitster

    Merge branch 'np/push-delta'

    gitster authored
    * np/push-delta:
      allow OFS_DELTA objects during a push
Commits on May 2, 2009
  1. @gitster

    allow OFS_DELTA objects during a push

    Nicolas Pitre authored gitster committed
    The fetching of OFS_DELTA objects has been negotiated between both peers
    since git version 1.4.4.  However, this was missing from the push side
    where every OFS_DELTA objects were always converted to REF_DELTA objects
    causing an increase in transferred data.
    
    To fix this, both the client and the server processes have to be
    modified: the former to invoke pack-objects with --delta-base-offset
    when the server provides the ofs-delta capability, and the later to send
    that capability when OFS_DELTA objects are allowed as already indicated
    by the repack.usedeltabaseoffset config variable which is TRUE by
    default since git v1.6.0.
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Apr 30, 2009
  1. @raalkml @gitster

    replace direct calls to unlink(2) with unlink_or_warn

    raalkml authored gitster committed
    This helps to notice when something's going wrong, especially on
    systems which lock open files.
    
    I used the following criteria when selecting the code for replacement:
    - it was already printing a warning for the unlink failures
    - it is in a function which already printing something or is
      called from such a function
    - it is in a static function, returning void and the function is only
      called from a builtin main function (cmd_)
    - it is in a function which handles emergency exit (signal handlers)
    - it is in a function which is obvously cleaning up the lockfiles
    
    Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 5, 2009
  1. @peff @gitster

    improve missing repository error message

    peff authored gitster committed
    Certain remote commands, when asked to do something in a
    particular directory that was not actually a git repository,
    would say "unable to chdir or not a git archive". The
    "chdir" bit is an unnecessary detail, and the term "git
    archive" is much less common these days than "git repository".
    
    So let's switch them all to:
    
      fatal: '%s' does not appear to be a git repository
    
    Signed-off-by: Jeff King <peff@peff.net>
    Acked-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 15, 2009
  1. @gitster

    builtin-receive-pack.c: fix compiler warnings about format string

    René Scharfe authored gitster committed
    While all of the strings passed to warning() are, in fact, literals, the
    compiler doesn't recognize them as such because it doesn't see through
    the loop used to iterate over them:
    
       builtin-receive-pack.c: In function 'warn_unconfigured_deny':
       builtin-receive-pack.c:247: warning: format not a string literal and no format arguments
       builtin-receive-pack.c: In function 'warn_unconfigured_deny_delete_current':
       builtin-receive-pack.c:273: warning: format not a string literal and no format arguments
    
    Calm the compiler by adding easily recognizable format string literals.
    
    Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 11, 2009
  1. @gitster

    builtin-receive-pack.c: do not initialize statics to 0

    gitster authored
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    receive-pack: receive.denyDeleteCurrent

    gitster authored
    This is a companion patch to the recent 3d95d92 (receive-pack: explain
    what to do when push updates the current branch, 2009-01-31).
    
    Deleting the current branch from a remote will result in the next clone
    from it not check out anything, among other things.  It also is one of the
    cause that makes remotes/origin/HEAD a dangling symbolic ref.  This patch
    still allows the traditional behaviour but with a big warning, and promises
    that the default will change to 'refuse' in a future release.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 6, 2009
  1. @gitster

    Merge branch 'jc/refuse-push-to-current'

    gitster authored
    * jc/refuse-push-to-current:
      receive-pack: explain what to do when push updates the current branch
Commits on Feb 4, 2009
  1. @aspotashev @gitster

    Replace deprecated dashed git commands in usage

    aspotashev authored gitster committed
    Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 3, 2009
  1. @gitster

    receive-pack: explain what to do when push updates the current branch

    gitster authored
    This makes "git push" issue a more detailed instruction when a user pushes
    into the current branch of a non-bare repository without having an
    explicit configuration set to receive.denycurrentbranch.  In such a case,
    it will also tell the user that the default will change to refusal in a
    future version of git.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 18, 2009
  1. @sbeyer @gitster

    Move run_hook() from builtin-commit.c into run-command.c (libgit)

    sbeyer authored gitster committed
    A function that runs a hook is used in several Git commands.
    builtin-commit.c has the one that is most general for cases without
    piping. The one in builtin-gc.c prints some useful warnings.
    This patch moves a merged version of these variants into libgit and
    lets the other builtins use this libified run_hook().
    
    The run_hook() function used in receive-pack.c feeds the standard
    input of the pre-receive or post-receive hooks. This function is
    renamed to run_receive_hook() because the libified run_hook() cannot
    handle this.
    
    Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
    Mentored-by: Christian Couder <chriscool@tuxfamily.org>
    Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 9, 2008
  1. @peff @gitster

    receive-pack: detect push to current branch of non-bare repo

    peff authored gitster committed
    Pushing into the currently checked out branch of a non-bare
    repository can be dangerous; the HEAD then loses sync with
    the index and working tree, and it looks in the receiving
    repo as if the pushed changes have been reverted in the
    index (since they were never there in the first place).
    
    This patch adds a safety valve that checks for this
    condition and either generates a warning or denies the
    update. We trigger the check only on a non-bare repository,
    since a bare repo does not have a working tree (and in fact,
    pushing to the HEAD branch is a common workflow for
    publishing repositories).
    
    The behavior is configurable via receive.denyCurrentBranch,
    defaulting to "warn" so as not to break existing setups
    (though it may, after a deprecation period, switch to
    "refuse" by default). For users who know what they are doing
    and want to silence the warning (e.g., because they have a
    post-receive hook that reconciles the HEAD and working
    tree), they can turn off the warning by setting it to false
    or "ignore".
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 5, 2008
  1. @gitster

    Merge branch 'mv/maint-branch-m-symref'

    gitster authored
    * mv/maint-branch-m-symref:
      update-ref --no-deref -d: handle the case when the pointed ref is packed
      git branch -m: forbid renaming of a symref
      Fix git update-ref --no-deref -d.
      rename_ref(): handle the case when the reflog of a ref does not exist
      Fix git branch -m for symrefs.
Commits on Nov 2, 2008
  1. @jast @gitster

    Introduce receive.denyDeletes

    jast authored gitster committed
    Occasionally, it may be useful to prevent branches from getting deleted from
    a centralized repository, particularly when no administrative access to the
    server is available to undo it via reflog. It also makes
    receive.denyNonFastForwards more useful if it is used for access control
    since it prevents force-updating by deleting and re-creating a ref.
    
    Signed-off-by: Jan Krüger <jk@jk.gs>
    Acked-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 26, 2008
  1. @gitster

    receive-pack: fix "borrowing from alternate object store" implementation

    gitster authored
    In the alternate_object_database structure, ent->base[] is a buffer the
    users can use to form pathnames to loose objects, and ent->name is a
    pointer into that buffer (it points at one beyond ".git/objects/").  If
    you get a call to add_refs_from_alternate() after somebody used the entry
    (has_loose_object() has been called, for example), *ent->name would not be
    NUL, and ent->base[] won't be the path to the object store.
    
    This caller is expecting to read the path to the object store in ent->base[];
    it needs to NUL terminate the buffer if it wants to.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 9, 2008
  1. @gitster

    push: receiver end advertises refs from alternate repositories

    gitster authored
    Earlier, when pushing into a repository that borrows from alternate object
    stores, we followed the longstanding design decision not to trust refs in
    the alternate repository that houses the object store we are borrowing
    from.  If your public repository is borrowing from Linus's public
    repository, you pushed into it long time ago, and now when you try to push
    your updated history that is in sync with more recent history from Linus,
    you will end up sending not just your own development, but also the
    changes you acquired through Linus's tree, even though the objects needed
    for the latter already exists at the receiving end.  This is because the
    receiving end does not advertise that the objects only reachable from the
    borrowed repository (i.e. Linus's) are already available there.
    
    This solves the issue by making the receiving end advertise refs from
    borrowed repositories.  They are not sent with their true names but with a
    phoney name ".have" to make sure that the old senders will safely ignore
    them (otherwise, the old senders will misbehave, trying to push matching
    refs, and mirror push that deletes refs that only exist at the receiving
    end).
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    receive-pack: make it a builtin

    gitster authored
    It is a good thing to do in general, but more importantly, transport
    routines can only be used by built-ins, which is what I'll be adding next.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.