* We used to allow committing a path ".Git/config" with Git that is
running on a case sensitive filesystem, but an attempt to check out
such a path with Git that runs on a case insensitive filesystem
would have clobbered ".git/config", which is definitely not what
the user would have expected. Git now prevents you from tracking
a path with ".Git" (in any case combination) as a path component.
* On Windows, certain path components that are different from ".git"
are mapped to ".git", e.g. "git~1/config" is treated as if it were
".git/config". HFS+ has a similar issue, where certain unicode
codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
it were ".git/config". Pathnames with these potential issues are
rejected on the affected systems. Git on systems that are not
affected by this issue (e.g. Linux) can also be configured to
reject them to ensure cross platform interoperability of the hosted
projects.
* "git fsck" notices a tree object that records such a path that can
be confused with ".git", and with receive.fsckObjects configuration
set to true, an attempt to "git push" such a tree object will be
rejected. Such a path may not be a problem on some filesystems
but in order to protect those on HFS+ and on case insensitive
filesystems, this check is enabled on all platforms.
A big "thanks!" for bringing this issue to us goes to our friends in
the Mercurial land, namely, Matt Mackall and Augie Fackler.
Also contains typofixes, documentation updates and trivial code clean-ups.
Changes since v2.2.0 are as follows:
Hartmut Henkel (1):
l10n: de.po: fix typos
Jeff King (8):
unpack-trees: propagate errors adding entries to the index
read-tree: add tests for confusing paths like ".." and ".git"
verify_dotfile(): reject .git case-insensitively
t1450: refactor ".", "..", and ".git" fsck tests
fsck: notice .git case-insensitively
utf8: add is_hfs_dotgit() helper
read-cache: optionally disallow HFS+ .git variants
fsck: complain about HFS+ ".git" aliases in trees
Johannes Schindelin (3):
path: add is_ntfs_dotgit() helper
read-cache: optionally disallow NTFS .git variants
fsck: complain about NTFS ".git" aliases in trees
Ports
* Building on older MacOS X systems automatically sets
the necessary NO_APPLE_COMMON_CRYPTO build-time option.
* Building with NO_PTHREADS has been resurrected.
* Compilation options have been updated a bit to better support the
z/OS port.
UI, Workflows & Features
* "git archive" learned to filter what gets archived with a pathspec.
* "git config --edit --global" starts from a skeletal per-user
configuration file contents, instead of a total blank, when the
user does not already have any global config. This immediately
reduces the need to later ask "Have you forgotten to set
core.user?", and we can add more to the template as we gain
more experience.
* "git stash list -p" used to be almost always a no-op because each
stash entry is represented as a merge commit. It learned to show
the difference between the base commit version and the working tree
version, which is in line with what "git stash show" gives.
* Sometimes users want to report a bug they experience on their
repository, but they are not at liberty to share the contents of
the repository. "fast-export" was taught an "--anonymize" option
to replace blob contents, names of people, paths and log
messages with bland and simple strings to help them.
* "git difftool" learned an option to stop feeding paths to the
diff backend when it exits with a non-zero status.
* "git grep" learned to paint (or not paint) partial matches on
context lines when showing "grep -C<num>" output in color.
* "log --date=iso" uses a slight variant of the ISO 8601 format that is
more human readable. A new "--date=iso-strict" option gives
datetime output that conforms more strictly.
* The logic "git prune" uses is more resilient against various corner
cases.
* A broken reimplementation of Git could write an invalid index that
records both stage 0 and higher-stage entries for the same path.
We now notice and reject such an index, as there is no sensible
fallback (we do not know if the broken tool wanted to resolve and
forgot to remove the higher-stage entries, or if it wanted to unresolve
and forgot to remove the stage 0 entry).
* The temporary files "git mergetool" uses are renamed to avoid too
many dots in them (e.g. a temporary file for "hello.c" used to be
named e.g. "hello.BASE.4321.c" but now uses underscore instead,
e.g. "hello_BASE_4321.c", to allow us to have multiple variants).
* The temporary files "git mergetool" uses can be placed in a newly
created temporary directory, instead of the current directory, by
setting the mergetool.writeToTemp configuration variable.
* "git mergetool" understands "--tool bc" now, as version 4 of
BeyondCompare can be driven the same way as its version 3 and it
feels awkward to say "--tool bc3" to run version 4.
* The "pre-receive" and "post-receive" hooks are no longer required
to consume their input fully (not following this requirement used
to result in intermittent errors in "git push").
* The pretty-format specifier "%d", which expands to " (tagname)"
for a tagged commit, gained a cousin "%D" that just gives the
"tagname" without frills.
* "git push" learned "--signed" push, that allows a push (i.e.
request to update the refs on the other side to point at a new
history, together with the transmission of necessary objects) to be
signed, so that it can be verified and audited, using the GPG
signature of the person who pushed, that the tips of branches at a
public repository really point the commits the pusher wanted to,
without having to "trust" the server.
* "git interpret-trailers" is a new filter to programmatically edit
the tail end of the commit log messages, e.g. "Signed-off-by:".
* "git help everyday" shows the "Everyday Git in 20 commands or so"
document, whose contents have been updated to match more modern
Git practice.
* On the "git svn" front, work progresses to reduce memory consumption and
to improve handling of mergeinfo.
* Some MUAs mangled a line in a message that begins with "From " to
">From " when writing to a mailbox file and feeding such an input to
"git am" used to lose such a line.
* "git daemon" (with NO_IPV6 build configuration) used to incorrectly
use the hostname even when gethostbyname() reported that the given
hostname is not found.
* Newer versions of 'meld' breaks the auto-detection we use to see if
they are new enough to support the `--output` option.
* "git pack-objects" forgot to disable the codepath to generate
object recheability bitmap when it needs to split the resulting
pack.
* "gitweb" used deprecated CGI::startfrom, which was removed from
CGI.pm as of 4.04; use CGI::start_from instead.
* "git log" documentation had an example section marked up not
quite correctly, which passed AsciiDoc but failed with
AsciiDoctor.
Also contains some documentation updates.
* "git push" over HTTP transport had an artificial limit on number of
refs that can be pushed imposed by the command line length.
* When receiving an invalid pack stream that records the same object
twice, multiple threads got confused due to a race.
* An attempt to remove the entire tree in the "git fast-import" input
stream caused it to misbehave.
* Reachability check (used in "git prune" and friends) did not add a
detached HEAD as a starting point to traverse objects still in use.
* "git config --add section.var val" used to lose existing
section.var whose value was an empty string.
* "git fsck" failed to report that it found corrupt objects via its
exit status in some cases.
Backward compatibility notes
----------------------------
* The default value we give to the environment variable LESS has been
changed from "FRSX" to "FRX", losing "S" (chop long lines instead
of wrapping). Existing users who prefer not to see line-wrapped
output may want to set
$ git config core.pager "less -S"
to restore the traditional behaviour. It is expected that people
find output from most subcommands easier to read with the new
default, except for "blame" which tends to produce really long
lines. To override the new default only for "git blame", you can
do this:
$ git config pager.blame "less -S"
* A few disused directories in contrib/ have been retired.
Updates since v2.0
------------------
UI, Workflows & Features
* Since the very beginning of Git, we gave the LESS environment a
default value "FRSX" when we spawn "less" as the pager. "S" (chop
long lines instead of wrapping) has been removed from this default
set of options, because it is more or less a personal taste thing,
as opposed to the others that have good justifications (i.e. "R" is
very much justified because many kinds of output we produce are
colored and "FX" is justified because output we produce is often
shorter than a page).
* The logic and data used to compute the display width needed for
UTF-8 strings have been updated to match Unicode 7.0 better.
* HTTP-based transports learned to better propagate the error messages from
the webserver to the client coming over the HTTP transport.
* The completion script for bash (in contrib/) has been updated to
better handle aliases that define a complex sequence of commands.
* The "core.preloadindex" configuration variable is enabled by default,
allowing modern platforms to take advantage of their
multiple cores.
* "git clone" applies the "if cloning from a local disk, physically
copy the repository using hardlinks, unless otherwise told not to with
--no-local" optimization when the url.*.insteadOf mechanism rewrites a
remote-repository "git clone $URL" into a
clone from a local disk.
* "git commit --date=<date>" option learned more
timestamp formats, including "--date=now".
* The `core.commentChar` configuration variable is used to specify a
custom comment character (other than the default "#") for
the commit message editor. This can be set to `auto` to attempt to
choose a different character that does not conflict with any that
already starts a line in the message being edited, for cases like
"git commit --amend".
* "git format-patch" learned --signature-file=<file> to add the contents
of a file as a signature to the mail message it produces.
* "git grep" learned the grep.fullname configuration variable to force
"--full-name" to be the default. This may cause regressions for
scripted users who do not expect this new behaviour.
* "git imap-send" learned to ask the credential helper for auth
material.
* "git log" and friends now understand the value "auto" for the
"log.decorate" configuration variable to enable the "--decorate"
option automatically when the output is sent to tty.
* "git merge" without an argument, even when there is an upstream
defined for the current branch, refused to run until
merge.defaultToUpstream is set to true. Flip the default of that
configuration variable to true.
* "git mergetool" learned to drive the vimdiff3 backend.
* mergetool.prompt used to default to 'true', always asking "do you
really want to run the tool on this path?". The default has been
changed to 'false'. However, the prompt will still appear if
mergetool used its autodetection system to guess which tool to use.
Users who explicitly specify or configure a tool will no longer see
the prompt by default.
Strictly speaking, this is a backward incompatible change and
users need to explicitly set the variable to 'true' if they want
to be prompted to confirm running the tool on each path.
* "git replace" learned the "--edit" subcommand to create a
replacement by editing an existing object.
* "git replace" learned a "--graft" option to rewrite the parents of a
commit.
* "git send-email" learned "--to-cover" and "--cc-cover" options, to
tell it to copy To: and Cc: headers found in the first input file
when emitting later input files.
* "git svn" learned to cope with malformed timestamps with only one
digit in the hour part, e.g. 2014-01-07T5:01:02.048176Z, emitted
by some broken subversion server implementations.
* "git tag" when editing the tag message shows the name of the tag
being edited as a comment in the editor.
* "git tag" learned to pay attention to "tag.sort" configuration, to
be used as the default sort order when no --sort=<value> option
is given.
* A new "git verify-commit" command, to check GPG signatures in signed
commits, in a way similar to "git verify-tag" is used to check
signed tags, was added.
has been linking with Apple's CommonCrypto instead. Add an
"apple-common-crypto" option that explicitly avoids CommonCrypto
when it's off. Turn it off by default, and set PKG_FAIL_REASON if
it's enabled on an unsuitable system.
While here, regenerate fuzzy patches.
Addresses pkg/49051. Bump PKGREVISION.
------------------
* Commands that take pathspecs on the command line misbehaved when
the pathspec is given as an absolute pathname (which is a
practice not particularly encouraged) that points at a symbolic
link in the working tree.
* An earlier fix to the shell prompt script (in contrib/) for using
the PROMPT_COMMAND interface did not correctly check if the extra
code path needs to trigger, causing the branch name not to appear
when 'promptvars' option is disabled in bash or PROMPT_SUBST is
unset in zsh.
* "git p4" dealing with changes in binary files were broken by a
change in 1.9 release.
* The shell prompt script (in contrib/), when using the PROMPT_COMMAND
interface, used an unsafe construct when showing the branch name in
$PS1.
* "git rebase" used a POSIX shell construct FreeBSD /bin/sh does not
work well with.
* Some more Unicode codepoints defined in Unicode 6.3 as having
zero width have been taught to our display column counting logic.
* Some tests used shell constructs that did not work well on
FreeBSD.
Foreign interfaces, subsystems and ports.
* The HTTP transport, when talking GSS-Negotiate, uses "100
Continue" response to avoid having to rewind and resend a large
payload, which may not be always doable.
* Various bugfixes to remote-bzr and remote-hg (in contrib/).
* The build procedure is aware of MirBSD now.
* Various "git p4", "git svn" and "gitk" updates.
UI, Workflows & Features
* Fetching from a shallowly-cloned repository used to be forbidden,
primarily because the codepaths involved were not carefully vetted
and we did not bother supporting such usage. This release attempts
to allow object transfer out of a shallowly-cloned repository in a
more controlled way (i.e. the receiver becomes a shallow repository
with a truncated history).
* Just like we give a reasonable default for "less" via the LESS
environment variable, we now specify a reasonable default for "lv"
via the "LV" environment variable when spawning the pager.
* Two-level configuration variable names in "branch.*" and "remote.*"
hierarchies, whose variables are predominantly three-level, were
not completed by hitting a <TAB> in bash and zsh completions.
* Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol'
remote-tracking branch from an earlier fetch was still there, would
error out, primarily because the command was not told that it is
allowed to lose any information on our side. "git fetch --prune"
now can be used to remove 'frotz/nitfol' to make room for fetching and
storing the 'frotz' remote-tracking branch.
* "diff.orderfile=<file>" configuration variable can be used to
pretend as if the "-O<file>" option were given from the command
line of "git diff", etc.
* The negative pathspec syntax allows "git log -- . ':!dir'" to tell
us "I am interested in everything but 'dir' directory".
* "git difftool" shows how many different paths there are in total,
and how many of them have been shown so far, to indicate progress.
* "git push origin master" used to push our 'master' branch to update
the 'master' branch at the 'origin' repository. This has been
enhanced to use the same ref mapping "git push origin" would use to
determine what ref at the 'origin' to be updated with our 'master'.
For example, with this configuration
[remote "origin"]
push = refs/heads/*:refs/review/*
that would cause "git push origin" to push out our local branches
to corresponding refs under refs/review/ hierarchy at 'origin',
"git push origin master" would update 'refs/review/master' over
there. Alternatively, if push.default is set to 'upstream' and our
'master' is set to integrate with 'topic' from the 'origin' branch,
running "git push origin" while on our 'master' would update their
'topic' branch, and running "git push origin master" while on any
of our branches does the same.
* "gitweb" learned to treat ref hierarchies other than refs/heads as
if they are additional branch namespaces (e.g. refs/changes/ in
Gerrit).
* "git for-each-ref --format=..." learned a few formatting directives;
e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)".
* The command string given to "git submodule foreach" is passed
directly to the shell, without being eval'ed. This is a backward
incompatible change that may break existing users.
* "git log" and friends learned the "--exclude=<glob>" option, to
allow people to say "list history of all branches except those that
match this pattern" with "git log --exclude='*/*' --branches".
* "git rev-parse --parseopt" learned a new "--stuck-long" option to
help scripts parse options with an optional parameter.
* The "--tags" option to "git fetch" no longer tells the command to
fetch _only_ the tags. It instead fetches tags _in addition to_
what are fetched by the same command line without the option.
* "git fetch --depth=0" was a no-op, and was silently ignored.
Diagnose it as an error.
* Remote repository URL expressed in scp-style host:path notation are
parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks
to connect to user's home directory on host at address ::1.
* SSL-related options were not passed correctly to underlying socket
layer in "git send-email".
* "git commit -v" appends the patch to the log message before
editing, and then removes the patch when the editor returned
control. However, the patch was not stripped correctly when the
first modified path was a submodule.
* "git mv A B/", when B does not exist as a directory, should error
out, but it didn't.
* When we figure out how many file descriptors to allocate for
keeping packfiles open, a system with non-working getrlimit() could
cause us to die(), but because we make this call only to get a
rough estimate of how many is available and we do not even attempt
to use up all file descriptors available ourselves, it is nicer to
fall back to a reasonable low value rather than dying.
* "git log --decorate" did not handle a tag pointed by another tag
nicely.
* "git add -A" (no other arguments) in a totally empty working tree
used to emit an error.
* There is no reason to have a hardcoded upper limit of the number of
parents for an octopus merge, created via the graft mechanism, but
there was.
* The implementation of 'git stash $cmd "stash@{...}"' did not quote
the stash argument properly and left it split at IFS whitespace.
* The documentation to "git pull" hinted there is an "-m" option
because it incorrectly shared the documentation with "git merge".
Also contains typofixes, documentation updates and trivial code clean-ups.
* The "--[no-]informative-errors" options to "git daemon" were parsed
a bit too loosely, allowing any other string after these option
names.
* A "gc" process running as a different user should be able to stop a
new "gc" process from starting.
* An earlier "clean-up" introduced an unnecessary memory leak to the
credential subsystem.
* "git mv A B/", when B does not exist as a directory, should error
out, but it didn't.
* "git rev-parse <revs> -- <paths>" did not implement the usual
disambiguation rules the commands in the "git log" family used in
the same way.
* "git cat-file --batch=", an admittedly useless command, did not
behave very well.
Also contains typofixes, documentation updates and trivial code clean-ups.
git-svn: workaround for a bug in svn serf backend
Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its 3d argument when storing it on the returned
descriptor. As a result, by the time this field is used (in
transactions of file copying or renaming) it may well be released.
This patch works around this bug, by storing the value to be passed as
the 3d argument to add_file() in a local variable with the same scope as
the file change descriptor, making sure their lifetime is the same.
Cc: Benjamin Pabst <benjamin.pabst85 <at> gmail.com>
Cc: Eric Wong <normalperson <at> yhbt.net>
Signed-off-by: Roman Kagan <rkagan <at> mail.ru>
---
perl/Git/SVN/Editor.pm | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
http://permalink.gmane.org/gmane.comp.version-control.git/239690
* "git diff -- ':(icase)makefile'" was unnecessarily rejected at the
command line parser.
* "git cat-file --batch-check=ok" did not check the existence of
the named object.
* "git am --abort" sometimes complained about not being able to write
a tree with an 0{40} object in it.
* Two processes creating loose objects at the same time could have
failed unnecessarily when the name of their new objects started
with the same byte value, due to a race condition.
Also contains typofixes, documentation updates and trivial code clean-ups
* "git submodule init" copied "submodule.$name.update" settings from
.gitmodules to .git/config without making sure if the suggested
value was sensible.
* The interaction between use of Perl in our test suite and NO_PERL
has been clarified a bit.
* A fast-import stream expresses a pathname with funny characters by
quoting them in C style; remote-hg remote helper (in contrib/)
forgot to unquote such a path.
* One long-standing flaw in the pack transfer protocol used by "git
clone" was that there was no way to tell the other end which branch
"HEAD" points at, and the receiving end needed to guess. A new
capability has been defined in the pack protocol to convey this
information so that cloning from a repository with more than one
branches pointing at the same commit where the HEAD is at now
reliably sets the initial branch in the resulting repository.
* We did not handle cases where http transport gets redirected during
the authorization request (e.g. from http:// to https://).
* "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the
output, but "git rev-list --objects v1.0^..v1.0" did not.
* The fall-back parsing of commit objects with broken author or
committer lines were less robust than ideal in picking up the
timestamps.
* Bash prompting code to deal with an SVN remote as an upstream
were coded in a way not supported by older Bash versions (3.x).
* "git checkout topic", when there is not yet a local "topic" branch
but there is a unique remote-tracking branch for a remote "topic"
branch, pretended as if "git checkout -t -b topic remote/$r/topic"
(for that unique remote $r) was run. This hack however was not
implemented for "git checkout topic --".
* Coloring around octopus merges in "log --graph" output was screwy.
* We did not generate HTML version of documentation to "git subtree"
in contrib/.
* The synopsis section of "git unpack-objects" documentation has been
clarified a bit.
* An ancient How-To on serving Git repositories on an HTTP server
lacked a warning that it has been mostly superseded with more
modern way.
* "git clone" gave some progress messages to the standard output, not
to the standard error, and did not allow suppressing them with the
"--no-progress" option.
* "format-patch --from=<whom>" forgot to omit unnecessary in-body
from line, i.e. when <whom> is the same as the real author.
* "git shortlog" used to choke and die when there is a malformed
commit (e.g. missing authors); it now simply ignore such a commit
and keeps going.
* "git merge-recursive" did not parse its "--diff-algorithm=" command
line option correctly.
* "git branch --track" had a minor regression in v1.8.3.2 and later
that made it impossible to base your local work on anything but a
local branch of the upstream repository you are tracking from.
* "git ls-files -k" needs to crawl only the part of the working tree
that may overlap the paths in the index to find killed files, but
shared code with the logic to find all the untracked files, which
made it unnecessarily inefficient.
* When there is no sufficient overlap between old and new history
during a "git fetch" into a shallow repository, objects that the
sending side knows the receiving end has were unnecessarily sent.
* When running "fetch -q", a long silence while the sender side
computes the set of objects to send can be mistaken by proxies as
dropped connection. The server side has been taught to send a
small empty messages to keep the connection alive.
* When the webserver responds with "405 Method Not Allowed", "git
http-backend" should tell the client what methods are allowed with
the "Allow" header.
* "git cvsserver" computed the permission mode bits incorrectly for
executable files.
* The implementation of "add -i" has a crippling code to work around
ActiveState Perl limitation but it by mistake also triggered on Git
for Windows where MSYS perl is used.
* We made sure that we notice the user-supplied GIT_DIR is actually a
gitfile, but did not do the same when the default ".git" is a
gitfile.
* When an object is not found after checking the packfiles and then
loose object directory, read_sha1_file() re-checks the packfiles to
prevent racing with a concurrent repacker; teach the same logic to
has_sha1_file().
* "git commit --author=$name", when $name is not in the canonical
"A. U. Thor <au.thor@example.xz>" format, looks for a matching name
from existing history, but did not consult mailmap to grab the
preferred author name.
* The commit object names in the insn sheet that was prepared at the
beginning of "rebase -i" session can become ambiguous as the
rebasing progresses and the repository gains more commits. Make
sure the internal record is kept with full 40-hex object names.
* "git rebase --preserve-merges" internally used the merge machinery
and as a side effect, left merge summary message in the log, but
when rebasing, there should not be a need for merge summary.
* "git rebase -i" forgot that the comment character can be
configurable while reading its insn sheet.
* Some old versions of bash do not grok some constructs like
'printf -v varname' which the prompt and completion code started
to use recently. The completion and prompt scripts have been
adjusted to work better with these old versions of bash.
* In FreeBSD's and NetBSD's "sh", a return in a dot script in a
function returns from the function, not only in the dot script,
breaking "git rebase" on these platforms (regression introduced
in 1.8.4-rc1).
* "git rebase -i" and other scripted commands were feeding a
random, data dependant error message to 'echo' and expecting it
to come out literally.
* Setting the "submodule.<name>.path" variable to the empty
"true" caused the configuration parser to segfault.
* Output from "git log --full-diff -- <pathspec>" looked strange
because comparison was done with the previous ancestor that
touched the specified <pathspec>, causing the patches for paths
outside the pathspec to show more than the single commit has
changed.
* The auto-tag-following code in "git fetch" tries to reuse the
same transport twice when the serving end does not cooperate and
does not give tags that point to commits that are asked for as
part of the primary transfer. Unfortunately, Git-aware transport
helper interface is not designed to be used more than once, hence
this did not work over smart-http transfer. Fixed.
* Send a large request to read(2)/write(2) as a smaller but still
reasonably large chunks, which would improve the latency when the
operation needs to be killed and incidentally works around broken
64-bit systems that cannot take a 2GB write or read in one go.
* A ".mailmap" file that ends with an incomplete line, when read
from a blob, was not handled properly.
* The recent "short-cut clone connectivity check" topic broke a
shallow repository when a fetch operation tries to auto-follow
tags.
* When send-email comes up with an error message to die with upon
failure to start an SSL session, it tried to read the error
string from a wrong place.
* A call to xread() was used without a loop to cope with short
read in the codepath to stream large blobs to a pack.
* On platforms with fgetc() and friends defined as macros, the
configuration parser did not compile.
* New versions of MediaWiki introduced a new API for returning
more than 500 results in response to a query, which would cause
the MediaWiki remote helper to go into an infinite loop.
* Subversion's serf access method (the only one available in
Subversion 1.8) for http and https URLs in skelta mode tells its
caller to open multiple files at a time, which made "git svn
fetch" complain that "Temp file with moniker 'svn_delta' already
in use" instead of fetching.
Also contains a handful of trivial code clean-ups, documentation
updates, updates to the test suite, etc.
Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.
Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce,
and ClearCase with features like cheap local branching, convenient
staging areas, and multiple workflows.
This package contains only the git program (and subcommands). It does
not contain man pages or the tk-based repository browser.
