When a single SVN repository is split into multiple Git repositories
many SVN revisions will exist in only one of the Git repositories
created. For some projects the only way to build a working artifact is
to check out corresponding versions of various repositories, with no
indication of what those are in the Git world - in the SVN world the
revision numbers are sufficient.
By adding "--before" to "git-svn find-rev" we can say "tell me what this
repository looked like when that other repository looked like this":
git svn find-rev --before \
r$(git --git-dir=/over/there.git svn find-rev HEAD)
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --log-window-size parameter to git-svn fetch is undocumented.
Minimally describe what it does and why the user might change it.
Signed-off-by: Gunnlaugur Þór Briem <gunnlaugur@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
The documentation of the dcommit subcommand is reworded to clarify that
the optional argument refers to a git branch, not an SVN branch.
The discussion of the optional argument is put into its own paragraph
as is the guidance about using 'dcommit' in preference to 'set-tree'.
The section on REBASE vs. PULL/MERGE is reworded to incorporate the
advice to prefer 'git rebase' previously in the description of 'dcommit'.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When git svn rebase is performed after an unpushed merge, the
rebase operation follows both parents and replays both the user's
local commits and those from the merged branch. This is usually
not the intended behavior.
This patch adds support for the --preserve-merges/-p flag which
allows for a better workflow by re-applying merge commits as merges.
[ew: fixed a minor syntax error]
Signed-off-by: Avishay Lavie <avishay.lavie@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Allow the user to check the patch set before it is commited to SVN. It is
then possible to accept/discard one patch, accept all, or quit.
This interactive mode is similar with 'git send email' behaviour. However,
'git svn dcommit' returns as soon as one patch is discarded.
Part of the code was taken from git-send-email.perl (see 'ask' function)
Tests several combinations of potential answers to
'git svn dcommit --interactive'. For each of them, test whether patches
were commited to SVN or not.
Thanks-to Eric Wong <normalperson@yhbt.net> for the initial idea.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
The git term is 'working tree', so replace the most public references
to 'working copy'.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow git-svn to populate the svn:mergeinfo property automatically in
a narrow range of circumstances. Specifically, when dcommitting a
revision with multiple parents, all but (potentially) the first of
which have been committed to SVN in the same repository as the target
of the dcommit.
In this case, the merge info is the union of that given by each of the
parents, plus all changes introduced to the first parent by the other
parents.
In all other cases where a revision to be committed has multiple
parents, cause "git svn dcommit" to raise an error rather than
completing the commit and potentially losing history information in
the upstream SVN repository.
This behavior is disabled by default, and can be enabled by setting
the svn.pushmergeinfo config option.
[ew: minor style changes and manpage merge fix]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Bryan Jacobs <bjacobs@woti.com>
"svn dcommit --mergeinfo" replaces the svn:mergeinfo property in an
upstream SVN repository with the given text. The svn:mergeinfo
property may contain commits originating on multiple branches,
separated by newlines.
Cause space characters in the mergeinfo to be replaced by newlines,
allowing a user to create history representing multiple branches being
merged into one.
Update the corresponding documentation and add a test for the new
functionality.
Signed-off-by: Bryan Jacobs <bjacobs@woti.com>
Acked-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Adds a --preserve-empty-dirs flag to the clone operation that will detect
empty directories in the remote Subversion repository and create placeholder
files in the corresponding local Git directories. This allows "empty"
directories to exist in the history of a Git repository.
Also adds the --placeholder-file flag to control the name of any placeholder
files created. Default value is ".gitignore".
Signed-off-by: Ray Chen <rchen@cs.umd.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
The SYNOPSIS sections of most commands that span several lines already
use [verse] to retain line breaks. Most commands that don't span
several lines seem not to use [verse]. In the HTML output, [verse]
does not only preserve line breaks, but also makes the section
indented, which causes a slight inconsistency between commands that
use [verse] and those that don't. Use [verse] in all SYNOPSIS sections
for consistency.
Also remove the blank lines from git-fetch.txt and git-rebase.txt to
align with the other man pages. In the case of git-rebase.txt, which
already uses [verse], the blank line makes the [verse] not apply to
the last line, so removing the blank line also makes the formatting
within the document more consistent.
While at it, add single quotes to 'git cvsimport' for consistency with
other commands.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark subcommand names as 'subcommand' to make them stand out.
Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options '---use-log-author' and '--add-author-from' are applicable to other
subcommands except 'fetch' -- therefore move them from the 'fetch' section to
the more general 'options' section.
Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option '--add-author-from' is used in 'commit-diff', 'set-tree', and
'dcommit' subcommands.
Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)
introduced the --mergeinfo option. Document it.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Similar to the 'remote.<name>.pushurl' config key for git remotes,
'pushurl' is designed to be used in cases where 'url' points to an SVN
repository via a read-only transport, to provide an alternate
read/write transport. It is assumed that both keys point to the same
repository.
The 'pushurl' key is distinct from the 'commiturl' key in that
'commiturl' is a full svn path while 'pushurl' (like 'url') is a base
path. 'commiturl' takes precendece over 'pushurl' in cases where
either might be used.
The 'pushurl' is used by git-svn's dcommit and branch commands.
Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Reviewed-by: James Y Knight <jknight@itasoftware.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
"git svn mkdirs" (which creates empty directories in the current
working copy) can be very slow and is often unnecessary. Provide a
config file option "svn-remote.<name>.automkdirs" that prevents empty
directories from being created automatically. (They are still created
if "git svn mkdirs" is invoked explicitly.)
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of these sections is generally to:
1. Give credit where it is due.
2. Give the reader an idea of where to ask questions or
file bug reports.
But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame. For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody
useless.
So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.
Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.
Leaving uppercase abbreviations (e.g. URL) and an identifier named after
an upercase env variable (CVSROOT) in place, this adjusts the few
remaining cases and fixes an unidentified identifier along the way.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git-remote add' creates a remote.origin.fetch entry in the config, we
want to replace this entry rather than add another one (which will
cause 'git fetch' to error).
This adds 'git config --remove-section remote.origin' after the fetch
for encouraging users to only use "git svn" for future updates.
[ew: rewording of commit message for present tense]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: StephenB <mail4stb@gmail.com>
Remove some stray usage of other bracket types and asterisks for the
same purpose.
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"noMetadata" is a sometimes harmful option, so better document
its behavior and limitations.
Suggested-by: Vadim Zeitlin
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Introduce a new option 'svn.pathnameencoding' that instructs git svn to
recode pathnames to a given encoding. It can be used by windows users
and by those who work in non-utf8 locales to avoid corrupted file names
with non-ascii characters.
[rp: renamed the option and added manpage documentation]
Signed-off-by: Dmitry Statyvka <dstatyvka@tmsoft-ltd.kiev.ua>
Signed-off-by: Robert Pollak <robert.pollak@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Use the definite article when talking about a configuration property.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
For very large projects it is useful to be able to clone a subset of the
upstream SVN repo's branches. Allow for this by letting the left-side of
the branches and tags glob specs contain a brace-delineated comma-separated
list of names. e.g.:
branches = branches/{red,green}/src:refs/remotes/branches/*
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
In certain situations it may be necessary to manually remap an svn
repostitory UUID. For example:
o--- [git-svn clone]
/
[origin svn repo]
\
o--- [svnsync clone]
Imagine that only "git-svn clone" and "svnsync clone" are made available
to external users. Furthur, "git-svn clone" contains only trunk, and for
reasons unknown, "svnsync clone" is missing the revision properties that
normally provide the origin svn repo's UUID.
A git user who has cloned the "git-svn clone" repo now wishes to use
git-svn to pull in the missing branches from the "synsync clone" repo.
In order for git-svn to get the history correct for those branches,
it needs to know the origin svn repo's UUID. Hence rewriteUUID.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn has the following rule to detect the SVN base for its
operations: find the first git-svn-id line reachable through
first-parent ancestry. IOW,
git log --grep=^git-svn-id: --first-parent -1
Document this, as it is very important when using merges with git-svn.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
We parse unhandled.log files for empty_dir statements and make a
best effort attempt to recreate empty directories on fresh
clones and rebase. This should cover the majority of cases
where users work off a single branch or for projects where
branches do not differ in empty directories.
Since this cannot affect "normal" git commands like "checkout"
or "reset", so users switching between branches in a single
working directory should use the new "git svn mkdirs" command
after switching branches.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The note about interoperating in different timezones and such is about
localtime argument, not parent.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
This reverts the --minimize-url behavior change that
appeared recently in commit 0b2af457a4
("Fix branch detection when repository root is inaccessible").
However, we now allow the option to be turned off by allowing
"--no-minimize-url" so people with limited-access setups can
still take advantage of the fix in
0b2af457a4.
Also document the behavior and default settings of minimize-url
in the manpage for the first time.
This introduces a temporary UI regression to allow t9141 to pass
that will be reverted (fixed) in the next commit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Add a git svn gc command that gzips all unhandled.log files, and
removes all index files under .git/svn.
Signed-off-by: Robert Allan Zeh <robert.a.zeh@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
- correctly link paragraphs within list items
- consistently format examples
- put option alernatives on separate lines
- always use [verse] for config items
- always indent 1st paragraph of a list item, with a tab
Signed-off-by: Yann Dirson <ydirson@altern.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also consistently use single quotes around git commands to make things clear
(was only needed at a couple of places).
Signed-off-by: Yann Dirson <ydirson@altern.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a command to unwind the effects of fetch by moving the rev_map
and refs/remotes/git-svn back to an old SVN revision. This allows
revisions to be re-fetched. Ideally SVN revs would be immutable,
but permissions changes in the SVN repository or indiscriminate use
of '--ignore-paths' can create situations where fetch cannot make
progress.
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
'git svn dcommit' takes an optional revision argument, but the meaning
of it was rather scary. It completely ignored the current state of
the HEAD, only looking at the revisions between SVN and $rev. If HEAD
was attached to $branch, the branch lost all commits $rev..$branch in
the process.
Considering that 'git svn dcommit HEAD^' has the intuitive meaning
"dcommit all changes on my branch except the last one", we change the
meaning of the revision argument. git-svn temporarily checks out $rev
for its work, meaning that
* if a branch is specified, that branch (_not_ the HEAD) is rebased as
part of the dcommit,
* if some other revision is specified, as in the example, all work
happens on a detached HEAD and no branch is affected.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
