summaryrefslogtreecommitdiff
path: root/builtin-receive-pack.c
AgeCommit message (Collapse)AuthorFilesLines
2009-07-06receive-pack: remove unnecessary run_status reportLibravatar Johannes Sixt1-16/+4
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>
2009-07-06run_command: report failure to execute the program, but optionally don'tLibravatar Johannes Sixt1-3/+1
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>
2009-07-06run_command: report system call errors instead of returning error codesLibravatar Johannes Sixt1-19/+3
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>
2009-07-05run_command: return exit code as positive valueLibravatar Johannes Sixt1-2/+2
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>
2009-06-21receive-pack: do not send error details to the clientLibravatar Johannes Sixt1-31/+22
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>
2009-06-09Simplify some instances of run_command() by using run_command_v_opt().Libravatar Johannes Sixt1-7/+3
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-18Merge branch 'np/push-delta'Libravatar Junio C Hamano1-7/+15
* np/push-delta: allow OFS_DELTA objects during a push
2009-05-01allow OFS_DELTA objects during a pushLibravatar Nicolas Pitre1-7/+15
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>
2009-04-29replace direct calls to unlink(2) with unlink_or_warnLibravatar Alex Riesen1-1/+1
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>
2009-03-04improve missing repository error messageLibravatar Jeff King1-1/+1
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>
2009-02-15builtin-receive-pack.c: fix compiler warnings about format stringLibravatar René Scharfe1-2/+2
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>
2009-02-10builtin-receive-pack.c: do not initialize statics to 0Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10receive-pack: receive.denyDeleteCurrentLibravatar Junio C Hamano1-11/+61
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>
2009-02-05Merge branch 'jc/refuse-push-to-current'Libravatar Junio C Hamano1-15/+43
* jc/refuse-push-to-current: receive-pack: explain what to do when push updates the current branch
2009-02-04Replace deprecated dashed git commands in usageLibravatar Alexander Potashev1-1/+1
Signed-off-by: Alexander Potashev <aspotashev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-03receive-pack: explain what to do when push updates the current branchLibravatar Junio C Hamano1-15/+43
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>
2009-01-17Move run_hook() from builtin-commit.c into run-command.c (libgit)Libravatar Stephan Beyer1-3/+3
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>
2008-11-09receive-pack: detect push to current branch of non-bare repoLibravatar Jeff King1-0/+59
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>
2008-11-05Merge branch 'mv/maint-branch-m-symref'Libravatar Junio C Hamano1-1/+1
* 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.
2008-11-02Introduce receive.denyDeletesLibravatar Jan Krüger1-0/+12
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>
2008-10-26receive-pack: fix "borrowing from alternate object store" implementationLibravatar Junio C Hamano1-2/+7
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>
2008-09-09push: receiver end advertises refs from alternate repositoriesLibravatar Junio C Hamano1-0/+38
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>
2008-09-09receive-pack: make it a builtinLibravatar Junio C Hamano1-0/+520
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>