Thanks to Johannes Schindelin for review and fixes, and Julian
Phillips for the original C translation.
This changes a few small bits of behavior:
branch.<name>.merge is parsed as if it were the lhs of a fetch
refspec, and does not have to exactly match the actual lhs of a
refspec, so long as it is a valid abbreviation for the same ref.
branch.<name>.merge is no longer ignored if the remote is configured
with a branches/* file. Neither behavior is useful, because there can
only be one ref that gets fetched, but this is more consistant.
Also, fetch prints different information to standard out.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usage info is emebed in the script, but the gist of it is to run the script
from a pre-commit hook to save permissions/ownership data to a file and check
that file into the repository. Then, a post_merge hook reads the file and
updates working tree permissions/ownership. All updates are transparent to
the user (although there is a --verbose option). Merge conflicts are handled
in the "read" phase (in pre-commit), and the script aborts the commit and
tells you how to fix things in the case of a merge conflict in the metadata
file. This same idea could be extended to handle file ACLs or other file
metadata if desired.
Signed-off-by: Josh England <jjengla@sandia.gov>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is based on the git-import.sh script, but is a little
more robust and efficient. More importantly, it should
serve as a quick template for interfacing fast-import with
perl scripts.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This example just puts a directory under git control. It is
significantly slower than using the git tools directly, but
hopefully shows a bit how fast-import works.
[jk: added header comments]
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default behavior for each state can be customized, and it can also
be toggled directly from the status buffer.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes insertions and updates much more efficient.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces the script "git-reset.sh" with "builtin-reset.c".
A few git commands used in the script are called from the builtin also:
"ls-files" to check for unmerged files, "read-tree" for resetting
the index file in "mixed" and "hard" resets, and "update-index" to
refresh at the end in the "mixed" reset and also for the option that
gets selected paths into the index.
The reset option with paths was implemented by Johannes Schindelin.
Since the option that gets selected paths into the index is not
a "reset" like the others because it does not change the HEAD at all,
now the command is showing a warning when the "--mixed" option
is supplied for that purpose.
The following table shows the behaviour of "git reset" for
the different supported options, where X means "changing"
the HEAD, index or working tree:
reset: --soft --mixed --hard -- <paths>
HEAD X X X -
index - X X X
files - - X -
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recently I found that doing a sequence like the following:
git-new-workdir a b
...
git-new-workdir a b
by accident will cause a (and now also b) to have an infinite cycle
in its refs directory. This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.
This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo". Plenty of commands start
to see ambiguous ref names and others just take ages to compute.
git-clone has the same safety check, so git-new-workdir should
behave just like it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a change in a p4 "branch" appears that hasn't seen any previous commit and
that has a known branch mapping we now try to import it properly. First we
find the p4 change of the source branch that the new p4 branch is based on. Then
we using git rev-list --bisect to locate the corresponding git commit to that change.
Finally we import all changes in the new p4 branch up to the current change and resume
with the regular import.
Signed-off-by: Simon Hausmann <simon@lst.de>
Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`. In both such cases being able to complete the names
of existing tags saves the fingers some typing effort. We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.
When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.
If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Both --left-right and --cherry-pick are particularly long to type, so
help the user there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't create the p4/HEAD symbolic ref if p4/master doesn't exist yet.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After a clone with "git clone" of a repository the p4 branches are only in remotes/origin/p4/* and not in remotes/p4/*.
Separate the code for detection and creation out of the P4Sync command class into standalone methods and use them
from the P4Branches command.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-submodule command is new in 1.5.3 and contains a number
of useful subcommands for working on submodules. We usually try
to offer the subcommands of a git command in the bash completion,
so here they are for git-submodule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm often finding that I need to run git-describe on very long
remote tracking branch names, to find out what tagged revision
the remote tracking branch is now at (or not at). Typing out
the ref names is painful, so bash completion on them is a very
useful feature.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A number of commands have learned new tricks as part of git 1.5.3.
If these are long options (--foo) we tend to support them in the
bash completion, as it makes the user's task of using the option
slightly easier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If core.bare is set to true in the config file of a repository that
the user is trying to create a working directory from we should
abort and suggest to the user that they remove the option first.
If we leave the core.bare=true setting in the config file then
working tree operations will get confused when they attempt to
execute in the new workdir, as it shares its config file with the
bare repository. The working tree operations will assume that the
workdir is bare and abort, which is not what the user wants.
If we changed core.bare to be false then working tree operations
will function in the workdir but other operations may fail in the
bare repository, as it claims to not be bare.
If we remove core.bare from the config then Git can fallback on
the legacy guessing behavior. This allows operations in the bare
repository to work as though it were bare, while operations in the
workdirs to act as though they are not bare.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
My day-job workflow involves using multiple workdirs attached to a
bunch of bare repositories. Such repositories are stored inside of
a directory called "foo.git", which means `git rev-parse --git-dir`
will return "." and not ".git". Under such conditions new-workdir
was getting confused about where the Git repository it was supplied
is actually located.
If we get "." for the result of --git-dir query it means we should
use the user supplied path as-is, and not attempt to perform any
magic on it, as the path is directly to the repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When performing a git-p4 clone operation on a Perforce repository,
where the changelists change in order of magnitude (e.g. 100 to 1000),
the set of changes to import from is not sorted properly. This is
because the data in the list is strings not integers. The other place
where this is done already converts the value to an integer, so it is
not affected.
Acked-by: Simon Hausmann <simon@lst.de>
This allows jumping to the correct file with the diff-mode commands.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have to load a tree difference for the purpose of testing
file patterns. But if our branch is being created and there is no
specific base to difference against in the rule our base will be
'0'x40. This is (usually) not a valid tree-ish object in a Git
repository, so there's nothing to difference against.
Instead of creating the empty tree and running git-diff against
that we just take the output of `ls-tree -r --name-only` and mark
every returned pathname as an add.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
Also don't require .git/info/exclude to exist in order to list unknown
files.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Acked-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces "git-verify-tag.sh" with "builtin-verify-tag.c".
Testing relies on the "git tag -v" tests calling this command.
A temporary file is needed when calling to gpg, because git is
already creating detached signatures (gpg option -b) to sign tags
(instead of leaving gpg to add the signature to the file by itself),
and those signatures need to be supplied in a separate file to be
verified by gpg.
The program uses git_mkstemp to create that temporary file needed by
gpg, instead of the previously used "$GIT_DIR/.tmp-vtag", in order to
allow the command to be used in read-only repositories, and also
prevent other instances of git to read or remove the same file.
Signal SIGPIPE is ignored because the program sometimes was
terminated because that signal when writing the input for gpg.
The command now can receive many tag names to be verified.
Documentation is also updated here to reflect this new behaviour.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fall back to USERPROFILE if HOME isn't set.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without argument the mode is toggled, which would do the wrong thing
if the file was already open.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we know which files have been modified, we can now run diff-index
or ls-files with a file list to refresh only the specified files
instead of the whole project.
This also allows proper refreshing of files upon add/delete/resolve,
instead of making assumptions about the new file state.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces the script "git-tag.sh" with "builtin-tag.c".
The existing test suite for "git tag" guarantees the compatibility
with the features provided by the script version.
There are some minor changes in the behaviour of "git tag" here:
"git tag -v" now can get more than one tag to verify, like "git tag -d" does,
"git tag" with no arguments prints all tags, more like "git branch" does,
and "git tag -n" also prints all tags with annotations (without needing -l).
Tests and documentation were also updated to reflect these changes.
The program is currently calling the script "git verify-tag" for verify.
This can be changed porting it to C and calling its functions directly
from builtin-tag.c.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
David Brown