git-tag(1): -v option is a subcommand; fix code block
When the -v is passed, git-tag will exit after it is processed like it
does with the -d and -l options. Additionally, missing code block caused
wrong rendering of an option example.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Improve request-pull to handle non-rebased branches
This is actually a few different changes to request-pull,
making it slightly smarter:
1) Minor cleanup of revision->base variable names, making it
follow the head/headrev naming convention that is already
in use.
2) Compute the merge-base between the two revisions upfront
and reuse that selected merge-base to create the diffstat.
3) Refuse to generate a pull request for branches that have no
existing relationship. These aren't very common and would mess
up our diffstat generation.
4) Disable the PAGER when running shortlog and diff, as these
would otherwise activate the pager for each command when
git-request-pull is run on a tty. Instead users can get the
entire output paged (if desired) using `git -p request-pull`.
5) Use shortlog rather than `git log | git shortlog` now that
recent shortlog versions are able to run the revision listing
internally.
6) Attempt to resolve the input URL using the user's configured
remotes. This is useful if the URL you want the recipient to
see is also the one you used to push your changes. If not a
config-file remote could easily be setup for the public URL
and request-pull could be passed that name instead.
7) Automatically guess and include the remote branch name in the
body of the message. We list the branch name immediately after
the URL, making it easy for the recipient to copy and paste
the entire line onto a `git pull` command line. Rumor has it
Linus likes this format, for exactly that reason.
If multiple branches at the remote match $headrev we take the
first one returned by peek-remote and assume it is suitable.
If no branches are available we warn the user about the problem,
but insert a static string that is not a valid branch name
and would be obvious to anyone reading the message as being
totally incorrect. This allows users to still generate a
template message without network access (for example) and
hand-correct the bits that cannot be verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
gitweb: use decode_utf8 directly
posix compatibility for t4200
Document 'opendiff' value in config.txt and git-mergetool.txt
Allow PERL_PATH="/usr/bin/env perl"
Make xstrndup common
diff.c: fix "size cache" handling.
http-fetch: Disable use of curl multi support for libcurl < 7.16.
There is a mechanism PERL_PATH in the Makefile to specify path to
Perl binary, but sometimes it is convenient to let 'env' figure
out where Perl comes from, with PERL_PATH="/usr/bin/env perl".
Allowing this would make things easier to MacPorts, where we wish
to work with the MacPorts perl if it is installed, but fall back
to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st> Signed-off-by: Junio C Hamano <junkio@cox.net>
This also improves the implementation to match how strndup is
specified (by GNU): if the length given is longer than the string,
only the string's length is allocated and copied, but the string need
not be null-terminated if it is at least as long as the given length.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
We broke the size-cache handling when we changed the function
signature of sha1_object_info() in 21666f1a. We obviously
wanted to cache the size we obtained when sha1_object_info()
succeeded, not when it failed.
http-fetch: Disable use of curl multi support for libcurl < 7.16.
curl_multi_remove_handle() is broken in libcurl < 7.16, in that it
doesn't correctly update the active handles count when a request is
aborted. This causes the transfer to hang forever waiting for the
handle count to become less than the number of active requests.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
There really isn't any point in turning off .mailmap. The
number of mailmap lookups are bounded by number of lines in the
target file, and the real blame processing is much more
expensive. If it turns out to be too costly, we should optimize
the mailmap lookup itself, instead of avoiding the call.
If the author information of commits of the project are
relatively clean, .mailmap would have only small number of
entries, and the overhead of looking it up will not be high. On
the other hand, if the author information is really screwed up
that a good .mailmap needs to be maintained to run shortlog,
giving uncleaned names in blame output is not helpful at all
either.
We can't unconditionally assign revision 1.1 to
newly added files. In case the file did exist in the
past and was deleted we need to honor the old
revision number.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that fast-import is using a "library function" to handle
correcting its packfile's object count and trailing SHA-1 we
should reuse the same function in index-pack, to reduce the
size of the code we must maintain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Teach import-tars about GNU tar's @LongLink extension.
This extension allows GNU tar to process file names in excess of the 100
characters defined by the original tar standard. It does this by faking a
file, named '././@LongLink' containing the true file name, and then adding
the file with a truncated name. The idea is that tar without this
extension will write out a file with the long file name, and write the
contents into a file with truncated name.
Unfortunately, GNU tar does a lousy job at times. When truncating results
in a _directory_ name, it will happily use _that_ as a truncated name for
the file.
An example where this actually happens is gcc-4.1.2, where the full path
of the file WeThrowThisExceptionHelper.java truncates _exactly_ before the
basename. So, we have to support that ad-hoc extension.
This bug was noticed by Chris Riddoch on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Track our own embedded values and rebuild when they change
Like core-Git we now track the values that we embed into our shell
script wrapper, and we "recompile" that wrapper if they are changed.
This concept was lifted from git.git's Makefile, where a similar
thing was done by Eygene Ryabinkin. Too bad it wasn't just done
here in git-gui from the beginning, as the git.git Makefile support
for GIT-GUI-VARS was really just because git-gui doesn't do it on
its own.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Whenever we want to execute a git subcommand from the plumbing
layer (and on rare occasion, the more porcelain-ish layer) we
tend to use our proc wrapper, just to make the code slightly
cleaner at the call sites. I wasn't doing that in a couple of
places, so this is a simple cleanup to correct that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Use option database defaults to set the font
Rather than passing "-font font_ui" to every widget that we
create we can instead reconfigure the option database for
all widget classes to use our font_ui as the default widget
font. This way Tk will automatically setup their defaults
for us, and we can reduce the size of the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An earlier change tossed these optionMenu font configurations
all over the code, when really we can just rename the proc to
a hidden internal name and provide our own wrapper to install
the font configuration we really want.
We also don't need to set these option database entries in all
of the procedures that open dialogs; instead we should just set
one time, them after we have the font configuration ready for use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Correct line wrapping for too many branch message
Since Tk automatically wraps lines for us in tk_messageBox
widgets we don't need to try to wrap them ourselves. Its
actually worse that we linewrapped this here in the script,
as not all fonts will render this dialog nicely.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Warn users before making an octopus merge
A coworker who was new to git-gui recently tried to make an octopus
merge when he did not quite mean to. Unfortunately in his case the
branches had file level conflicts and failed to merge with the octopus
strategy, and he didn't quite know why this happened. Since most users
really don't want to perform an octopus merge this additional safety
valve in front of the merge process is a good thing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Include the subject in the status bar after commit
Now that the command line git-commit has made displaying
the subject (first line) of the newly created commit popular
we can easily do the same thing here in git-gui, without the
ugly part of forking off a child process to obtain that first
line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.
Reported by Randal L. Schwartz on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Remove pointless calls to access(2) when checking for .mailmap
read_mailmap already returns not 0 in case of error, and nothing
seem to be interested in it. It also is silent about the fact
(read_mailmap being to chatty would justify the call to access,
but there is no point for it to be and it isn't).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
strncpy does not NUL-terminate output in case of output buffer too short,
and map_email prototype (and usage) does not allow for figuring out
what the length of the name is.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix symlink handling in git-svn, related to PerlIO
After reading the leading contents from a symlink data obtained
from subversion, which we expect to begin with 'link ', the code
forked to hash the remainder (which should match readlink()
result) using git-hash-objects, by redirecting its STDIN from
the filehandle we read that 'link ' from. This was Ok with Perl
on modern Linux, but on Mac OS, the read in the parent process
slurped more than we asked for in stdio buffer, and the child
did not correctly see the "remainder".
This attempts to fix the issue by using lower level sysseek and
sysread instead of seek and read to bypass the stdio buffer.
Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Eric Wong <normalperson@yhbt.net> Acked-by: Seth Falcon <sethfalcon@gmail.com>
This splits out a few functions to deal with mailmap from
shortlog and makes it a bit more usable from other programs.
Most notably, it does not clobber input e-mail address anymore.
* maint:
http.c: Fix problem with repeated calls of http_init
Add missing reference to GIT_COMMITTER_DATE in git-commit-tree documentation
Fix import-tars fix.
Update .mailmap with "Michael"
Do not barf on too long action description
Catch empty pathnames in trees during fsck
Don't allow empty pathnames in fast-import
import-tars: be nice to wrong directory modes
git-svn: Added 'find-rev' command
git shortlog documentation: add long options and fix a typo
http.c: Fix problem with repeated calls of http_init
Calling http_init after calling http_cleanup causes a segfault. This
is due to the pragma_header curl_slist being freed but not being set
to NULL. The subsequent call to http_init tries to setup the slist
again, but it now points to an invalid memory location.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Released versions of fast-import have been able to create a tree that
contains files or subtrees that contain no name. Unfortunately these
trees aren't valid, but people may have actually tried to create them
due to bugs in import-tars.perl or their own fast-import frontend.
We now look for this unusual condition and warn the user if at
least one of their tree objects contains the problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* commit 'jc/maint': (35 commits)
Update git-http-fetch documentation
Update git-local-fetch documentation
Update git-http-push documentation
Update -L documentation for git-blame/git-annotate
Update git-grep documentation
Update git-fmt-merge documentation
Document additional options for git-fetch
Removing -n option from git-diff-files documentation
Start preparing for 1.5.1.3
Sanitize @to recipients.
git-svn: Ignore usernames in URLs in find_by_url
Document --dry-run and envelope-sender for git-send-email.
Allow users to optionally specify their envelope sender.
Ensure clean addresses are always used with Net::SMTP
Validate @recipients before using it for sendmail and Net::SMTP.
Perform correct quoting of recipient names.
Change the scope of the $cc variable as it is not needed outside of send_message.
Debugging cleanup improvements
Prefix Dry- to the message status to denote dry-runs.
Document --dry-run parameter to send-email.
...
riddochc on #git noticed corruption caused by import-tars. This
was fixed in the prior commit by Dscho, but fast-import was wrong
to have allowed a tree to be created with an empty string as the
filename. No operating system allows this, and Git itself doesn't
accept this into the index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Documentation/git-local-fetch.txt: -s to use
symbolic links instead of file-to-file copy, -l
to use hardlinks, -n to never use file-to-file
copies, --recover to resume a failed fetch.
Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-grep.txt: Document -F/--fixed-strings to
search for non-regexp patterns. Document -I to not search
binary files. Document -<num> as a shortcut for -C<num>.
Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-fmt-merge-msg.txt:
--summary to list commit summaries on merge
--no-summary
--file to take merged objects from a file.
Configuration option merge.summary
Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
post-receive-email example hook: sed command for getting description was wrong
The sed command that extracted the first line of the project description
didn't include the -n switch and hence the project name was being
printed twice. This was ruining the email header generation because it
was assumed that the description was only one line and was included in
the subject. This turned the subject into a two line item and
prematurely finished the header.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
post-receive-email example hook: detect rewind-only updates and output sensible message
Sometimes a non-fast-forward update doesn't add new commits, it merely
removes old commits. This patch adds support for detecting that and
outputting a more correct message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
as it is not relevant for whether the result should be written.
Even if no real merge happened, there might be _no_ reason to
rewrite the working tree file. Maybe even more so.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
If a file is changed in one branch, and renamed and changed to the
same content in another branch than we can skip the rewrite of this
file in the working directory, as the content does not change.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing for 1.5.1.3
Sanitize @to recipients.
git-svn: Ignore usernames in URLs in find_by_url
Document --dry-run and envelope-sender for git-send-email.
Allow users to optionally specify their envelope sender.
Ensure clean addresses are always used with Net::SMTP
Validate @recipients before using it for sendmail and Net::SMTP.
Perform correct quoting of recipient names.
Change the scope of the $cc variable as it is not needed outside of send_message.
Debugging cleanup improvements
Prefix Dry- to the message status to denote dry-runs.
Document --dry-run parameter to send-email.
git-svn: Don't rely on $_ after making a function call
Fix handle leak in write_tree
Actually handle some-low memory conditions
This adds --date={local,relative,default} option to log family of commands,
to allow displaying timestamps in user's local timezone, relative time, or
the default format.
Existing --relative-date option is a synonym of --date=relative; we could
probably deprecate it in the long run.
Allow users to optionally specify their envelope sender.
If your normal user is not the same user you are subscribed to a list with,
then the default envelope sender used will cause your messages to bounce or
silently vanish into the ether.
This patch provides an optional parameter to set the envelope sender.
To use it with the sendmail binary, you must have privileges to use the -f
parameter!
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Validate @recipients before using it for sendmail and Net::SMTP.
Ensure that @recipients is only raw addresses when it is handed to the sendmail
binary OR Net::SMTP, otherwise BCC cases might get an extra <, or wierd stuff
might be passed to the exec.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Always perform quoting of the recipient names if they contain periods,
previously only the author's address was treated this way. This stops sendmail
binaries from exploding the name into bad addresses.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
The debug output is much more helpful if it has the parameters that were used.
Pull the sendmail parameters into a seperate array for that, and also include
similar data during the Net::SMTP case.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: Don't rely on $_ after making a function call
Many functions and operators in perl set $_, so its value cannot be relied upon
after calling arbitrary functions. The solution is simply to copy the value of
$_ into a local variable that will not get overwritten.
Signed-off-by: Adam Roben <aroben@apple.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Tim Ansell discovered his Debian server didn't permit git-daemon to
use as much memory as it needed to handle cloning a project with
a 128 MiB packfile. Filtering the strace provided by Tim of the
rev-list child showed this gem of a sequence:
open("./objects/pack/pack-*.pack", O_RDONLY|O_LARGEFILE <unfinished ...>
<... open resumed> ) = 5
And we asked for another window further into the file. But got
denied. In Tim's case this was due to a resource limit on the
git-daemon process, and its children.
Now where are we in the code? We're down inside use_pack(),
after we have called unuse_one_window() enough times to make sure
we stay within our allowed maximum window size. However since we
didn't unmap the prior window at 0xb5e2d000 we aren't exceeding
the current limit (which probably was just the defaults).
But we're actually down inside xmmap()...
So we release the window we do have (by calling release_pack_memory),
assuming there is some memory pressure...
And that was the last window in this packfile. So we closed it.
Way to go us. Our xmmap did not expect release_pack_memory to
close the fd its about to map...
And we report the bad file descriptor error, and not the ENOMEM,
and die, claiming we are out of memory. But actually that mmap
should have succeeded, as we had enough memory for that window,
seeing as how we released the prior one.
Originally when I developed the sliding window mmap feature I had
this exact same bug in fast-import, and I dealt with it by handing
in the struct packed_git* we want to open the new window for, as the
caller wasn't prepared to reopen the packfile if unuse_one_window
closed it. The same is true here from xmmap, but the caller doesn't
have the struct packed_git* handy. So I'm using the file descriptor
instead to perform the same test.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>