* 'master' of git://repo.or.cz/git/git-p4:
git-p4: Added support for automatically importing newly appearing perforce branches.
git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.
git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run.
git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function).
git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync.
git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method.
git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.
git-p4: Always call 'p4 sync ...' before submitting to Perforce.
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>
* cr/tag:
Teach "git stripspace" the --strip-comments option
Make verify-tag a builtin.
builtin-tag.c: Fix two memory leaks and minor notation changes.
launch_editor(): Heed GIT_EDITOR and core.editor settings
Make git tag a builtin.
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>
* 'master' of git://people.freedesktop.org/~hausmann/git-p4:
git-p4: Cleanup, used common function for listing imported p4 branches
git-p4: Fix upstream branch detection for submit/rebase with multiple branches.
git-p4: Cleanup, make listExistingP4Branches a global function for later use.
git-p4: input to "p4 files" by stdin instead of arguments
git-p4: use subprocess in p4CmdList
Don't use git name-rev to locate the upstream git-p4 branch for rebase and submit but instead locate the branch by comparing the depot paths.
name-rev may produce results like wrongbranch~12 as it uses the first match.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
This approach, suggested by Alex Riesen, bypasses the need for xargs-style
argument list handling. The handling in question looks broken in a corner
case with SC_ARG_MAX=4096 and final argument over 96 characters.
Signed-off-by: Scott Lamb <slamb@slamb.org>
Signed-off-by: Simon Hausmann <simon@lst.de>
This allows bidirectional piping - useful for "-x -" to avoid commandline
arguments - and is a step toward bypassing the shell.
Signed-off-by: Scott Lamb <slamb@slamb.org>
Signed-off-by: Simon Hausmann <simon@lst.de>
Move git-p4import.py and Documentation/git-p4import.txt into
a contrib/p4import directory. Add a README there directing
people to contrib/fast-import/git-p4 as a better alternative.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git/fastimport:
Teach fast-import to recursively copy files/directories
Fix git-p4 on Windows to not use the Posix sysconf function.
Correct trivial typo in fast-import documentation
Add condition for Windows, since it doesn't support the os.sysconf module.
We hardcode the commandline limit to 2K, as that should work on most
Windows platforms.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Acked-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This script reads the existing commit log and .mailmap file,
and outputs author e-mail addresses that would map to more
than one names (most likely due to difference in the way they
are spelled, but some are due to ancient botched commits).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is necessary to make several editing functions work, like
C-u C-x v =
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script was originally posted on the git mailing list by
Randal L. Schwartz <merlyn@stonehenge.com>.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This tool will print vaguely pretty information about a pack. It
expects the output of "git-verify-pack -v" as input on stdin.
$ git-verify-pack -v | packinfo.pl
See the documentation in the script (contrib/stats/packinfo.pl)
for more information.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, "git rerere" was enabled by creating the directory
.git/rr-cache. That is definitely not in line with most other
features, which are enabled by a config variable.
So, check the config variable "rerere.enabled". If it is set
to "false" explicitely, do not activate rerere, even if
.git/rr-cache exists. This should help when you want to disable
rerere temporarily.
If "rerere.enabled" is not set at all, fall back to detection
of the directory .git/rr-cache.
[jc: with minimum tweaks]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using `git push origin +foo` to forcefully overwrite the remote
branch named foo is a common idiom, especially since + is shorter
than the long option --force and can be specified on a per-branch
basis.
We now complete `git push origin +foo` just like we do the standard
`git push origin foo`. The leading + on a branch refspec does not
alter the completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
rev-parse --git-dir outputs a full path - except for the single case
of when the path would be $(pwd)/.git, in which case it outputs simply
.git. Check for this special case and handle it.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Simon has asked that the git.git project include the git-p4 project
as at least a contrib/fast-import within git.git. I think it makes
a lot of sense, as git-p4 nicely complements the only other in-tree
fast-import user: import-tars.perl.
git-p4 is offered under the MIT license by its authors.
Raimund Bauer just discovered that the default bash completion for
a local branch name in a git-push line is not the best choice when
the branch does not exist on the remote system.
In the past we have always completed the local name 'test' as
"test:test", indicating that the destination name is the same as
the local name. But this fails when "test" does not yet exist on
the remote system, as there is no "test" branch for it to match
the name against.
Fortunately git-push does the right thing when given just the
local branch, as it assumes you want to use the same name in the
destination repository. So we now offer "test" as the completion
in a git-push line, and let git-push assume that is also the remote
branch name.
We also still support the remote branch completion after the :,
but only if the user manually adds the colon before trying to get
a completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This isn't used right now in git-p4 but I use it in an external script that loads git-p4 as module.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
Collect "unknown" source branches separately and register them at the end.
Also added a minor speed up to splitFilesIntoBranches by breaking out of the loop through all branches when it's safe.
Signed-off-by: Simon Hausmann <simon@lst.de>
A perforce command with all the files in the repo is generated to get
all the file content.
Here is a patch to break it into multiple successive perforce command
who uses 4K of parameter max, and collect the output for later.
It works, but not for big depos, because the whole perforce depo
content is stored in memory in P4Sync.run(), and it looks like mine is
bigger than 2 Gigs, so I had to kill the process.
[Simon: I added the bit about using SC_ARG_MAX, as suggested by Han-Wen]
Signed-off-by: Benjamin Sergeant <bsergean@gmail.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
pass -C -C option to git-blame so that blame browsing
works when the data is copied over from other files.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The async reading from the pipe was skipping some of the
input lines. Fix the same by making sure that we add the
partial content of the previous read to the newly read
data.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using git-p4 in this manner:
git-p4 clone //depot/path/project myproject
If "myproject" already exists as a dir, but not a valid git repo, it fails
to create the directory.
Signed-off-by: Kevin Green <Kevin.Green@morganstanley.com>
Define __slots__ for the Commit class. This reserves space in each Commit
object for only the defined variables. On my system this reduces heap usage
when viewing a kernel repo by 12% ~= 55868 KB.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes the Commit class to use new-style class, which has
been available since Python 2.2 (Dec 2001). This is a necessary
step in order to use __slots__[] declaration, so that we can
reduce the memory footprint in the next patch.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Need to use min instead of max for prev/cur to avoid out-of-bounds
string access. Also treat "i" as index of the last match instead of
a length because in case of a complete match of the two strings
i was off by one.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- import into master/local if --import-local is set
- use Die() for exiting
- if --verbose is set, raise Exception()
- use joined strings iso. `list` for progress printing
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
- print commands with \n
- extractDepotPathsAndChangeFromGitLog -> extractSettings, returning
dict.
- store keepRepoPath in [git-p4: ] line
- create a main() function, so git-p4 can be pychecked
- use --destination for clone destination. This simplifies logic
for --keep-path
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
On one particular system I like to keep a cluster of bare Git
repositories and spawn new-workdirs off of them. Since the bare
repositories don't have working directories associated with them
they don't have a .git/ subdirectory that hosts the repository we
are linking to.
Using a bare repository as the backing repository for a workdir
created by this script does require that the user delete core.bare
from the repository's configuration file, so that Git auto-senses
the bareness of a repository based on pathname information, and
not based on the config file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A few new configuration options grew out of the woodwork during the
1.5.2 series. Most of these are pretty easy to support a completion
of, so we do so.
I wanted to also add completion support for the <driver> part of
merge.<driver>.name but to do that we have to look at all of the
.gitattributes files and guess what the unique set of <driver>
strings would be. Since this appears to be non-trivial I'm punting
on it at this time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
(Somewhat) recently git-log learned about --reverse (to show commits
in the opposite order) and a looong time ago I think it learned
about --raw (to show the raw diff, rather than a unified diff).
These are both useful options, so we should make them easy for the
user to complete.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently the git-remote command grew an update subcommand, which
can be used to execute git-fetch across multiple repositories
in a single step. These can be configured with the 'remotes.*'
configuration options, so we can offer completion for any name that
matches and appears to be useful to git-remote update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
1) Added a note about supporting the long options for most commands,
as we have been doing so for quite some time.
2) Include a notice that these routines are covered by the GPL,
as that may not be obvious, even though they are distributed
as part of the core Git distribution.
3) Added a short section on how to send patches to the routines,
and to whom they should get sent to. Currently that is me,
as I am the active maintainer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This was just me being silly; I put the --not option into the
completion list twice. There's no duplicates shown in the shell
as the shell removes them before showing them to the user. But we
really don't need the duplicates in the source script either.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We've had completion for git-log for quite some time, but just
today I noticed we don't have it for the new builtin shortlog
that runs git-log internally. This is indeed a handy thing to
have completion for, especially when your branch names are of
the Very-Very-Long-and-Hard/To-Type/Variety/That-Some-Use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The diff-* programs are meant to be plumbing for the diff frontend;
most end users aren't invoking these commands directly. Consequently
we should avoid showing them as possible completions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
[sp: Modified Jonas' original patch to keep checkout-index
as a a valid completion.]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
applying them to a Perforce checkout. This should make it possible to apply git
commits with binary files that cannot be handled by path.
Signed-off-by: Simon Hausmann <simon@lst.de>
to use for the current import by looking at the p4 tags. The current approach of using
the log message works better.
Signed-off-by: Simon Hausmann <simon@lst.de>
it's creating a new branch from itself. It's a sensible error in general but
in the case of incremental imports we have to apply force :)
Signed-off-by: Simon Hausmann <simon@lst.de>
* maint:
format-patch: add MIME-Version header when we add content-type.
Fixed link in user-manual
import-tars: Use the "Link indicator" to identify directories
git name-rev writes beyond the end of malloc() with large generations
Documentation/branch: fix small typo in -D example
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.
Noticed by Chris Riddoch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Randal L. Schwartz pointed out multiple times that we should be
testing the length of the name string here, not if it is "true".
The problem is the string '0' is actually false in Perl when we
try to evaluate it in this context, as '0' is 0 numerically and
the number 0 is treated as a false value. This would cause us
to break out of the import loop early if anyone had a file or
directory named "0".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This extension allows GNU tar to process file names in excess of the 100
characters defined by the original tar standard. It does this by faking a
file, named '././@LongLink' containing the true file name, and then adding
the file with a truncated name. The idea is that tar without this
extension will write out a file with the long file name, and write the
contents into a file with truncated name.
Unfortunately, GNU tar does a lousy job at times. When truncating results
in a _directory_ name, it will happily use _that_ as a truncated name for
the file.
An example where this actually happens is gcc-4.1.2, where the full path
of the file WeThrowThisExceptionHelper.java truncates _exactly_ before the
basename. So, we have to support that ad-hoc extension.
This bug was noticed by Chris Riddoch on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
http.c: Fix problem with repeated calls of http_init
Add missing reference to GIT_COMMITTER_DATE in git-commit-tree documentation
Fix import-tars fix.
Update .mailmap with "Michael"
Do not barf on too long action description
Catch empty pathnames in trees during fsck
Don't allow empty pathnames in fast-import
import-tars: be nice to wrong directory modes
git-svn: Added 'find-rev' command
git shortlog documentation: add long options and fix a typo
This heeds advice from our resident Perl expert to make sure
the script is not confused with a string that ends with /\n
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some tars seem to have modes 0755 for directories, not 01000755. Do
not generate an empty object for them, but ignore them.
Noticed by riddochc on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The sed command that extracted the first line of the project description
didn't include the -n switch and hence the project name was being
printed twice. This was ruining the email header generation because it
was assumed that the description was only one line and was included in
the subject. This turned the subject into a two line item and
prematurely finished the header.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes a non-fast-forward update doesn't add new commits, it merely
removes old commits. This patch adds support for detecting that and
outputting a more correct message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
fast-import: size_t vs ssize_t
fix importing of subversion tars
Don't repack existing objects in fast-import
add a / between the prefix and name fields of the tar archive if prefix
is non-empty.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a new configuration option clean.requireForce. If set, git-clean will
refuse to run, unless forced with the new -f option, or not acting due to -n.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
List files modifed as a part of the commit in the diff window
Support annotation of the file listed in the diff window
Support history browsing in the annotation window.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a description of the commit to the reflog using the first line of
the log message, the same way the git-commit script does it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm using a variant of this update hook in a corporate environment
where we perform some validations of the commits and tags that
are being pushed. The model is a "central repository" type setup,
where users are given access to push to specific branches within
the shared central repository. In this particular installation we
run a specially patched git-receive-pack in setuid mode via SSH,
allowing all writes into the repository as the repository owner,
but only if this hook blesses it.
One of the major checks we perform with this hook is that the
'committer' line of a commit, or the 'tagger' line of a new annotated
tag actually correlates to the UNIX user who is performing the push.
Users can falsify these lines on their local repositories, but
the central repository that management trusts will reject all such
forgery attempts. Of course 'author' lines are still allowed to
be any value, as sometimes changes do come from other individuals.
Another nice feature of this hook is the access control lists for
all repositories on the system can also be stored and tracked in
a supporting Git repository, which can also be access controlled
by itself. This allows full auditing of who-had-what-when-and-why,
thanks to git-blame's data mining capabilities.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Fix lseek(2) calls with args 2 and 3 swapped
Honor -p<n> when applying git diffs
Fix dependency of common-cmds.h
Fix renaming branch without config file
DESTDIR support for git/contrib/emacs
gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches
Document --left-right option to rev-list.
Revert "builtin-archive: use RUN_SETUP"
rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.
rerere: make sorting really stable.
Fix t4200-rerere for white-space from "wc -l"
I thought it would be cool to have different set of colors for each
git-blame-mode. Function `git-blame-new-commit' does this for us
picking when possible, a random colors based on the set we build on
startup. When it fails, `git-blame-ancient-color' will be used. We
also take care not to use the same color more than once (thank you
David Kågedal, really).
* Prevent (future possible) namespace clash by renaming `color-scale'
into `git-blame-color-scale'. Definition has been changed to be more
in the "lisp" way (thanks for help to #emacs). Also added a small
description of what it does.
* Added docstrings at some point and instructed defvar when a variable
was candidate to customisation by users.
* Added missing defvar to silent byte-compilers (git-blame-file,
git-blame-current)
* Do not require 'cl at startup
* Added more informations on compatibility
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Acked-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-blame-mode has been splitted into git-blame-mode-on and
git-blame-mode-off; it now conditionnaly calls one of them depending
of how we call it. Code is now easier to maintain and to understand.
Fixed `git-reblame' function: interactive form was at the wrong
place.
String displayed on the mode line is now configurable through
`git-blame-mode-line-string` (default to " blame").
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a simple script to create a working directory that uses symlinks
to point at an exisiting repository. This allows having different
branches in different working directories but all from the same
repository.
Based on a description from Junio of how he creates multiple working
directories[1]. With the following caveat:
"This risks confusion for an uninitiated if you update a ref that
is checked out in another working tree, but modulo that caveat
it works reasonably well."
[1] http://article.gmane.org/gmane.comp.version-control.git/41513/
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The update hook is no longer the correct place to generate emails; there
is now the hooks/post-receive script which is run automatically after a
ref has been updated.
This patch is to make use of that new location, and to address some
faults in the old update hook.
The primary problem in the conversion was that in the update hook, the
ref has not actually been changed, but is about to be. In the
post-receive hook the ref has already been updated. That meant that
where we previously had lines like:
git rev-list --not --all
would now give the wrong list because "--all" in the post-receive hook
includes the ref that we are making the email for. This made it more
difficult to show only the new revisions added by this update.
The solution is not pretty; however it does work and doesn't need any
changes to git-rev-list itself. It also fixes (more accurately: reduces
the likelihood of) a nasty race when another update occurs while this
script is running. The solution, in short, looks like this (see the
source code for a longer explanation)
git rev-parse --not --all | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $oldrev..$newrev
This uses git-rev-parse followed by grep to filter out the revision of
the ref in question before it gets to rev-list and inhibits the output
of itself. By using $(git rev-parse $revname) rather than $newrev as the
filter, it also takes care of the situation where another update to the
same ref has been made since $refname was $newrev.
The second problem that is addressed is that of tags inhibiting the
correct output of an update email. Consider this, with somebranch and
sometag pointing at the same revision:
git push origin somebranch
git push origin sometag
That would work fine; the push of the branch would generate an email
containing all the new commits introduced by the update, then the push
of the tag would generate the shortlog formatted tag email. Now
consider:
git push origin sometag
git push origin somebranch
When some branch comes to run its "--not --all" line, it will find
sometag, and filter those commits from the email - leaving nothing.
That meant that those commits would not show (in full) on any email.
The fix is to not use "--all", and instead use "--branches" in the
git-rev-parse command.
Other changes
* Lose the monstrous one-giant-script layout and put things in easy to
digest functions. This makes it much easier to find the place you
need to change if you wanted to customise the output. I've also
tried to write more verbose comments for the same reason. The hook
script is big, mainly because of all the different cases that it has
to handle, so being easy to navigate is important.
* All uses of "git-command" changed to "git command", to cope better
if a user decided not to install all the hard links to git;
* Cleaned up some of the English in the email
* The fact that the receive hook makes the ref available also allows me
to use Shawn Pearce's fantastic suggestion that an annotated tag can
be parsed with git-for-each-ref. This removes the potentially
non-portable use of "<<<" heredocs and the nasty messing around with
"date" to convert numbers of seconds UTC to a real date
* Deletions are now caught and notified (briefly)
* To help with debugging, I've retained the command line mode from the
update hook; but made it so that the output is not emailed, it's just
printed to the screen. This could then be redirected if the user
wanted
* Removed the "Hello" from the beginning of the email - it's just
noise, and no one seriously has their day made happier by "friendly"
programs
* The fact that it doesn't rely on repository state as an indicator any
more means that it's far more stable in its output; hopefully the
same arguments will always generate the same email - even if the
repository changes in the future. This means you can easily recreate
an email should you want to.
* Included Jim Meyering's envelope sender option for the sendmail call
* The hook is now so big that it was inappropriate to copy it
to every repository by keeping it in the templates directory.
Instead, I've put a comment saying to look in contrib/hooks, and
given an example of calling the script from that template hook. The
advantage of calling the script residing at some fixed location is
that if a future package of git included a bug fixed version of the
script, that would be picked up automatically, and the user would not
have to notice and manually copy the new hook to every repository
that uses it.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use git-log --pretty=oneline to print a short description of the
current HEAD (and merge heads if any) in the buffer header.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple but powerful continuous integration build system
for Git. It works by receiving push events from repositories
through the post-receive hook, aggregates them on a per-branch
basis into a first-come-first-serve build queue, and lets a
background build daemon perform builds one at a time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Run the pre-commit and post-commit hooks at appropriate places, and
display their output if any.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git.el: Retrieve commit log information from .dotest directory.
git.el: Avoid appending a signoff line that is already present.
setup_git_directory_gently: fix off-by-one error
user-manual: install user manual stylesheet with other web documents
user-manual: fix rendering of history diagrams
user-manual: fix missing colon in git-show example
user-manual: fix inconsistent use of pull and merge
user-manual: fix inconsistent example
glossary: fix overoptimistic automatic linking of defined terms
Documentation: s/seperator/separator/
Adjust reflog filemode in shared repository
If a git-am or git-rebase is in progress, fill the commit log buffer
from the commit information found in the various files in the .dotest
directory.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also avoid inserting an extra newline if other signoff lines are
present.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added a disk-cache p4 output so debugging imports is faster.
Added --known-branches commandline option for pre-defining branches.
Various other fixes...
Signed-off-by: Simon Hausmann <hausmann@kde.org>
Add git-blame as a candidate to the byte-compilation.
batch-byte-compile is the prefered way to byte-compile files in
batch mode. Use it instead of the interactive function.
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing Release Notes for 1.5.0.3
Documentation: git-remote add [-t <branch>] [-m <branch>] [-f] name url
Include config.mak in doc/Makefile
git.el: Set the default commit coding system from the repository config.
git-archimport: support empty summaries, put summary on a single line.
http-push.c::lock_remote(): validate all remote refs.
git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
If not otherwise specified, take the default coding system for commits
from the 'i18n.commitencoding' repository configuration value.
Also set the buffer-file-coding-system variable in the log buffer to
make the selected coding system visible on the modeline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
builtin-fmt-merge-msg: fix bugs in --file option
index-pack: Loop over pread until data loading is complete.
blameview: Fix the browse behavior in blameview
Fix minor typos/grammar in user-manual.txt
Correct ordering in git-cvsimport's option documentation
git-show: Reject native ref
Fix git-show man page formatting in the EXAMPLES section
* maint:
Use gunzip -c over gzcat in import-tars example.
git-gui: Don't crash in citool mode on initial commit.
git-gui: Remove TODO list.
git-gui: Include browser in our usage message.
git-gui: Change summary of git-gui.
git-gui: Display all authors of git-gui.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Correct crash when saving options in blame mode.
git-gui: Expose the browser as a subcommand.
git-gui: Create new branches from a tag.
git-gui: Prefer version file over git-describe.
git-gui: Print version on the console.
git-gui: More consistently display the application name.
git-gui: Permit merging tags into the current branch.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Refactor 'exec git subcmd' idiom.
Not everyone has gzcat or bzcat installed on their system, but
gunzip -c and bunzip2 -c perform the same task and are available
if the user has installed gzip support or bzip2 support.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Also spawn the the new blameview in the background
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is a bug with this $git_mode variable which should be 0644
or 0755, but nothing else I think.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new git-fast-import command is not intended to be invoked
directly by an end user. So offering it as a possible completion
for a subcommand is not very useful.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This file is incomplete, unmaintained, and it doesn't belong in the GIT
package anyway.
A more complete version is already included in the Linux -mm tree and
is about to make its way into mainline RSN.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the support for automatically updating the buffer while editing.
A configuration variable git-blame-autoupdate controls whether this should
be enabled or not.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-blame use the current buffer contents for the blame, instead of
the saved file. This makes the blame correct even if there are unsaved
changes.
Also added a git-reblame command.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change installation instructions to using either "(require 'git-blame)"
or appropriate autoload instruction in GNU Emacs init file, .emacs
This required adding "(provide 'git-blame)" at the end of git-blame.el
and adding [preliminary] docstring to `git-blame-mode' function for
consistency (to mark function as interactive in `autoload' we have to
provide docstring as DOCSTRING is third arg, and INTERACTIVE fourth,
and both are optional). `git-blame-mode' is marked to autoload.
While at it ensure that we add `git-blame-mode' to `minor-mode-alist'
only once (in a way that does not depend on `cl' package).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add Emacs Lisp file headers, according to "Coding Conventions" chapter
in Emacs Lisp Reference Manual and Elisp Area Convetions for
EmacsWiki:
http://www.emacswiki.org/cgi-bin/wiki/ElispAreaConventions
Those include: copyright notice, GNU GPL boilerplate, description and
instalation instructions as provided in email and in commit message
introducing git-blame.el, compatibility notes from another email by
David Kågedal about what to change to use it in GNU Emacs 20, and
"git-blame ends here" to detect if file was truncated. First line
includes setting file encoding via first line local variable values
(file variables).
Added comment to "(require 'cl)" to note why it is needed; "Coding
Conventions" advises to avoid require the `cl' package of Common Lisp
extensions at run time.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
tar archive frontend for fast-import.
Correct spelling of fast-import in docs.
Correct some language in fast-import documentation.
Correct ^0 asciidoc syntax in fast-import docs.
This is an example fast-import frontend, in less than 100 lines
of Perl. It accepts one or more tar archives on the command line,
passes them through gzcat/bzcat/zcat if necessary, parses out the
individual file headers and feeds all contained data to fast-import.
No temporary files are involved.
Each tar is treated as one commit, with the commit timestamp coming
from the oldest file modification date found within the tar.
Each tar is also tagged with an annotated tag, using the basename
of the tar file as the name of the tag.
Currently symbolic links and hard links are not handled by the
importer. The file checksums are also not verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Added support for @all as revision range specifier to import all changes to a given depot path.
Also default to an import of #head if no revrange is specified.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
Completing the 3 core subcommands to git-remote, along with the
names of remotes for 'show' and 'prune' (which take only existing
remotes) is handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently `git-rebase -m` uses a metadata directory within .git
(.git/.dotest-merge) rather than .dotest used by git-am (and
git-rebase without the -m option). This caused the completion code
to not offer --continue, --skip or --abort when working within a
`git-rebase -m` session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds. Plus a few minor fixes.
To use:
1) Load into emacs: M-x load-file RET git-blame.el RET
2) Open a git-controlled file
3) Blame: M-x git-blame-mode
Signed-off-by: Junio C Hamano <junkio@cox.net>
hg-to-git.py is able to convert a Mercurial repository into a git one,
and preserves the branches in the process (unlike tailor)
hg-to-git.py can probably be greatly improved (it's a rather crude
combination of shell and python) but it does already work quite well for
me. Features:
- supports incremental conversion
(for keeping a git repo in sync with a hg one)
- supports hg branches
- converts hg tags
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Double clicking on the row execs a new blameview with commit hash
as argument.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now offer completion support for git-bisect's subcommands,
as well as ref name completion on the good/bad/reset subcommands.
This should make interacting with git-bisect slightly easier on
the fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've recently added --add as an argument to git-config, but I
missed putting it into the earlier round of git-config updates
within the bash completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't offer resolve as a possible subcommand completion. If you
read the top of the script, there is a big warning about how it
will go away soon in the near future. People should not be using it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm lazy. I don't want to type out --prune if bash can do it for
me with --<tab>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently nobody really makes use of git-diff-stages, as nobody
has complained that it is not supported by the git-diff frontend.
Since its likely this will go away in the future, we should not
offer it as a possible subcommand completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I just realized I did not support ref name completion for git-cherry.
This tool is just too useful to contributors who submit patches
upstream by email; completion support for it is very handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
format-patch/log/whatchanged all take --not and --all as options
to the internal revlist process. So these should be supported
as possible completions.
gitk takes anything rev-list/log/whatchanged takes, so we should
use complete_revlist to handle its options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because our use of -o nospace prevents bash from adding a trailing space
when a completion is unique and has been fully completed, we need to
perform this addition on our own. This (large) change converts all
existing uses of compgen to our wrapper __gitcomp which attempts to
handle this by tacking a trailing space onto the end of each offered
option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In many cases we know a completion will be unique, but we've disabled
bash's automatic space addition (-o nospace) so we need to do it
ourselves when necessary.
This change adds additional support for new configuration options
added in 1.5.0, as well as some extended completion support for
the color.* family of options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of these commands are not ones you want to invoke from the
command line on a frequent basis, or have been renamed in 1.5.0 to
more friendly versions, but the old names are being left behind to
support existing scripts in the wild.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we use the nospace option for our completion function for
the main 'git' wrapper bash won't automatically add a space after a
unique completion has been made by the user. This has been pointed
out in the past by Linus Torvalds as an undesired behavior. I agree.
We have to use the nospace option to ensure path completion for
a command such as `git show` works properly, but that breaks the
common case of getting the space for a unique completion. So now we
set IFS=$'\n' (linefeed) and add a trailing space to every possible
completion option. This causes bash to insert the space when the
completion is unique.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new --interactive mode of git-add can be very useful, so users
will probably want to have completion for it.
Likewise the new git-add--interactive executable is actually a
plumbing command. Its invoked by `git add --interactive` and is
not intended to be invoked directly by the user. Therefore we
should hide it from the list of available Git commands.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-show is capable of displaying any file content from any
revision and is the approved Porcelain-ish level method of doing so,
cat-file should no longer be classified as a user-level utility by
the bash completion package.
I'm also classifying the new git-reflog command as plumbing for the
time being as there are no subcommands which are really useful to
the end-user. git-gc already invokes `git reflog expire --all`,
which makes it rather unnecessary for the user to invoke it directly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The short options (-l, -f, -d) for git-branch are rather silly to
include in the completion generation as these options must be fully
typed out by the user and most users already know what the options
are anyway, so including them in the suggested completions does
not offer huge value. (The same goes for git-checkout and git-diff.)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use p4 files //depot/path/...@revision to determine the state of the project and create a "fake" git commit from it.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
Try to find the last imported p4 change number from the git tags and try to pass the right parent for commits to git fast-import.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
Fix blameview to use git-cat-file to read the file content.
This make sure we show the right content when we have modified
file in the working directory which is not committed.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is necessary for vc-version-other-window. Based on a patch by Sam
Vilain <sam.vilain@catalyst.net.nz>.
Currently, the vc-git-checkout function uses `git checkout' to fetch a
file from the git repository to the working copy. However, it is
completely ignoring the input argument that specifies the destination
file. `git-checkout' does not support specifying this, so we have to
use `git-cat-file', capture the output in a buffer and then save it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, the vc-git-checkout function uses `git checkout' to fetch a
file from the git repository to the working copy. However, it is
completely ignoring the input argument that specifies the destination
file. `git-checkout' does not support specifying this, so we have to
use `git-cat-file', capture the output in a buffer and then save it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not all echos know -n. This was causing a test failure in
t5401-update-hooks.sh, but not t3800-mktag.sh for some reason.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also use `concat' instead of `format' in the pretty-printer since
format doesn't preserve properties under XEmacs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead, reinitialize the keywords after the fact. This avoids
conflicts with other users of log-edit mode, like pcl-cvs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It doesn't make a difference for git.el, but it helps when interacting
with git-rebase and friends.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8). Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.
The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch changes the syntax highlighting to correctly match the new
text of the commit message introduced by
82dca84871
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that 'git show' accepts ref:path as an argument to specify a
tree or blob we should use the same completion logic as we support
for cat-file's object identifier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While adding colour to the branch command it was pointed out that a
config option like "branch.color" conflicts with the pre-existing
"branch.something" namespace used for specifying default merge urls and
branches. The suggested solution was to flip the order of the
components to "color.branch", which I did for colourising branch.
This patch does the same thing for
- git-log (color.diff)
- git-status (color.status)
- git-diff (color.diff)
- pager (color.pager)
I haven't removed the old config options; but they should probably be
deprecated and eventually removed to prevent future namespace
collisions. I've done this deprecation by changing the documentation
for the config file to match the new names; and adding the "color.XXX"
options to contrib/completion/git-completion.bash.
Unfortunately git-svn reads "diff.color" and "pager.color"; which I
don't like to change unilaterally.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>"
no longer would complete to "foo". Instead it printed out an internal
git error ("fatal: Not a git repository: '.'").
The break occurred when I tried to improve performance by switching from
git-peek-remote to git-for-each-ref. Apparently git-peek-remote will
drop into directory "$1/.git" (where $1 is its first parameter) if it
is given a repository with a working directory. This allowed the bash
completion code to work properly even though it was not handing over
the true repository directory.
So now we do a stat in bash to see if we need to add "/.git" to the
path string before running any command with --git-dir.
I also tried to optimize away two "git rev-parse --git-dir" invocations
in common cases like "git log fo<tab>" as typically the user is in the
top level directory of their project and therefore the .git subdirectory
is in the current working directory. This should make a difference on
systems where fork+exec might take a little while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the user's git installation is not likely to grow a new command
or merge strategy in the lifespan of the current shell process we can
save time during completion operations by caching these lists during
sourcing of the completion support.
If the git executable is not available or we run into errors while
caching at load time then we defer these to runtime and generate
the list on the fly. This might happen if the user doesn't put git
into their PATH until after the completion script gets sourced.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because git-merge and git-rebase both accept -s, --strategy or --strategy=
we should recognize all three formats in the bash completion functions and
issue back all merge strategies on demand.
I also moved the prior word testing to be before the current word testing,
as the current word cannot be completed with -- if the prior word was an
option which requires a parameter, such as -s or --strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a really ugly completion script for git-repo-config, but it has
some nice properties. I've added all of the documented configuration
parameters from Documentation/config.txt to the script, allowing the
user to complete any standard configuration parameter name.
We also have some intelligence for the remote.*.* and branch.*.* keys
by completing not only the key name (e.g. remote.origin) but also the
values (e.g. remote.*.fetch completes to the branches available on the
corresponding remote).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that people are really likely to start using separate remotes
(due to the default in git-clone changing) we should support ref
completion for these refs in as many commands as possible.
While we are working on this routine we should use for-each-ref
to obtain a list of local refs, as this should run faster than
peek-remote as it does not need to dereference tag objects in
order to produce the list of refs back to us. It should also
be more friendly to users of StGIT as we won't generate a list
of the StGIT metadata refs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Typing out options to git log/show/whatchanged can take a while, but
we can easily complete them with bash. So list the most common ones,
especially --pretty=online|short|medium|... so that users don't need
to type everything out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As git-rebase is a popular command bash should know how to complete
reference names and its long options. We only support completions
which make sense given the current state of the repository, that
way users don't get shown --continue/--skip/--abort on the first
execution.
Also added support for long option --strategy to git-merge, as I
missed that option earlier and just noticed it while implementing
git-rebase.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Provide completion for currently known long options supported by
git-format-patch as well as the revision list specification argument,
which is generally either a refname or in the form a..b.
Since _git_log was the only code that knew how to complete a..b, but
we want to start adding option support to _git_log also refactor the
a..b completion logic out into its own function.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Many users want to display the current branch name of the current git
repository as part of their PS1 prompt, much as their PS1 prompt might
also display the current working directory name.
We don't force our own PS1 onto the user. Instead we let them craft
their own PS1 string and offer them the function __git_ps1 which they
can invoke to obtain either "" (when not in a git repository) or
"(%s)" where %s is the name of the current branch, as read from HEAD,
with the leading refs/heads/ removed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Users generally are not going to need to invoke plumbing-level commands
from within one line shell commands. If they are invoking these commands
then it is likely that they are glueing them together into a shell script
to perform an action, in which case bash completion for these commands is
of relatively little use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-merge is high-level Porcelain users are going to expect
to be able to use it from the command line, in which case we really
should also be able to complete ref names as parameters.
I'm also including completion support for the merge strategies
that are supported by git-merge.sh, should the user wish to use a
different strategy than their default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code had "/pub/scm/linux/kernel/git/" hardcoded which was
too specific to the kernel project.
With this, a line in the .mailmap file:
# repo-abbrev: /pub/scm/linux/kernel/git/
can be used to cause the substring to be abbreviated to /.../
on the title line of the commit message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
While at it, remove the linux specific mailmap into
contrib/mailmap.linux.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This change removes between 1 and 4 sed invocations per completion
entered by the user. In the case of cat-file the 4 invocations per
completion can take a while on Cygwin; running these replacements
directly within bash saves some time for the end user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that log, whatchanged, rev-list, etc. support the symmetric
difference operator '...' we should provide bash completion for it
just like we do for '..'.
While we are at it we can remove two sed invocations during the
interactive prompt and replace them with internal bash operations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has setup a command line of "git --git-dir=baz" then
anything we complete must be performed within the scope of "baz"
and not the current working directory.
This is useful with commands such as "git --git-dir=git.git log m"
to complete out "master" and view the log for the master branch of
the git.git repository. As a nice side effect this also works for
aliases within the target repository, just as git would honor them.
Unfortunately because we still examine arguments by absolute position
in most of the more complex commands (e.g. git push) using --git-dir
with those commands will probably still cause completion to fail.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that Git natively supports remote specifications within the
config file such as:
[remote "origin"]
url = ...
we should provide bash completion support "out of the box" for
these remotes, just like we do for the .git/remotes directory.
Also cleaned up the __git_aliases expansion to use the same form
of querying and filtering repo-config as this saves two fork/execs
in the middle of a user prompted completion. Finally also forced
the variable 'word' to be local within __git_aliased_command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The only platform which actually needs to define .exe suffixes as
part of its completion set is Cygwin. So don't define them on any
other platform.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The show-branch and merge-base commands were partially supported
when it came to bash completions as they were only specified in
one form another. Now we specify them in both forms.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Completion for the --hard/--soft/--mixed modes of operation as
well as a ref name for <commit-ish> can be very useful and save
some fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Cygwin a user might complete the new git-branch builtin as
git-branch.exe, at which point bash requires a new completion
registration for the command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets us take advantage of the fact that git-cherry-pick now saves
the message in MERGE_MSG too.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Bound to 'o' by default, compatible with pcl-cvs and
buffer-mode. Suggested by Han-Wen Nienhuys.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is useful when doing a merge that changes many files with only a
few conflicts here and there.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Add aliases to the list of available git commands.
- Make completion work for aliased commands.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
vc-git complains that it can't find the definition of ignore-errors
unless I (require 'cl). So I guess the correct place to do that is in
the file itself.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Provide some more detailed installation instructions, for the
elisp-challenged among us.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The deleted file should be labeled "renamed to" and the added file
"renamed from", not the other way around (duh!)
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a set of bash completion routines for many of the
popular core Git tools. I wrote these routines from scratch
after reading the git-compl and git-compl-lib routines available
from the gitcompletion package at http://gitweb.hawaga.org.uk/
and found those to be lacking in functionality for some commands.
Consequently there may be some similarities but many differences.
Since these are completion routines only for tools shipped with
core Git and since bash is a popular shell on many of the native
core Git platforms (Linux, Mac OS X, Solaris, BSD) including these
routines as part of the stock package would probably be convienent
for many users.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch avoids problems if vc-git.el is installed and activated, but
the git executable is not available, for example
http://list-archive.xemacs.org/xemacs-beta/200608/msg00062.html
Signed-off-by: Ville Skyttä <scop@xemacs.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default, running git-status again will now reuse an existing buffer
that displays the same directory. The old behavior of always creating
a new buffer can be obtained by customizing the git-reuse-status-buffer
option.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This way the ignore command will really only ignore the marked files
and not files with the same name in subdirectories.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add bindings for "h" and "?" in git-status-mode to display help about the mode,
including keymap via (describe-function 'git-status-mode), like in PCL-CVS.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The only visible change is that git-blame doesn't understand
"--compability" anymore, but it does accept "--compatibility" instead,
which is already documented.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow NO_SVN_TESTS to be defined to skip git-svn tests. These
tests are time-consuming due to SVN being slow, and even more so
if SVN Perl libraries are not available.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's a patch that fixes print-log and diff compatibility with recent
vc versions, such as current GNU Emacs CVS.
Signed-off-by: Ville Skytt,Ad(B <scop@xemacs.org>
Thanks to Santi <sbejar@gmail.com> for the bug report and explanation:
> /path/to/repository/project/file
> /path/to/repository/project-2/file
<...>
> you end up with a project with the following files:
>
> file
> -2/file
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn init url://to/the/repo local-repo
will create the local-repo dirrectory if doesn't exist yet and
populate it as expected.
Original patch by Luca Barbato, cleaned up and made to work for
the current version of git-svn by me (Eric Wong).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch renames man1 and man7 variables to man1dir and man7dir,
according to "Makefile Conventions: Variables for Installation
Directories" in make.info of GNU Make.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Makefiles in subdirectories now use existing value of INSTALL, bindir,
mandir if it is set, allowing those to be set in main Makefile or in
included config.mak. Main Makefile exports variables which it sets.
Accidentally it renames bin to bindir in Documentation/Makefile
(should be bindir from start, but is unused, perhaps to be removed).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Slower connections can make git-svn look as if it's doing
nothing for a long time; leaving the user wondering if we're
actually doing anything. Now we print some file progress just
to assure the user that something is going on while they're
waiting.
Added the -q/--quiet option to users to revert to the old method
if they preferred it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
--follow-parent:
This is especially helpful when we're tracking a directory
that has been moved around within the repository, or if we
started tracking a branch and never tracked the trunk it was
descended from.
This relies on the SVN::* libraries to work. We can't
reliably parse path info from the svn command-line client
without relying on XML, so it's better just to have the SVN::*
libs installed.
This also removes oldvalue verification when calling update-ref
In SVN, branches can be deleted, and then recreated under the
same path as the original one with different ancestry
information, causing parent information to be mismatched /
misordered.
Also force the current ref, if existing, to be a parent,
regardless of whether or not it was specified.
--no-metadata:
This gets rid of the git-svn-id: lines at the end of every commit.
With this, you lose the ability to use the rebuild command. If
you ever lose your .git/svn/git-svn/.rev_db file, you won't be
able to fetch again, either. This is fine for one-shot imports.
Also fix some issues with multi-fetch --follow-parent that were
exposed while testing this. Additionally, repack checking is
simplified greatly.
git-svn log will not work on repositories using this, either.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended for interoperability with git-svnimport.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'graft-branches' command can now analyze tree matches for
merge detection after commits are done, when --branch or
--branch-all-refs options are used.
We ensure that tree joins (--branch and --branch-all-refs
options) during commit time only add SVN parents that occurred
before the commit we're importing
Also fixed branch detection via merge messages, this manner of
merge detection (a la git-svnimport) is really all fuzzy, but at
least it actually works now :)
Add some new tests to go along with these fixes, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tested on a plain Ubuntu Hoary installation
using subversion 1.1.1-2ubuntu3
1.1.x issues I had to deal with:
* Avoid the noisy command-line client compatibility check if we
use the libraries.
* get_log() arguments differ (now using a nice wrapper from
Junio's suggestion)
* get_file() is picky about what kind of file handles it gets,
so I ended up redirecting STDOUT. I'm probably overflushing
my file handles, but that's the safest thing to do...
* BDB kept segfaulting on me during tests, so svnadmin will use FSFS
whenever we can.
* If somebody used an expanded CVS $Id$ line inside a file, then
propsetting it to use svn:keywords will cause the original CVS
$Id$ to be retained when asked for the original file. As far as
I can see, this is a server-side issue. We won't care in the
test anymore, as long as it's not expanded by SVN, a static
CVS $Id$ line is fine.
While we're at making ourselves more compatible, avoid grep
along with the -q flag, which is GNU-specific. (grep avoidance
tip from Junio, too)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Trying to open an interactive editor in the console while stdout is
being piped to the parent process doesn't work out very well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When tracking directories with nearly all of its files at
the most nested levels, --rmdir would accidentally go too
far when deleting.
Of course, we'll add a test for this condition, too.
Makefile: automatically run new tests as they appear in t/
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We will now automatically fetch the refs/remotes/git-svn ref
from origin and store a Pull: line for it.
--remote=<origin> may be passed if your remote is named something
other than 'origin'
Also, remember to make GIT_SVN_DIR whenever we need to create
.rev_db
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tested on a plain Ubuntu Warty installation
using subversion 1.0.6-1.2ubuntu3
svn add --force was never needed, as it only affected
directories, which git (thankfully) doesn't track
The 1.0.x also didn't support symlinks(!), so allow NO_SYMLINK
to be defined for running tests
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Revisions with long commit messages were being skipped, since
the 'git-svn-id' metadata line was at the end and git-log uses a
32k buffer to print the commits.
Also the last 'git-svn-id' metadata line in a commit is always
the valid one, so make sure we use that, as well.
Made the verbose flag work by passing the correct option switch
('--summary') to git-log.
Finally, optimize -r/--revision argument handling by passing
the appropriate limits to revision
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This means we'll have a loose object when we encounter a symlink
but that's not the common case.
We also don't have to worry about svn:eol-style when using the
SVN libraries, either. So remove the code to deal with that.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Share the repack counter between branches when doing
multi-fetch.
Pass the -d flag to git repack by default. That's the
main reason we will want automatic pack generation, to
save space and improve disk cache performance. I won't
add -a by default since it can generate extremely large
packs that make RAM-starved systems unhappy.
We no longer generate the .git/svn/$GIT_SVN_ID/info/uuid
file, either. It was never read in the first place.
Check for and create .rev_db if we need to during fetch (in case
somebody manually blew away their .rev_db and wanted to start
over. Mainly makes debugging easier).
Croak with $? instead of $! if there's an error closing pipes
Quiet down some of the chatter, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
repo_path_split() is already pretty fast, and is already
optimized via caching.
We also don't need to create an exclude file if we're
relying on the SVN libraries.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is a very intrusive change, so I've beefed up the tests
significantly. Added 'full-test' a target to the Makefile,
to test different possible configurations. This is intended
for maintainers only. Users should only be concerned with
'test' succeeding.
We now have a very simple custom database format for handling
mapping of svn revisions => git commits. Of course, we're
not really using it yet, either.
Also disabled automatic branch-finding on new trees for now.
It's too easily broken. revisions_eq() function should be
helpful for branch detection.
Also removed an extra assertion in fetch_cmd() that wasn't
correctly done. This bug was found by full-test.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This means we no longer have to deal with having bloated SVN
working copies around and we get a nice performance increase as
well because we don't have to exec the SVN binary and start a
new server connection each time.
Of course we have to manually manage memory with SVN::Pool
whenever we can, and hack around cases where SVN just eats
memory despite pools (I blame Perl, too). I would like to
keep memory usage as stable as possible during long fetch/commit
processes since I still use computers with only 256-512M RAM.
commit should always be faster with the SVN library code. The
SVN::Delta interface is leaky (or I'm not using it with pools
correctly), so I'm forking on every commit, but that doesn't
seem to hurt performance too much (at least on normal Unix/Linux
systems where fork() is pretty cheap).
fetch should be faster in most common cases, but probably not all.
fetches will be faster where client/server delta generation is
the bottleneck and not bandwidth. Of course, full-files are
generated server-side via deltas, too. Full files are always
transferred when they're updated, just like git-svnimport and
unlike command-line svn. I'm also hacking around memory leaks
(see comments) here by using some more forks.
I've tested fetch with http://, https://, file://, and svn://
repositories, so we should be reasonably covered in terms of
error handling for fetching.
Of course, we'll keep plain command-line svn compatibility as a
fallback for people running SVN 1.1 (I'm looking into library
support for 1.1.x SVN, too). If you want to force command-line
SVN usage, set GIT_SVN_NO_LIB=1 in your environment.
We also require two simultaneous connections (just like
git-svnimport), but this shouldn't be a problem for most
servers.
Less important commands:
show-ignore is slower because it requires repository
access, but -r/--revision <num> can be specified.
graft-branches may use more memory, but it's a
short-term process and is funky-filename-safe.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This quick feature should make it easy to look up svn log
messages when svn users refer to -r/--revision numbers.
The following features from `svn log' are supported:
--revision=<n>[:<n>] - is supported, non-numeric args are not:
HEAD, NEXT, BASE, PREV, etc ...
-v/--verbose - just maps to --raw (in git log), so
it's completely incompatible with
the --verbose output in svn log
--limit=<n> - is NOT the same as --max-count,
doesn't count merged/excluded commits
--incremental - supported (trivial :P)
New features:
--show-commit - shows the git commit sha1, as well
--oneline - our version of --pretty=oneline
Any other arguments are passed directly to `git log'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
New commands:
graft-branches - The most interesting command of the bunch. It
detects branches in SVN via various techniques (currently
regexes and file copies). It can be later extended to handle
svk and other properties people may use to track merges in svk.
Basically, merge tracking is not standardized at all in the SVN
world, and git grafts are perfect for dealing with this
situation.
Existing branch support (via tree matches) is only handled at
fetch time.
The following tow were originally implemented as shell scripts
several months ago, but I just decided to streamline things a
bit and added them to the main script.
multi-init - supports git-svnimport-like command-line syntax for
importing repositories that are layed out as recommended by the
SVN folks. This is a bit more tolerant than the git-svnimport
command-line syntax and doesn't require the user to figure out
where the repository URL ends and where the repository path
begins.
multi-fetch - runs fetch on all known SVN branches we're
tracking. This will NOT discover new branches (unlike
git-svnimport), so multi-init will need to be re-run (it's
idempotent).
Consider these three to be auxilliary commands (like
show-ignore, and rebuild) so their behavior won't receive as
much testing or scrutiny as the core commands (fetch and
commit).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This should help keep disk usage sane for large imports.
--repack takes an optional argument for the interval, it
defaults to 1000 if no argument is specified.
Arguments to --repack-flags are passed directly to git-repack.
No arguments are passed by default.
Idea stolen from git-cvsimport :)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
While we're at it, read_repo_config has been added and
expanded to handle case where command-line arguments are
optional to Getopt::Long
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since GIT_SVN_ID usage is probably going to become more
widespread <evil grin>, we won't run the chance of somebody
having a GIT_SVN_ID name that conflicts with one of the default
directories that already exist in $GIT_DIR (branches/tags).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Sometimes I don't feel like downloading an entire tree again when
I actually decide a branch is worth tracking, so some users can
get around it more easily with this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
By breaking the pipe read once we've seen a commit twice.
This should make -B/--branch-all-ref faster and usable on a
frequent basis.
We use topological order now for calling git-rev-list, and any
commit we've seen before should imply that all parents have been
seen (at least I hope that's the case for --topo-order).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This should make life easier for all those who type:
`git-rev-parse --symbolic --all | xargs -n1 echo -b`
every time they run git-svn fetch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If new revisions are fetched, that implies we haven't merged,
acked, or nacked them yet, and attempting to write the tree
we're committing means we'd silently clobber the newly fetched
changes.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn forces UTF-8 for commit messages, and with LC_ALL set to 'C'
it is unable to determine encoding of the git commit message.
Now we'll just assume the user has set LC_* correctly for
the commit message they're using.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If we read the maximum size of our buffer into $buf, and the
last character is '\015', there's a chance that the character is
'\012', which means our regex won't work correctly. At the
worst case, this could introduce an extra newline into the code.
We'll now read an extra character if we see '\015' is the last
character in $buf.
We also forgot to recalculate the length of $buf after doing the
newline substitution, causing some files to appeare truncated.
We'll do that now and force byte semantics in length() for good
measure.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn has trouble parsing files with embedded '@' characters. For
example,
svn propget svn:keywords foo@bar.c
svn: Syntax error parsing revision 'bar.c'
I asked about this on #svn and the workaround suggested was to append
an explicit revision specifier:
svn propget svn:keywords foo@bar.c@BASE
This patch appends '@BASE' to the filename in all calls to 'svn
propget'.
Patch originally by Seth Falcon <sethfalcon@gmail.com>
Seth: signoff?
[ew: Made to work with older svn that don't support peg revisions]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Some changes to the latest git.git made this test croak. So
we'll always just force everything when using a new branch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn < 1.3.x would display changes to keywords lines as modified
if they aren't expanded in the working copy. We already check
for changes against the git tree here, so checking against the
svn one is probably excessive.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The dash installed on my Debian Sarge boxes don't seem to like
<<'' as a heredoc starter. Recent versions of dash do not need
this fix.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unlike my earlier test patch, this also checks svn:eol-style and
makes sure it's applied to working copy updates. This is
definitely more correct than my original attempt at killing
keyword expansions, but I still haven't tested it enough to
know. Feedback would be much appreciated.
Also changed assert_svn_wc_clean() to only work on the svn
working copy. This requires a separate call to assert_tree() to
check wc integrity against git in preparation for another change
I'm planning.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Clarify that 'init' requires an argument
* Remove instances of 'SVN_URL' in the manpage, it's not an
environment variable.
* Refer to 'Additional Fetch Arguments' when documenting 'fetch'
* document --authors-file / -A option
Thanks to Pavel Roskin and Seth Falcon for bringing these issues
to my attention.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use this tool to rewrite the .git/remotes/* files into the config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I hacked it up to teach it the git extended diff headers, made
it not to read the whole patch in the array.
Also, the original program, when arguments are given, ran "diff"
with the given arguments and showed the output from it. Of
course, I changed it to run "git diff" ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Bugs like the last one could've been avoided if it weren't for
this...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fetching from repos without an authors-file defined was broken.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn/git-svn.txt:
added git-repo-config key names for options
fixed quoting of "git-svn-HEAD" in the manpage
use preformatted text for examples
contrib/git-svn/Makefile:
add target to generate HTML:
http://git-svn.yhbt.net/git-svn.html
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
repo-config keys are any of the long option names minus the '-'
characters
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We chdir internally, so we need a consistent GIT_DIR variable.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We should be safely able to import histories with thousands
of revisions without hogging up lots of memory.
With this, we lose the ability to autocorrect mistakes when
people specify revisions in reverse, but it's probably no longer
a problem since we only have one method of log parsing nowadays.
I've added an extra check to ensure that revision numbers do
increment.
Also, increment the version number to 0.11.0. I really should
just call it 1.0 soon...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-diff-file-merge-head generates a diff against the first merge
head, or with a prefix argument against the nth head. Bound to `d h'
by default.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If user name or email are not set explicitly, get them from the
user.name and user.email configuration values before falling back to
the Emacs defaults.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure that functions that call a git process and return a string
always return nil when the subprocess failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It's only for repositories that were imported with very early
versions of git-svn. Unfortunately, some of those repos are out
in the wild already, so fix this warning.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Output a big warning if somebody actually has a pre-1.0 version
of svn that doesn't support it.
Thanks to Yann Dirson for reminding me it still existed
and attempting to re-enable it :)
I think I subconciously removed support for it earlier...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
'svn info' doesn't work with URLs in svn <= 1.1. Now we
only run svn info in local directories.
As a side effect, this should also work better for 'init' off
directories that are no longer in the latest revision of the
repository.
svn checkout -r<revision> arguments are fixed.
Newer versions of svn (1.2.x) seem to need URL@REV as well as
-rREV to checkout a particular revision...
Add an example in the manpage of how to track directory that has
been moved since its initial revision.
A huge thanks to Yann Dirson for the bug reporting and testing
my original patch. Thanks also to Junio C Hamano for suggesting
a safer way to use git-rev-parse.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If `git-append-signed-off-by' is non-nil, automatically append a
sign-off line to the log message when editing it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update .gitignore files in the status list as they are created or
modified.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also set the list-buffers-directory variable for nicer buffer list
display.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fixed octal constants for XEmacs.
Added highlighting support in log-edit buffer for Emacs CVS.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a basic Emacs VC backend. It currently supports the following
commands: checkin, checkout, diff, log, revert, and annotate. There is
only limited support for working with revisions other than HEAD.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I thought passing --stop-on-copy to svn would save us from all
the trouble svn-arch-mirror had with directory (project) copies.
I was wrong, there was one thing I overlooked.
If a tree was moved from /foo/trunk to /bar/foo/trunk with no
other changes in r10, but the last change was done in r5, the
Last Changed Rev (from svn info) in /bar/foo/trunk will still be
r5, even though the copy in the repository didn't exist until
r10.
Now, if we ever detect that the Last Changed Rev isn't what
we're expecting, we'll run svn diff and only croak if there are
differences between them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I ended up using GIT_SVN_ID far more than I ever thought I
would. Typing less is good.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If it does change, we're screwed anyways as SVN will refuse to
commit or update. We also never access more than one SVN
repository per-invocation, so we can store it as a global, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a new repository, the initial fetch creates a master branch
if one does not exist so HEAD has something to point to.
It now creates a master at the end of the initial fetch run,
pointing to the latest revision. Previously it pointed to the
first revision imported, which is generally less useful.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Syntax is compatible with git-svnimport and git-cvsimport:
normalperson = Eric Wong <normalperson@yhbt.net>
If this option is specified and git-svn encounters an SVN
committer name that it cannot parse, it git-svn will abort.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We regenerate and use git-svn-id: whenever we fetch or otherwise
commit to remotes/git-svn. We don't actually know what revision
number we'll commit to SVN at commit time, so this is useless.
It won't throw off things like 'rebuild', though, which knows to
only use the last instance of git-svn-id: in a log message
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fixed manually-edited commit messages not going to
remotes/git-svn on sequential commits after the sequential
commit optimization.
* format help correctly after adding 'show-ignore'
* sha1_short regexp matches down to 4 hex characters
(from git-rev-parse --short documentation)
* Print the first line of the commit message when we commit to
SVN next to the sha1.
* Document 'T' (type change) in the comments
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've said I don't like branches in Subversion, and I still don't.
This is a bit more flexible, though, as the argument for -b is any
arbitrary git head/tag reference.
This makes some things easier:
* Importing git history into a brand new SVN branch.
* Tracking multiple SVN branches via GIT_SVN_ID, even from multiple
repositories.
* Adding tags from SVN (still need to use GIT_SVN_ID, though).
* Even merge tracking is supported, if and only the heads end up with
100% equivalent tree objects. This is more stricter but more robust
and foolproof than parsing commit messages, imho.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In our last update to use the encoding while showing the commit
diff we added a new argument to this function. But we missed
updating all the callers.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After reading a lengthy discussion on the list, I've come to the
conclusion that creating a 'remotes' directory in refs isn't
such a bad idea.
You can still branch from it by specifying remotes/git-svn (not
needing the leading 'refs/'), and the documentation has been
updated to reflect that.
The 'git-svn' part of the ref can of course be set to whatever
you want by using the GIT_SVN_ID environment variable, as
before.
I'm using refs/remotes/git-svn, and not going with something
like refs/remotes/git-svn/HEAD as it's redundant for Subversion
where there's zero distinction between branches and directories.
Run git-svn rebuild --upgrade to upgrade your repository to use
the new head. git-svn-HEAD must be manually deleted for safety
reasons.
Side note: if you ever (and I hope you never) want to run
git-update-refs on a 'remotes/' ref, make sure you have the
'refs/' prefix as you don't want to be clobbering your
'remotes/' in $GIT_DIR (where remote URLs are stored).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we set up the window to never scroll
horizontally, which made it harder to use on a narrow screen.
This patch allows scrollbar to be used as needed by Gtk
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Thanks to Nicolas Vilz <niv@iaglans.de> for noticing this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As a rule, interface branches to different SCMs should never be modified
directly by the user. They are used exclusively for talking to the
foreign SCM.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Get the encoding information from repository and convert it to utf-8 before
passing to gtk.TextBuffer.set_text. gtk.TextBuffer.set_text work only with utf-8
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
New features deserve an increment of the minor version. This will very
likely become 1.0.0 unless release-critical bugs are found.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Avoid running 'svn up' to a previous revision if we know the
revision we just committed is the first descendant of the
revision we came from.
This reduces the time to do a series of commits by about 25%.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to the
$GIT_DIR/info/exclude file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fix all the known issue with the graph display
The bug need to be explained graphically
|
a
This line need not be there ---->| \
b |
| /
c
c is parent of a and all a,b and c are placed on the same line and b is child of c
With my last checkin I added a seperate line to indicate that a is
connected to c. But then we had the line connecting a and b which should
not be ther. This changes fixes the same bug
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rearrange the code little bit so that it is easier to read
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since i wanted to limit the graph box size i was resetting
the window after an index of 5. This result in line joining
commit nodes to pass over nodes which are not related. The
changes fixes the same
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch address the below:
Use monospace font to draw branch and tag name
set the font size to 13.
Make the graph column resizable. This helps to accommodate large tag names
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fix the below bug
Junio C Hamano <junkio@cox.net> writes:
>
> It does not work in my repository, since you do not seem to
> handle branch and tag names with slashes in them. All of my
> topic branches live in directories with two-letter names
> (e.g. ak/gitview).
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
None of these were really show-stoppers (or even triggered)
on most of the trees I've tracked.
* Node change prevention for identically named nodes. This is
a limitation of SVN, but we find the error and exit before
it's passed to SVN so we don't dirty our working tree when our
commit fails. git-svn will exit with an error code 1 if any
of the following conditions are found:
1. a directory is removed and a file of the same name of the
removed directory is created
1a. a file has its parent directory removed and the file is
takes the name of the removed parent directory::
baz/zzz => baz
2. a file is removed and a directory of the same name of the
removed file is created.
2a. a file is moved into a deeper directory that shares the
previous name of the file::
dir/$file => dir/file/$file
Since SVN cannot handle these cases, the user will have to
manually split the commit into several parts.
* --rmdir now handles nested/deep removals. If dir/a/b/c/d/e/file
is removed, and everything else is in the dir/ hierarchy is
otherwise empty, then dir/ will be deleted when file is deleted
from svn and --rmdir specified.
* Always assert that we have written the tree we want to write
on commits. This helped me find several bugs in the symlink
handling code (which as been fixed).
* Several symlink handling fixes. We now refuse to set
permissions on symlinks. We also always unlink a file
if we're going to overwrite it.
* Apply changes in a pre-determined order, so we always have
rename from locations handy before we delete them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
XML::Simple was originally required back when I made svn-arch-mirror
because I needed to explictly track renames with Arch. Then I carried
it over to git-svn because I was afraid somebody could commit an svn
log message that could throw off a non-XML log parser. Then I noticed
the <n> lines column in the header. So, no more XML :)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow 'from..to' notation from the command line.
More liberal sha1 parsing when reading from stdin no longer requires the
sha1 to be the first character, so a leading 'commit ' string is OK.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both of these options are passed directly to git-diff-tree when
committing to a SVN repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just a typo, I doubt anybody would use (and I highly recommend not
using) this option anyways. But you never know...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is an Emacs interface for git. The user interface is modeled on
pcl-cvs. It has been developed on Emacs 21 and will probably need some
tweaking to work on XEmacs.
The basic command is 'M-x git-status' which displays a buffer listing
modified files in the selected project tree. In that buffer the
following features are supported:
- add/remove files
- list unknown files
- commit marked files
- manage .gitignore
- commit merges based on MERGE_HEAD
- revert files to the HEAD version
- resolve conflicts with smerge or ediff
- diff files against HEAD/base/mine/other or combined diff
- get a log of the revisions for specified files
There are plenty of unimplemented features too, see the TODO list at
the top of the file...
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes a bug when importing where a directory gets removed/renamed
but is immediately replaced by a file of the same name in the same
revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We run svn log against a URL without a working copy for the first fetch,
so we end up a log that's sorted from highest to lowest. That's bad, we
always want lowest to highest. Just default to --revision 0:HEAD now if
-r isn't specified for the first fetch.
Also sort the revisions after we get them just in case somebody
accidentally reverses the argument to --revision for whatever reason.
Thanks again to Emmanuel Guerin for helping me find this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
