1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-16 22:14:53 +01:00
Commit graph

14 commits

Author SHA1 Message Date
Jeff King
05ac6b34e2 improve missing repository error message
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-03-04 20:37:21 -08:00
René Scharfe
88a667f063 builtin-receive-pack.c: fix compiler warnings about format string
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-15 11:14:12 -08:00
Junio C Hamano
1b53a076fc builtin-receive-pack.c: do not initialize statics to 0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10 22:27:14 -08:00
Junio C Hamano
747ca2455a receive-pack: receive.denyDeleteCurrent
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-10 22:26:49 -08:00
Junio C Hamano
5d680a67d7 Merge branch 'jc/refuse-push-to-current'
* jc/refuse-push-to-current:
  receive-pack: explain what to do when push updates the current branch
2009-02-05 19:40:36 -08:00
Alexander Potashev
34263de026 Replace deprecated dashed git commands in usage
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04 15:08:49 -08:00
Junio C Hamano
3d95d92b9a receive-pack: explain what to do when push updates the current branch
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-02-03 00:39:18 -08:00
Stephan Beyer
ae98a0089f Move run_hook() from builtin-commit.c into run-command.c (libgit)
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>
2009-01-17 17:16:24 -08:00
Jeff King
986e82396a receive-pack: detect push to current branch of non-bare repo
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-09 10:16:50 -08:00
Junio C Hamano
efcce2e1f0 Merge branch 'mv/maint-branch-m-symref'
* 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-05 11:33:19 -08:00
Jan Krüger
a240de1137 Introduce receive.denyDeletes
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-11-02 01:54:28 -07:00
Junio C Hamano
b8492539f9 receive-pack: fix "borrowing from alternate object store" implementation
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-10-26 14:05:55 -07:00
Junio C Hamano
d79796bcf0 push: receiver end advertises refs from alternate repositories
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-09 09:27:46 -07:00
Junio C Hamano
be5908aed3 receive-pack: make it a builtin
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>
2008-09-09 09:27:45 -07:00
Renamed from receive-pack.c (Browse further)