t9500: skip gitweb tests if perl version is too old
gitweb calls Encode::decode_utf8 with two arguments,
but old versions of perl only allow this function to be called
with one argument. Even older versions of perl do not even
have an Encode module.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'master' of git://repo.or.cz/git/fastimport
* 'master' of git://repo.or.cz/git/fastimport: (260 commits)
Avoid src:dst syntax as default bash completion for git push
Make it possible to specify the HEAD for the internal findUpstreamBranchPoint function.
Added git-p4 branches command that shows the mapping of perforce depot paths to imported git branches.
Warn about conflicting p4 branch mappings and use the first one found.
Fix the branch mapping detection to be independent from the order of the "p4 branches" output.
git-p4 fails when cloning a p4 depo.
Fix initial multi-branch import.
Only use double quotes on Windows
Fix git-p4 rebase to detect the correct upstream branch instead of unconditionally
Moved the code from git-p4 submit to figure out the upstream branch point
git-p4 submit: Fix missing quotes around p4 commands to make them work with spaces in filenames
Mention remotes/p4/master also in the documentation.
Provide some information for single branch imports where the commits go
git-p4: check for existence of repo dir before trying to create
Write out the options tag in the log message of imports only if we actually have
Fix support for explicit disabling of syncing with the origin
Fix depot-paths encoding for multi-path imports (don't split up //depot/path/foo)
Fix project name guessing
Fix updating/creating remotes/p4/* heads from origin/p4/*
Fixed the check to make sure to exclude the HEAD symbolic refs when updating
...
* js/filter:
filter-branch: subdirectory filter needs --full-history
filter-branch: Simplify parent computation.
Teach filter-branch about subdirectory filtering
filter-branch: also don't fail in map() if a commit cannot be mapped
filter-branch: Use rev-list arguments to specify revision ranges.
filter-branch: fix behaviour of '-k'
filter-branch: use $(($i+1)) instead of $((i+1))
chmod +x git-filter-branch.sh
filter-branch: prevent filters from reading from stdin
t7003: make test repeatable
Add git-filter-branch
Document git-gui, git-citool as mainporcelain manual pages
Jakub Narebski pointed out that the git-gui blame viewer is not a
widely known feature, but is incredibly useful. Part of the issue
is advertising. Up until now we haven't even referenced git-gui from
within the core Git manual pages, mostly because I just wasn't sure
how I wanted to supply git-gui documentation to end-users, or how
that documentation should integrate with the core Git documentation.
Based upon Jakub's comment that many users may not even know that
the gui is available in a stock Git distribution I'm offering up
two basic manual pages: git-citool and git-gui. These should offer
enough of a starting point for users to identify that the gui exists,
and how to start it. Future releases of git-gui may contain their
own documentation system available from within a running git-gui.
But not today.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generate tags with correct timestamp (git-svnimport)
Now uses git-tag instead of manually constructing the tag. This gives us a
correct timestamp, removes some crufty code, and makes it work the same as
git-cvsimport.
The generated tags are now lightweight tags instead of tag objects, which may
or may not be the behaviour we want.
Also, remove two unused variables from git-cvsimport.
Import branch 'git-p4' of git://repo.or.cz/fast-export
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.
Avoid src:dst syntax as default bash completion for git push
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>
If the remote repository does not have a "current branch", git-clone
was confused and did not set up the resulting new repository
correctly. It did not reset HEAD from the default 'master', and did
not write the SHA1 to the master branch.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ALLOC_GROW now expects the 'nr' argument to be "how much you
want" and not "how much you have". This fixes all cases
where we weren't previously adding anything to the 'nr'.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pp_header(): work around possible memory corruption
add_user_info() possibly adds way more than just the commit header line.
In fact, it sometimes needs so much more space that there is a buffer
overrun, leading to an ugly crash. For example, the date is printed in its
own line, and usually takes up more space than the equivalent Unix epoch.
So, for good measure, add 80 characters (a full line) to the allocated
space, in addition to the header line length.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ALLOC_GROW macro will never let us fill the array completely,
instead allocating an extra chunk if that would be the case. This is
because the 'nr' argument was originally treated as "how much we do have
now" instead of "how much do we want". The latter makes much more
sense because you can grow by more than one item.
This off-by-one never resulted in an error because it meant we were
overly conservative about when to allocate. Any callers which passed
"how much we have now" need to be updated, or they will fail to allocate
enough.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document --stale-fix, used in "git reflog expire --stale-fix --all"
to remove invalid reflog entries, to fix situation after running
non reflog-aware git-prune from an older git in the presence of
reflogs (see RelNotes-1.5.0.txt).
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>
Do not use h_errno after connect(2): the function does not set it
Randal L. Schwartz noticed compilation problems on SunOS, which made
me look at the code again. The thing is, h_errno is not used by
connect(2), it is only for functions from netdb.h, like gethostbyname.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/remote:
git-push: Update description of refspecs and add examples
remote.c: "git-push frotz" should update what matches at the source.
remote.c: fix "git push" weak match disambiguation
remote.c: minor clean-up of match_explicit()
remote.c: refactor creation of new dst ref
remote.c: refactor match_explicit_refs()
* fl/cvsserver:
cvsserver: Actually implement --export-all
cvsserver: Let --base-path and pserver get along just fine
cvsserver: Add some useful commandline options
* lh/submodule:
gitmodules(5): remove leading period from synopsis
Add gitmodules(5)
git-submodule: give submodules proper names
Rename sections from "module" to "submodule" in .gitmodules
git-submodule: remember to checkout after clone
t7400: barf if git-submodule removes or replaces a file
Refspecs with no colons are left with no dst value, because they are
interepreted differently for fetch and push. For push, they mean to
reuse the src side. Fix this for patterns.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It turns out that the attribute definition we have had for a
long time to hide "^" character from AsciiDoc 7 was not honored
by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is
a similar breakage with the "compatible" mode with + characters.
The double colon at the end of definition list term needs
to be attached to the term, without a whitespace. After this
minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with
compatibility mode seems to produce reasonably good results.
$EMAIL is a last resort fallback, as it's system-wide.
$EMAIL is a system-wide setup that is used for many many many
applications. If the git user chose a specific user.email setup,
then _this_ should be honoured rather than $EMAIL.
Add a local implementation of hstrerror for the system which do not have it
The function converts the value of h_errno (last error of name
resolver library, see netdb.h).
One of systems which supposedly do not have the function is SunOS.
POSIX does not mandate its presence.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitmodules(5): remove leading period from synopsis
Asciidoc treats a line starting with a period followed by a title as a
blocktitle element. My introduction of gitmodules(5) unfortunatly broke
the documentation build process due to this processing, since it made
asciidoc generate an illegal (empty) synopsis element. Removing the leading
period fixes the problem and also makes gitmodules(5) use the same synopsis
notation as gitattributes(5).
Noticed-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also enforce that --export-all is only ever used together with an
explicit whitelist. Otherwise people might export every git repository
on the whole system without realising.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsserver: Let --base-path and pserver get along just fine
Embarassing bug number one in my options patch.
Since the code for --base-path support rewrote
the cvsroot value after comparing it with a possible
existing value (i.e. from pserver authentication)
the check always failed.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: test for creating new directories over svn://
As reported by Matthieu Moy, this is causing svnserve to
terminate connections, because it segfaults.
This test is disabled by default and can be enabled by setting
SVNSERVE_PORT to an unbound (for 127.0.0.1) TCP port in the
environment (in addition to SVN_TESTS=1). I'm not comfortable
with having a test start a daemon by default and take up a port
that could potentially stay running if the test failed.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: cleanup: factor out longest_common_path() function
I hadn't looked at this code in a while and had to read this
again to figure out what it did. To avoid having to do this
again in the future, I just gave gave the hunk a descriptive
name.
Signed-off-by: Eric Wong <normalperson@yhbt.net> 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>
Previously, the code would always set up the excludes, and then manually
pick through the pathspec we were given, assuming that non-added but
existing paths were just ignored. This was mostly correct, but would
erroneously mark a totally empty directory as 'ignored'.
Instead, we now use the collect_ignored option of dir_struct, which
unambiguously tells us whether a path was ignored. This simplifies the
code, and means empty directories are now just not mentioned at all.
Furthermore, we now conditionally ask dir_struct to respect excludes,
depending on whether the '-f' flag has been set. This means we don't have
to pick through the result, checking for an 'ignored' flag; ignored entries
were either added or not in the first place.
We can safely get rid of the special 'ignored' flags to dir_entry, which
were not used anywhere else.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When set, this option will cause read_directory to keep
track of which entries were ignored. While this shouldn't
effect functionality in most cases, it can make warning
messages to the user much more useful.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extend --pretty=oneline to cover the first paragraph,
so that an ugly commit message like this can be
handled sanely.
Currently, --pretty=oneline and --pretty=email (hence
format-patch) take and use only the first line of the commit log
message. This changes them to:
- Take the first paragraph, where the definition of the first
paragraph is "skip all blank lines from the beginning, and
then grab everything up to the next empty line".
- Replace all line breaks with a whitespace.
This change would not affect a well-behaved commit message that
adheres to the convention of "single line summary, a blank line,
and then body of message", as its first paragraph always
consists of a single line. Commit messages from different
culture, such as the ones imported from CVS/SVN, can however get
chomped with the existing behaviour at the first linebreak in
the middle of sentence right now, which would become much easier
to see with this change.
The Subject: and --pretty=oneline output would become very long
and unsightly for non-conforming commits, but their messages are
already ugly anyway, and thischange at least avoids the loss of
information.
The Subject: line from a multi-line paragraph is folded using
RFC2822 line folding rules at the places where line breaks were
in the original.
Traditionally we had 16kB limit when formatting log messages for
output, because it was easier to arrange for the caller to have
a reasonably big buffer and pass it down without ever worrying
about reallocating.
This changes the calling convention of pretty_print_commit() to
lift this limit. Instead of the buffer and remaining length, it
now takes a pointer to the pointer that points at the allocated
buffer, and another pointer to the location that stores the
allocated length, and reallocates the buffer as necessary.
To support the user format, the error return of interpolate()
needed to be changed. It used to return a bool telling "Ok the
result fits", or "Sorry, I had to truncate it". Now it returns
0 on success, and returns the size of the buffer it wants in
order to fit the whole result.
This is in preparation for keeping two entry lists in the
dir object.
This patch adds and uses the ALLOC_GROW() macro, which
implements the commonly used idiom of growing a dynamic
array using the alloc_nr function (not just in dir.c, but
everywhere).
We also move creation of a dir_entry to dir_entry_new.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote show: Also shorten non-fast-forward refs in the 'push' listing
'git-remote show remote-name' lists the refs that are pushed to the remote
by showing the 'Push' line from the config file. But before showing it,
it shortened 'refs/heads/here:refs/heads/there' to 'here:there'. However,
if the Push line is prefixed with a plus, the ref was not shortened.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: change filename/directory name of snapshots
/.git or .git is removed from the project name and the
basename of the remaining path is used as the beginning of
the filename and as the directory in the archive.
The regexp will actually not strip off /.git or .git if there
wouldn't be anything left after removing it.
Currently the full project name is used as directory in the
archive and the basename is used as filename. For example a
repository named foo/bar/.git will have a archive named
.git-<version>.* and extract to foo/bar/.git. With this patch
the file is named bar-<version>.* and extracts to bar.
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* aw/cvs:
cvsimport: add <remote>/HEAD reference in separate remotes more
cvsimport: update documentation to include separate remotes option
cvsimport: add support for new style remote layout
This changes the way git-submodule uses .gitmodules: Subsections no longer
specify the submodule path, they now specify the submodule name. The
submodule path is found under the new key "submodule.<name>.path", which is
a required key.
With this change a submodule can be moved between different 'checkout paths'
without upsetting git-submodule.
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename sections from "module" to "submodule" in .gitmodules
Rename [module] to [submodule], so that it would be more
forward compatible with the proposed extension by harmonizing
the section names used in .gitmodules and .git/config.
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
After the initial clone of a submodule, no files would be checked out in
the submodule directory if the submodule HEAD was equal to the SHA-1
specified in the index of the containing repository. This fixes the problem
by simply ignoring submodule HEAD for a fresh clone.
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach diff to imply --find-copies-harder upon -C -C
Earlier, a second "-C" on the command line had no effect.
But "--find-copies-harder" is so long to type, let's make doubled -C
enable that option. It is in line with how "git blame" handles such
doubled options to mean "work harder".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid double-slash in path names that depend on $(sharedir).
Recent git-gui has the ability to determine the location of its library
files relative to the --exec-dir. Its Makefile enables this capability
depending on the install paths that are specified. However, without this
fix there is an extra slash in a path specification, so that the Makefile
does not recognize the equivalence of two paths that it compares.
A side-effect is that all "standard" builds (which do not set $(sharedir)
explicitly) now exploit above mentioned gut-gui feature.
Another side-effect is that an ugly compiled-in double-slash in
$(template_dir) is avoided.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Save geometry before the window layout is damaged
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Include 'war on whitespace' fixes from git.git
Unquote From line from patch before comparing with given from address.
This makes --suppress-from actually work when you're unfortunate enough
to have non-ASCII in your name. Also, if there's a match use the optionally
RFC2047 quoted version from the email.
Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint' of git://repo.or.cz/git-gui into maint
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Save geometry before the window layout is damaged
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Include 'war on whitespace' fixes from git.git
git-gui: Save geometry before the window layout is damaged
Because Tk does not assure us the order that it will process
children in before it destroys the main toplevel we cannot safely
save our geometry data during a "bind . <Destroy>" event binding.
The geometry may have already changed as a result of a one or
more children being removed from the layout. This was pointed
out in gitk by Mark Levedahl, and patched over there by commit b6047c5a8166a71e01c6b63ebbb67c6894d95114.
So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when
the window is closed by the user, and forward that close event to
our main do_quit routine.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Give amend precedence to HEAD over MERGE_MSG
Apparently git-commit.sh (the command line commit user interface in
core Git) always gives precedence to the prior commit's message if
`commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists.
We actually were doing the same here in git-gui, but the amended
message got lost if $GIT_DIR/MERGE_MSG already existed because
we started a rescan immediately after loading the prior commit's
body into the edit buffer. When that happened the rescan found
MERGE_MSG existed and replaced the commit message buffer with the
contents of that file. This meant the user never saw us pick up
the commit message of the prior commit we are about to replace.
Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by
running `git cherry-pick -n $someid` and then trying to amend the
prior commit in git-gui, thus combining the contents of $someid
with the contents of HEAD, and reusing the commit message of HEAD,
not $someid. With the recent changes to make cherry-pick use the
$GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message
of $someid, not HEAD. Now we always use HEAD if we are amending.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Include 'war on whitespace' fixes from git.git
Earlier git.git applied a large "war on whitespace" patch that was
created using 'apply --whitespace=strip'. Unfortunately a few of
git-gui's own files got caught in the mix and were also cleaned up.
That was a6080a0a44d5ead84db3dabbbc80e82df838533d.
This patch is needed in git-gui.git to reapply those exact same
changes here, otherwise our version generator script is unable to
obtain our version number from git-describe when we are hosted in
the git.git repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>