hgignore(5) [centos man page]

HGIGNORE(5)							 Mercurial Manual						       HGIGNORE(5)

NAME

       hgignore - syntax for Mercurial ignore files

SYNOPSIS

       The  Mercurial system uses a file called .hgignore in the root directory of a repository to control its behavior when it searches for files
       that it is not currently tracking.

DESCRIPTION

       The working directory of a Mercurial repository will often contain files that should not be tracked  by	Mercurial.  These  include  backup
       files  created  by  editors and build products created by compilers.  These files can be ignored by listing them in a .hgignore file in the
       root of the working directory. The .hgignore file must be created manually. It is typically put under version control, so that the settings
       will propagate to other repositories with push and pull.

       An untracked file is ignored if its path relative to the repository root directory, or any prefix path of that path, is matched against any
       pattern in .hgignore.

       For example, say we have an untracked file, file.c, at a/b/file.c inside our repository. Mercurial will ignore file.c  if  any  pattern	in
       .hgignore matches a/b/file.c, a/b or a.

       In addition, a Mercurial configuration file can reference a set of per-user or global ignore files. See the ignore configuration key on the
       [ui] section of hg help config for details of how to configure these files.

       To control Mercurial's handling of files that it manages, many commands support the -I and -X options; see hg help  <command> and  hg  help
       patterns for details.

       Files that are already tracked are not affected by .hgignore, even if they appear in .hgignore. An untracked file X can be explicitly added
       with hg add X, even if X would be excluded by a pattern in .hgignore.

SYNTAX

       An ignore file is a plain text file consisting of a list of patterns, with one pattern per line. Empty lines are skipped. The  #  character
       is treated as a comment character, and the  character is treated as an escape character.

       Mercurial supports several pattern syntaxes. The default syntax used is Python/Perl-style regular expressions.

       To change the syntax used, use a line of the following form:

       syntax: NAME

       where NAME is one of the following:

       regexp

	      Regular expression, Python/Perl syntax.

       glob

	      Shell-style glob.

       The chosen syntax stays in effect when parsing all patterns that follow, until another syntax is selected.

       Neither	glob  nor regexp patterns are rooted. A glob-syntax pattern of the form *.c will match a file ending in .c in any directory, and a
       regexp pattern of the form .c$ will do the same. To root a regexp pattern, start it with ^.

       Note   Patterns specified in other than .hgignore are always rooted.  Please see hg help patterns for details.

EXAMPLE

       Here is an example ignore file.

       # use glob syntax.
       syntax: glob

       *.elc
       *.pyc
       *~

       # switch to regexp syntax.
       syntax: regexp
       ^.pc/

AUTHOR

       Vadim Gelfer <vadim.gelfer@gmail.com>

       Mercurial was written by Matt Mackall <mpm@selenic.com>.

SEE ALSO

       hg(1), hgrc(5)

COPYING

       This manual page is copyright 2006 Vadim Gelfer.  Mercurial is copyright 2005-2012 Matt Mackall.  Free use  of  this  software  is  granted
       under the terms of the GNU General Public License version 2 or any later version.

AUTHOR

       Vadim Gelfer <vadim.gelfer@gmail.com>

       Organization: Mercurial

																       HGIGNORE(5)

GO-REMOTE(7)						 Miscellaneous Information Manual					      GO-REMOTE(7)

NAME

       go - tool for managing Go source code

DESCRIPTION

       An  import path (see go-importpath(1)) denotes a package stored in the local file system.  Certain import paths also describe how to obtain
       the source code for the package using a revision control system.

       A few common code hosting sites have special syntax:

       BitBucket (Mercurial)
	      import "bitbucket.org/user/project"
	      import "bitbucket.org/user/project/sub/directory"

       GitHub (Git)
	      import "github.com/user/project"
	      import "github.com/user/project/sub/directory"

       Google Code Project Hosting (Git, Mercurial, Subversion)
	      import "code.google.com/p/project"
	      import "code.google.com/p/project/sub/directory"

	      import "code.google.com/p/project.subrepository"
	      import "code.google.com/p/project.subrepository/sub/directory"

       Launchpad (Bazaar)

	      import "launchpad.net/project"
	      import "launchpad.net/project/series"
	      import "launchpad.net/project/series/sub/directory"

	      import "launchpad.net/~user/project/branch"
	      import "launchpad.net/~user/project/branch/sub/directory"

       For code hosted on other servers, import paths may either be qualified with the version control type, or the go tool can dynamically  fetch
       the import path over https/http and discover where the code resides from a <meta> tag in the HTML.

       To declare the code location, an import path of the form

	   repository.vcs/path

       specifies  the  given  repository,  with  or without the .vcs suffix, using the named version control system, and then the path inside that
       repository.  The supported version control systems are:

       Bazaar
	       .bzr

       Git
	       .git

       Mercurial
	       .hg

       Subversion
	       .svn

       For example,

	   import "example.org/user/foo.hg"

       denotes the root directory of the Mercurial repository at example.org/user/foo or foo.hg, and

	   import "example.org/repo.git/foo/bar"

       denotes the foo/bar directory of the Git repository at example.com/repo or repo.git.

       When a version control system supports multiple protocols, each is tried in turn when downloading.   For  example,  a  Git  download  tries
       git://, then https://, then http://.

       If  the	import	path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import
       over https/http and looks for a <meta> tag in the document's HTML <head>.

       The meta tag has the form:

	   <meta name="go-import" content="import-prefix vcs repo-root">

       The import-prefix is the import path corresponding to the repository root. It must be a prefix or an  exact  match  of  the  package  being
       fetched with "go get". If it's not an exact match, another http request is made at the prefix to verify the <meta> tags match.

       The vcs is one of "git", "hg", "svn", etc,

       The repo-root is the root of the version control system containing a scheme and not containing a .vcs qualifier.

       For example,

	   import "example.org/pkg/foo"

       will result in the following request(s):

	   https://example.org/pkg/foo?go-get=1 (preferred)
	   http://example.org/pkg/foo?go-get=1	(fallback)

       If that page contains the meta tag

	   <meta name="go-import" content="example.org git https://code.org/r/p/exproj">

       the  go	tool will verify that https://example.org/?go-get=1 contains the same meta tag and then git clone https://code.org/r/p/exproj into
       GOPATH/src/example.org.

       New downloaded packages are written to the first directory listed in the GOPATH environment variable (see go-path(1)).

       The go command attempts to download the version of the package appropriate for the Go release being used.  See go-install(1) for more.

AUTHOR

       This manual page was written by Michael Stapelberg <stapelberg@debian.org>, for the Debian project (and may be used by others).

								    2012-05-13							      GO-REMOTE(7)