In some applications of the update hook a user may be allowed to
modify a branch, but only if the file level difference is also an
allowed change. This is the commonly requested feature of allowing
users to modify only certain files.
A new repository.*.allow syntax permits granting the three basic
file level operations:
A: file is added relative to the other tree
M: file exists in both trees, but its SHA-1 or mode differs
D: file is removed relative to the other tree
on a per-branch and path-name basis. The user must also have a
branch level allow line already granting them access to create,
rewind or update (CRU) that branch before the hook will consult
any file level rules.
In order for a branch change to succeed _all_ files that differ
relative to some base (by default the old value of this branch,
but it can also be any valid tree-ish) must be allowed by file
level allow rules. A push is rejected if any diff exists that
is not covered by at least one allow rule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some applications of this paranoid update hook the set of ACL
rules that need to be applied to a user can be large, and the
number of users that those rules must also be applied to can be
more than a handful of individuals. Rather than repeating the same
rules multiple times (once for each user) we now allow users to be
members of groups, where the group supplies the list of ACL rules.
For various reasons we don't depend on the underlying OS groups
and instead perform our own group handling.
Users can be made a member of one or more groups by setting the
user.memberOf property within the "users/$who.acl" file:
[user]
memberOf = developer
memberOf = administrator
This will cause the hook to also parse the "groups/$groupname.acl"
file for each value of user.memberOf, and merge any allow rules
that match the current repository with the user's own private rules
(if they had any).
Since some rules are basically the same but may have a component
differ based on the individual user, any user.* key may be inserted
into a rule using the "${user.foo}" syntax. The allow rule does
not match if the user does not define one (and exactly one) value
for the key "foo".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-cvsserver used checkout-index internally for commit and annotate.
Since a work tree is required for this to function now, this was
breaking. Work around this by defining GIT_WORK_TREE=. in the
appropriate places.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Parse the files section in the "p4 change -o" output and remove lines with file changes in unrelated depot paths.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The basic idea was proposed by Steve Hoelzer; in order to make
the list easier to search, we keep the command list in the
script that generates it with "sort -d".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Detect symlinks as file type, set the git file mode accordingly and strip off the trailing newline in the p4 print output.
Make the mode handling a bit more readable at the same time.
Signed-off-by: Simon Hausmann <simon@lst.de>
Acked-by: Brian Swetland <swetland@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.
I removed the _rfc822 suffix from the function name as it now does more
than rfc822 quoting.
I dug through rfc822 to do the double quoting right. Only if that is not
possible rfc2047 quoting is applied.
Signed-off-by: Uwe Kleine-K,Av(Bnig <ukleinek@informatik.uni-freiburg.de>
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The basic idea is from Mark Levedahl. I do not use GZ=1 nor
quick-install-doc myself (there obviously is a chicken-and-egg
issue with quick-install-doc for me).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was very unfortunate that we added core.pager setting to the
configuration file; even when the underlying command does not care
if there is no git repository is involved (think "git diff --no-index"),
the user would now rightfully want the configuration setting to be
honored, which means we would need to read the configuration file before
we launch the pager.
This is a minimum change in the sense that it restores the old
behaviour of not even reading config in setup_git_directory(),
but have the core.pager honored when we know it matters.
Note that this does not cover "git -p --git-dir where command";
the -p option immediately trigger the pager settings before we
even see --git-dir to learn where the configuration file is, so
we will end up reading the configuration from the place where
we would _normally_ find the git repository.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am expects the variable $resume to be empty or unset, which might not
be the case if $resume is set in the user's environment. So initialize
it to an empty value on startup.
The problem was noticed by Pierre Habouzit and reported through
http://bugs.debian.org/435807
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These instructions tell you how to create a clone of a repository
created with git-svn, that can in turn be used with git-svn.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
apply: remove directory that becomes empty by renaming the last file away
setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
We attempt to remove directory that becomes empty after removal
of a file. We should do the same when we rename an existing
file away.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a working tree _file_ "foo", attempt to refer to a
branch "foo/bar" without -- to disambiguate, like this:
$ git log foo/bar
tried to make sure that foo/bar cannot be naming a working tree
file "foo/bar" (in which case we would say "which one do you
want? A rev or a working tree file? clarify with -- please").
We run lstat("foo/bar") to check that. If it does not succeed,
there is no ambiguity.
That is good. But we also checked the error status for the
lstat() and expected it to fail with ENOENT. In this particular
case, however, it fails with ENOTDIR. That should be treated as
"expected error" as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As with git-add, I think previous updates to the git-commit man page did
indeed help make it more user-friendly. But I think the banishment of
the word "index" from the description goes too far; reinstate its use,
to simplify some of the language slightly and smooth the transition to
other documentation.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://linux-nfs.org/~bfields/git:
documentation: use the word "index" in the git-add manual page
user-manual: mention git-gui
user-manual: mention git stash
user-manual: update for new default --track behavior
It was a neat trick to show that you could introduce the git-add manual
page without using the word "index", and it was certainly an improvement
over the previous man page (which started out "A simple wrapper for
git-update-index to add files to the index...").
But it's possible to use the standard terminology without sacrificing
user-friendliness. So, rewrite to use the word "index" when
appropriate.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The git gui project seems to be still in early stages, but at a point
where it's worth mentioning as an alternative way of creating commits.
One feature of interest is the ability to manipulate individual diff
hunks. However, people have found that feature not to be easily
discoverable from the user-interface. Pending some ui improvements, a
parenthetical hint here may help.
(Thanks to Steffen Prohask and Junio Hamano for suggesting the
language.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Update documentation to reflect the --track default.
That change seems to have happened in the 1.5.3 -rc's, so bump the "for
version x.y.z or newer" warning as well.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The script starts in a subdirectory of the source directory to
muck with a branch whose structure does not have anything to
do with the actual work tree. Go up to the top to make it clear
that we operate on the whole tree.
It also exported GIT_DIR without any good reason. Remove it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sven originally raised this issue:
If you have a submodule checked out and you go back (or
forward) to a revision of the supermodule that contains a
different revision of the submodule and then switch to
another revision, it will complain that the submodule is not
uptodate, because git simply didn't update the submodule in
the first move.
The current policy is to consider it is perfectly normal that
checked-out submodule is out-of-sync wrt the supermodule index.
At least until we introduce a superproject repository
configuration option that says "in this repository, I do care
about this submodule and at any time I move around in the
superproject, recursively check out the submodule to match", it
is a reasonable policy, as we currently do not recursively
checkout the submodules at all. The most extreme case of this
policy is that the superproject index knows about the submodule
but the subdirectory does not even have to be checked out.
The function verify_uptodate(), called during the two-way merge
aka branch switching, is about "make sure the filesystem entity
that corresponds to this cache entry is up to date, lest we lose
the local modifications". As we explicitly allow submodule
checkout to drift from the supermodule index entry, the check
should say "Ok, for submodules, not matching is the norm" for
now.
Later when we have the ability to mark "I care about this
submodule to be always in sync with the superproject" (thereby
implementing automatic recursive checkout and perhaps diff,
among other things), we should check if the submodule in
question is marked as such and perform the current test.
Acked-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-push it is the remote repository and not the
local repository which is fast forwarded. The description
of the -f option in the git-push manpage gets it the other
way round.
Signed-off-by: Jyotirmoy Bhattacharya <jyotirmoy@jyotirmoy.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The GIT_SSH environment variable has survived for quite a while
without being documented, but has been mentioned on list and on
my day-job repositories can only be accessed via magic supplied
through the wonderous hack that is GIT_SSH.
Advertising it alongside other "low level magic" such as GIT_PAGER
and GIT_MERGE_VERBOSITY will certainly help others who need to
spread their own pixie dust to make things work.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit b6093a5c, by Robert Fitzsimons:
"gitweb: Change atom, rss actions to use parse_commits."
forgot to pass $file_name parameter to parse_commits subroutine.
If git_feed is provided a file name, it ought to show only the history
affecting that file or a directory. The title was being set
correctly, but all commits from history were being shown.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a new addition to 1.5.3; let's teach it to the
completion before the final release.
[sp: Added missing git-stash completion configuration]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
OS X sends Button-2 on a "real" right click, such as with a three
button mouse, or by using the two-finger trackpad click.
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The hashed contents did not matter in the end result, but it passed
an uninitialized variable to printf, which caused it to emit empty
while giving an error/usage message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If somebody used to advertise his repository that physically
resides at /pub/lic.git/ as:
git://git.example.com/pub/lic.git/
but now wants to use --base-path to allow:
git://git.example.com/lic.git/
she can start git-daemon with --base-path option, like this:
git-daemon --base-path=/pub --export-all
During the transition, however, she would also want to allow
older URL as well. One natural way to achieve that is to create
a symlink:
ln -s /pub /pub/pub
so that a request to git://git.example.com/pub/lic.git/ is first
translated by --base-path to a request to /pub/pub/lic.git/
which goes to /pub/lic.git, thanks to the symlink.
So far so good.
However, gitweb chokes if there is such a symlink (File::Find
barfs with "/pub/pub is a recursive symbolic link"). Make the
code ignore such a symlink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If there is no path currently shown in the diff viewer then we
were getting Tcl errors anytime the user right-clicked on the
diff viewer to bring up its popup menu. The bug here is caused
by trying to get the file_state for the empty string; this path
is never seen so we never have file_state for it. In such cases
we now disable the Stage Hunk For Commit option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In set_work_tree(), variable rel needs to be reinitialized to
NULL on every call (it should not be static).
Make sure the incoming dir variable is not too long before
copying to the temporary buffer, and make sure chdir to the
resulting directory succeeds.
This was spotted and fixed by Alex and Johannes in a handful
patch exchanges. Here is the final version.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
The current implementation of core.gitproxy only operates on
git:// URLs, so the ssh:// examples and custom protocol examples
have been removed or edited.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read-tree is already marked with RUN_SETUP in git.c, so there is
no need to call setup_git_directory() a second time.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
processing
P4 change outputs the changes sorted for each directory separately. We
want the global ordering on the changes, hence we sort.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
This changes the behaviour of cloning from a repository on the
local machine, by defaulting to "-l" (use hardlinks to share
files under .git/objects) and making "-l" a no-op. A new
option, --no-hardlinks, is also added to cause file-level copy
of files under .git/objects while still avoiding the normal
"pack to pipe, then receive and index pack" network transfer
overhead. The old behaviour of local cloning without -l nor -s
is availble by specifying the source repository with the newly
introduced file:///path/to/repo.git/ syntax (i.e. "same as
network" cloning).
* With --no-hardlinks (i.e. have all .git/objects/ copied via
cpio) would not catch the source repository corruption, and
also risks corrupted recipient repository if an
alpha-particle hits memory cell while indexing and resolving
deltas. As long as the recipient is created uncorrupted, you
have a good back-up.
* same-as-network is expensive, but it would catch the breakage
of the source repository. It still risks corrupted recipient
repository due to hardware failure. As long as the recipient
is created uncorrupted, you have a good back-up.
* The new default on the same filesystem, as long as the source
repository is healthy, it is very likely that the recipient
would be, too. Also it is very cheap. You do not get any
back-up benefit, though.
None of the method is resilient against the source repository
corruption, so let's discount that from the comparison. Then
the difference with and without --no-hardlinks matters primarily
if you value the back-up benefit or not. If you want to use the
cloned repository as a back-up, then it is cheaper to do a clone
with --no-hardlinks and two git-fsck (source before clone,
recipient after clone) than same-as-network clone, especially as
you are likely to do a git-fsck on the recipient if you are so
paranoid anyway.
Which leads me to believe that being able to use file:/// is
probably a good idea, if only for testability, but probably of
little practical value. We default to hardlinked clone for
everyday use, and paranoids can use --no-hardlinks as a way to
make a back-up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We might make it something like: "if you use an url, we don't default to
local", so the difference would be that
git clone file:///directory/to/repo
would work the way it does now, but
git clone /directory/to/repo
would default to "-l" behaviour. That kind of would make sense (and should
be easy to implement.
This adds support for "file://" URL to underlying connect
codepath to make it happen.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes "make doc" work even if you made "sudo make doc" previously
by mistake. Apparently an oversight: the other targets did this already.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
