Various 'reset' optimizations and clean-ups, followed by a change
to allow "git reset" to work even on an unborn branch.
* mz/reset-misc:
reset: update documentation to require only tree-ish with paths
reset [--mixed]: use diff-based reset whether or not pathspec was given
reset: allow reset on unborn branch
reset $sha1 $pathspec: require $sha1 only to be treeish
reset.c: inline update_index_refresh()
reset.c: finish entire cmd_reset() whether or not pathspec is given
reset [--mixed]: only write index file once
reset.c: move lock, write and commit out of update_index_refresh()
reset.c: move update_index_refresh() call out of read_from_tree()
reset.c: replace switch by if-else
reset: avoid redundant error message
reset --keep: only write index file once
reset.c: share call to die_if_unmerged_cache()
reset.c: extract function for updating {ORIG_,}HEAD
reset.c: remove unnecessary variable 'i'
reset.c: extract function for parsing arguments
reset: don't allow "git reset -- $pathspec" in bare repo
reset.c: pass pathspec around instead of (prefix, argv) pair
reset $pathspec: exit with code 0 if successful
reset $pathspec: no need to discard index
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the timestamps may differ.
Any stat checking by git will then need to check content, which may
be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if they are set to zero in the index.
This change introduces a core.checkstat config option where the
the user can select to check all fields (default), or just size
and the whole second part of mtime (minimal).
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a configuration variable to set default clean-up mode other
than "strip".
* rt/commit-cleanup-config:
commit: make default of "cleanup" option configurable
Teach commands in the "log" family to optionally pay attention to
the mailmap.
* ap/log-mailmap:
log --use-mailmap: optimize for cases without --author/--committer search
log: add log.mailmap configuration option
log: grep author/committer using mailmap
test: add test for --use-mailmap option
log: add --use-mailmap option
pretty: use mailmap to display username and email
mailmap: add mailmap structure to rev_info and pp
mailmap: simplify map_user() interface
mailmap: remove email copy and length limitation
Use split_ident_line to parse author and committer
string-list: allow case-insensitive string list
* git://bogomips.org/git-svn:
git-svn: teach find-rev to find near matches
git svn: do not overescape URLs (fallback case)
Git::SVN::Editor::T: pass $deletions to ->A and ->D
In the precedence order, the environment variable $EMAIL comes
between the built-in default (i.e. taking value by asking the
system's gethostname() etc.) and the user.email configuration
variable; the documentation implied that it is stronger than the
configuration like $GIT_COMMITTER_EMAIL is, which is wrong.
* pe/doc-email-env-is-trumped-by-config:
git-commit-tree(1): correct description of defaults
Add support for a pre-push hook which can be used to determine if the
set of refs to be pushed is suitable for the target repository. The
hook is run with two arguments specifying the name and location of the
destination repository.
Information about what is to be pushed is provided by sending lines of
the following form to the hook's standard input:
<local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
If the hook exits with a non-zero status, the push will be aborted.
This will allow the script to determine if the push is acceptable based
on the target repository and branch(es), the commits which are to be
pushed, and even the source branches in some cases.
Signed-off-by: Aaron Schrab <aaron@schrab.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
When resetting with paths, we no longer require a commit argument, but
only a tree-ish. Update the documentation and synopsis accordingly.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users do want to write a line that begin with a pound sign, #,
in their commit log message. Many tracking system recognise
a token of #<bugid> form, for example.
The support we offer these use cases is not very friendly to the end
users. They have a choice between
- Don't do it. Avoid such a line by rewrapping or indenting; and
- Use --cleanup=whitespace but remove all the hint lines we add.
Give them a way to set a custom comment char, e.g.
$ git -c core.commentchar="%" commit
so that they do not have to do either of the two workarounds.
[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It finds its upstream and applies the commit properly, but
the sync step will fail unless it is told which branch to
work on.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is legal to sync a branch with a different name than
refs/remotes/p4/master, and to do so even when master does
not exist.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a clone or sync, --branch says where the newly imported
branch should go, or which existing branch to sync up. It
takes an argument, which is currently either something that
starts with "refs/", or if not, "refs/heads/p4" is prepended.
Putting it in heads seems like a bad default; these should
go in remotes/p4/ in most situations. Make that the new default,
and be more liberal in the form of the branch name.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that the example on how to use git-p4.branchList
works if typed directly. In particular, it does not make sense
to set a config variable until the git repository has been
initialized.
Reported-by: Olivier Delalleau <shish@keba.be>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the --branch argument to "git p4 clone", one
might specify a destination for p4 changes different from
the default refs/remotes/p4/master. Both cases should
create a master branch and checkout files.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The internal logic had to deal with two representations of a death
of a child process by a signal.
* jk/unify-exit-code-by-receiving-signal:
run-command: encode signal death as a positive integer
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
* jc/format-patch-reroll:
format-patch: give --reroll-count a short synonym -v
format-patch: document and test --reroll-count
format-patch: add --reroll-count=$N option
get_patch_filename(): split into two functions
get_patch_filename(): drop "just-numbers" hack
get_patch_filename(): simplify function signature
builtin/log.c: stop using global patch_suffix
builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
* jc/submittingpatches:
SubmittingPatches: give list and maintainer addresses
SubmittingPatches: remove overlong checklist
SubmittingPatches: mention subsystems with dedicated repositories
SubmittingPatches: who am I and who cares?
When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* jn/warn-on-inaccessible-loosen:
config: exit on error accessing any config file
doc: advertise GIT_CONFIG_NOSYSTEM
config: treat user and xdg config permission problems as errors
config, gitignore: failure to access with ENOTDIR is ok
--depth is explained as deepen, but the way it's applied, it can
shorten the history as well. Keen users may have noticed the
implication by the phrase "the specified number of commits from the
tip of each remote branch". Put "shorten" in the description to make
it clearer.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user can do --depth=2147483647 (*) for restoring complete repo
now. But it's hard to remember. Any other numbers larger than the
longest commit chain in the repository would also do, but some
guessing may be involved. Make easy-to-remember --unshallow an alias
for --depth=2147483647.
Make upload-pack recognize this special number as infinite depth. The
effect is essentially the same as before, except that upload-pack is
more efficient because it does not have to traverse to the bottom
anymore.
The chance of a user actually wanting exactly 2147483647 commits
depth, not infinite, on a repository with a history that long, is
probably too small to consider. The client can learn to add or
subtract one commit to avoid the special treatment when that actually
happens.
(*) This is the largest positive number a 32-bit signed integer can
contain. JGit and older C Git store depth as "int" so both are OK
with this number. Dulwich does not support shallow clone.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor and generally clean up the directory traversal API
implementation.
* as/dir-c-cleanup:
dir.c: rename free_excludes() to clear_exclude_list()
dir.c: refactor is_path_excluded()
dir.c: refactor is_excluded()
dir.c: refactor is_excluded_from_list()
dir.c: rename excluded() to is_excluded()
dir.c: rename excluded_from_list() to is_excluded_from_list()
dir.c: rename path_excluded() to is_path_excluded()
dir.c: rename cryptic 'which' variable to more consistent name
Improve documentation and comments regarding directory traversal API
api-directory-listing.txt: update to match code
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
* nd/wildmatch:
wildmatch: replace variable 'special' with better named ones
compat/fnmatch: respect NO_FNMATCH* even on glibc
wildmatch: fix "**" special case
t3070: Disable some failing fnmatch tests
test-wildmatch: avoid Windows path mangling
Support "**" wildcard in .gitignore and .gitattributes
wildmatch: make /**/ match zero or more directories
wildmatch: adjust "**" behavior
wildmatch: fix case-insensitive matching
wildmatch: remove static variable force_lower_case
wildmatch: make wildmatch's return value compatible with fnmatch
t3070: disable unreliable fnmatch tests
Integrate wildmatch to git
wildmatch: follow Git's coding convention
wildmatch: remove unnecessary functions
Import wildmatch from rsync
ctype: support iscntrl, ispunct, isxdigit and isprint
ctype: make sane_ctype[] const array
Conflicts:
Makefile
Teach "log.mailmap" configuration variable to turn "--use-mailmap"
option on to "git log", "git show" and "git whatchanged".
The "--no-use-mailmap" option from the command line can countermand
the setting.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the --use-mailmap option to log commands. It allows to display
names from mailmap file when displaying logs, whatever the format
used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default of the "cleanup" option in "git commit"
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option "commit.cleanup" which can be used
to change the default of the "cleanup" option in
"git commit".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old phrasing indicated that the EMAIL environment variable takes
precedence over the user.email configuration setting, but it is the
other way around.
Signed-off-by: Peter Eisentraut <peter@eisentraut.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options in git-fast-import(1) are not currently arranged in a
logical order, which has caused the '--done' options to be documented
twice (commit 3266de10).
Rearrange them into logical groups under subheadings.
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The descriptions of '--relative-marks' and '--no-relative-marks' make
more sense when read together instead of as two independent options.
Combine them into a single description block.
Signed-off-by: John Keeping <john@keeping.me.uk>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 00d3947 (Teach --wrap to only indent without wrapping) added
special behaviour for a width of zero in the '-w' argument to
'git-shortlog' but this was not documented. Fix this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach various forms of "format-patch" command line to identify what
branch the patches are taken from, so that the branch description
is picked up in more cases.
* nd/maint-branch-desc-doc:
format-patch: pick up branch description when no ref is specified
format-patch: pick up correct branch name from symbolic ref
t4014: a few more tests on cover letter using branch description
branch: delete branch description if it's empty
config.txt: a few lines about branch.<name>.description
Streamline the document and update with a few e-mail addresses the
patches should be sent to.
* jc/submittingpatches:
SubmittingPatches: give list and maintainer addresses
SubmittingPatches: remove overlong checklist
SubmittingPatches: mention subsystems with dedicated repositories
SubmittingPatches: who am I and who cares?
The '--done' option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Deal with a situation where .config/git is a file and we notice
.config/git/config is not readable due to ENOTDIR, not ENOENT.
* jn/warn-on-inaccessible-loosen:
config: exit on error accessing any config file
doc: advertise GIT_CONFIG_NOSYSTEM
config: treat user and xdg config permission problems as errors
config, gitignore: failure to access with ENOTDIR is ok
By the end of a directory traversal, a dir_struct instance will
typically contains pointers to various data structures on the heap.
clear_directory() provides a convenient way to reclaim that memory.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously each exclude_list could potentially contain patterns
from multiple sources. For example dir->exclude_list[EXC_FILE]
would typically contain patterns from .git/info/exclude and
core.excludesfile, and dir->exclude_list[EXC_DIRS] could contain
patterns from multiple per-directory .gitignore files during
directory traversal (i.e. when dir->exclude_stack was more than
one item deep).
We split these composite exclude_lists up into three groups of
exclude_lists (EXC_CMDL / EXC_DIRS / EXC_FILE as before), so that each
exclude_list now contains patterns from a single source. This will
allow us to cleanly track the origin of each pattern simply by adding
a src field to struct exclude_list, rather than to struct exclude,
which would make memory management of the source string tricky in the
EXC_DIRS case where its contents are dynamically generated.
Similarly, by moving the filebuf member from struct exclude_stack to
struct exclude_list, it allows us to track and subsequently free
memory buffers allocated during the parsing of all exclude files,
rather than only tracking buffers allocated for files in the EXC_DIRS
group.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation for the ALLOC_GROW API implicitly encouraged
developers to use "ary" as the variable name for the array which is
dynamically grown. However "ary" is an unusual abbreviation hardly
used anywhere else in the source tree, and it is also better to name
variables based on their contents not on their type.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When building manual pages, the source text is transformed to XML with
AsciiDoc before the man pages are generated from the XML with xmlto.
Fix the dependencies in the Makefile so that the XML files are rebuilt
when asciidoc.conf changes and not just the manual pages from
unchanged XML, and move the dependencies from a recipeless rule to the
rules with commands that use asciidoc.conf to make the dependencies
easier to understand and maintain.
Reported-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Tested-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a sub-command dies due to a signal, we encode the
signal number into the numeric exit status as "signal -
128". This is easy to identify (versus a regular positive
error code), and when cast to an unsigned integer (e.g., by
feeding it to exit), matches what a POSIX shell would return
when reporting a signal death in $? or through its own exit
code.
So we have a negative value inside the code, but once it
passes across an exit() barrier, it looks positive (and any
code we receive from a sub-shell will have the positive
form). E.g., death by SIGPIPE (signal 13) will look like
-115 to us in inside git, but will end up as 141 when we
call exit() with it. And a program killed by SIGPIPE but run
via the shell will come to us with an exit code of 141.
Unfortunately, this means that when the "use_shell" option
is set, we need to be on the lookout for _both_ forms. We
might or might not have actually invoked the shell (because
we optimize out some useless shell calls). If we didn't invoke
the shell, we will will see the sub-process's signal death
directly, and run-command converts it into a negative value.
But if we did invoke the shell, we will see the shell's
128+signal exit status. To be thorough, we would need to
check both, or cast the value to an unsigned char (after
checking that it is not -1, which is a magic error value).
Fortunately, most callsites do not care at all whether the
exit was from a code or from a signal; they merely check for
a non-zero status, and sometimes propagate the error via
exit(). But for the callers that do care, we can make life
slightly easier by just using the consistent positive form.
This actually fixes two minor bugs:
1. In launch_editor, we check whether the editor died from
SIGINT or SIGQUIT. But we checked only the negative
form, meaning that we would fail to notice a signal
death exit code which was propagated through the shell.
2. In handle_alias, we assume that a negative return value
from run_command means that errno tells us something
interesting (like a fork failure, or ENOENT).
Otherwise, we simply propagate the exit code. Negative
signal death codes confuse us, and we print a useless
"unable to run alias 'foo': Success" message. By
encoding signal deaths using the positive form, the
existing code just propagates it as it would a normal
non-zero exit code.
The downside is that callers of run_command can no longer
differentiate between a signal received directly by the
sub-process, and one propagated. However, no caller
currently cares, and since we already optimize out some
calls to the shell under the hood, that distinction is not
something that should be relied upon by callers.
Fix the same logic in t/test-terminal.perl for consistency [jc:
raised by Jonathan in the discussion].
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
* wk/submodule-update-remote:
submodule add: If --branch is given, record it in .gitmodules
submodule update: add --remote for submodule's upstream changes
submodule: add get_submodule_config helper funtion
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
* jk/pathspec-literal:
add global --literal-pathspecs option
Conflicts:
dir.c
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
* jc/format-color-auto:
log --format: teach %C(auto,black) to respect color config
t6006: clean up whitespace
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
* jk/mailmap-from-blob:
mailmap: default mailmap.blob in bare repositories
mailmap: fix some documentation loose-ends for mailmap.blob
mailmap: clean up read_mailmap error handling
mailmap: support reading mailmap from blobs
mailmap: refactor mailmap parsing for non-file sources
Require "-f" for push to update a tag, even if it is a fast-forward.
* cr/push-force-tag-update:
push: allow already-exists advice to be disabled
push: rename config variable for more general use
push: cleanup push rules comment
push: clarify rejection of update to non-commit-ish
push: require force for annotated tags
push: require force for refs under refs/tags/
push: flag updates that require force
push: keep track of "update" state separately
push: add advice for rejected tag reference
push: return reject reasons as a bitset
Various updates to fast-export used in the context of the remote
helper interface.
* fc/fast-export-fixes:
fast-export: make sure updated refs get updated
fast-export: don't handle uninteresting refs
fast-export: fix comparison in tests
fast-export: trivial cleanup
remote-testgit: implement the "done" feature manually
remote-testgit: report success after an import
remote-testgit: exercise more features
remote-testgit: cleanup tests
remote-testgit: remove irrelevant test
remote-testgit: remove non-local functionality
Add new simplified git-remote-testgit
Rename git-remote-testgit to git-remote-testpy
remote-helpers: fix failure message
remote-testgit: fix direction of marks
fast-export: avoid importing blob marks
Accept "-v" as a synonym to "--reroll-count", so that users can say
"git format-patch -v4 master", instead of having to fully spell it
out as "git format-patch --reroll-count=4 master".
As I do not think of a reason why users would want to tell the
command to be "verbose", I think this should be OK.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The flow described in the document is still correct, but over time I
have automated various parts of the workflow with tools and their
use was not explained at all.
Update it and outline the use of two key scripts from the 'todo'
branch, "Reintegrate" and "cook".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various fixes that have been cooking in 'next' have been merged. All
of them should go to 'maint' for 1.8.1.1 later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --graph code fell into infinite loop when asked to do what the
code did not expect.
* mk/maint-graph-infinity-loop:
graph.c: infinite loop in git whatchanged --graph -m
An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* mh/ceiling:
string_list_longest_prefix(): remove function
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
longest_ancestor_length(): require prefix list entries to be normalized
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): use string_list_split()
Introduce new function real_path_if_valid()
real_path_internal(): add comment explaining use of cwd
Introduce new static function real_path_internal()
We told readers to "send it to the list" (or the maintainer) without
telling what addresses are to be used. Correct this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The section is no longer a concise checklist. It also talks about
things that are not covered in the "Long version" text, which means
people need to read both, covering more or less the same thing in
different phrasing.
Fold the details into the main text and remove the section.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not necessarily every bundle file can be cloned from. Only the ones
that do not need prerequisites can.
When 1d52b02 (Documentation: minor grammatical fixes and rewording
in git-bundle.txt, 2009-03-22) reworded this paragraph, it lost a
critical hint to tell readers why this particular bundle can be
cloned from. Resurrect it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were only mentioned in periodical "A note from the maintainer"
posting and not in the documentation suite. SubmittingPatches has a
section to help contributors decide on what commit to base their
changes, which is the most suitable place for this information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The introductory text in the "long version" talks about the origin
of this document with "I started ...", but it is unclear who that I
is, and more importantly, it is not interesting how it was started.
Just state the purpose of the document to help readers decide if it
is releavant to them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because the bundle created in the example does not record HEAD, "git
clone" will not check out the files to the working tree:
$ git clone pr.bundle q/
Cloning into 'q'...
Receiving objects: 100% (619/619), 13.52 MiB | 18.74 MiB/s, done.
Resolving deltas: 100% (413/413), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
Avoid alarming the readers by adding "-b master" to the example. A
better fix may be to arrange the bundle created in the earlier step
to record HEAD, so that it can be cloned without this workaround.
Signed-off-by: Brilliantov Kirill Vladimirovich <brilliantov@inbox.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
traversal API has a few potentially confusing properties. These
comments clarify a few key aspects and will hopefully make it easier
to understand for other newcomers in the future.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
7c4c97c0ac turned the flags in struct dir_struct into a single bitfield
variable, but forgot to update this document.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The parsecvs code has been neglected for a long time, and the only
public version does not even build correctly. I have been handed
control of the project and intend to fix this, but until I do it
cannot be recommended.
Also, the project URL given for Subversion needed to be updated
to follow their site move.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
