The build procedure did not bother fixing perl and python scripts
when NO_PERL and NO_PYTHON build-time configuration changed.
* jk/rebuild-perl-scripts-with-no-perl-seting-change:
Makefile: have python scripts depend on NO_PYTHON setting
Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros
Makefile: have perl scripts depend on NO_PERL setting
Some tests that depend on perl lacked PERL prerequisite to protect
them, breaking build with NO_PERL configuration.
* jk/no-perl-tests:
t960[34]: mark cvsimport tests as requiring perl
t0090: mark add-interactive test with PERL prerequisite
A request to store an empty note via "git notes" meant to remove
note from the object but with --allow-empty we will store a (surprise!)
note that is empty. In the longer run, we might want to deprecate
the somewhat unintuitive "emptying means deletion" behaviour.
* jh/empty-notes:
t3301: modernize style
notes: empty notes should be shown by 'git log'
builtin/notes: add --allow-empty, to allow storing empty notes
builtin/notes: split create_note() to clarify add vs. remove logic
builtin/notes: simplify early exit code in add()
builtin/notes: refactor note file path into struct note_data
builtin/notes: improve naming
t3301: verify that 'git notes' removes empty notes by default
builtin/notes: fix premature failure when trying to add the empty blob
"git checkout $treeish $path", when $path in the index and the
working tree already matched what is in $treeish at the $path,
still overwrote the $path unnecessarily.
* jk/checkout-from-tree:
checkout $tree: do not throw away unchanged index entries
Allow passing extra set of arguments when ssh is invoked to create
an encrypted & authenticated connection by introducing a new environment
variable GIT_SSH_COMMAND, whose contents is interpreted by shells.
This is not possible with existing GIT_SSH mechanism whose
invocation bypasses shells, which was designed more to match what
other programs with similar variables did, not necessarily to be
more useful.
* tq/git-ssh-command:
git_connect: set ssh shell command in GIT_SSH_COMMAND
By default, check-ignore does not list tracked files at all since
they are not subject to ignore patterns.
Make this clearer in the man page.
Reported-by: Guilherme <guibufolo@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add completion for git-tag options including
all options that are currently shown in "git tag -h".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds simple wrapper functions around calls to stat(), fstat(),
and lstat() that translate the operating system's native file type
bits to those used by most operating systems. It also rewrites the
S_IF* macros to the common values, so all file type processing is
performed using the translated modes. This makes projects portable
across operating systems that use different file type definitions.
Only the file type bits may be affected by these compatibility
functions; the file permission bits are assumed to be 07777 and are
passed through unchanged.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you run git as part of an automated system, you might
prefer git to die rather than try to issue a prompt on the
terminal (because there would be nobody to see it and
respond, and the process would hang forever).
This usually works out of the box because getpass() (and our
more featureful replacements) will fail when there is no
tty, but this does not cover all cases. For example, a batch
system run via ssh might have a tty, even when the user does
not expect it.
Let's provide an environment variable the user can set to
avoid even trying to touch the tty at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we are trying to fill a credential, we loop over the
set of defined credential-helpers, then fall back to running
askpass, and then finally prompt on the terminal. Helpers
which cannot find a credential are free to tell us nothing,
but they cannot currently ask us to stop prompting.
This patch lets them provide a "quit" attribute, which asks
us to stop the process entirely (avoiding running more
helpers, as well as the askpass/terminal prompt).
This has a few possible uses:
1. A helper which prompts the user itself (e.g., in a
dialog) can provide a "cancel" button to the user to
stop further prompts.
2. Some helpers may know that prompting cannot possibly
work. For example, if their role is to broker a ticket
from an external auth system and that auth system
cannot be contacted, there is no point in continuing
(we need a ticket to authenticate, and the user cannot
provide one by typing it in).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow new workdirs to be created in an empty directory (similar to "git
clone"). Provide more error checking and clean up on failure.
Signed-off-by: Paul Smith <paul@mad-scientist.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use <<-\END_OF_HERE_DOCUMENT to allow indenting the HERE document to
make it clear where each test begins and ends, and relieve readers
from having to worry about variable substitution.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ls-tree uses read_tree_recursive() which already does path filtering
using pathspec. No need to filter one more time based on prefix
only. "ls-tree ../somewhere" does not work because of
this. write_name_quotedpfx() can now be retired because nobody else
uses it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows the callback to use 'base' as a temporary buffer to
quickly assemble full path "without" extra allocation. The callback
has to restore it afterwards of course.
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was originally meant to be used to rewrite run_commit_hook()
that only special cases the GIT_INDEX_FILE environment, but the
run_hook_ve() refactoring done earlier made the implementation of
run_commit_hook() thin and clean enough.
Nobody uses this, so retire it as an unfinished clean-up made
unnecessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tcl is conventionally spelled "Tcl". The description of
option "--tcl", however, spells it "tcl". Let's follow
the convention.
Reported-by: Hartmut Henkel <hartmut_henkel@gmx.de>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit baa37bff ("mv: allow renaming to fix case on case
insensitive filesystems", 08-05-2014), the 'git mv' command has
been able to rename a file, to one which differs only in case,
on a case insensitive filesystem.
This results in the 'rename (case change)' test, which used to fail
prior to this commit, to now (unexpectedly) pass. Mark this test as
passing.
[jc: Ramsay's tests on Cygwin, Eric's on Mac OS X]
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Tested-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The plan for the push.default transition had all along been
to use the "simple" method rather than "upstream" as a
default if the user did not specify their own push.default
value. Commit 11037ee (push: switch default from "matching"
to "simple", 2013-01-04) tried to implement that by moving
PUSH_DEFAULT_UNSPECIFIED in our switch statement to
fall-through to the PUSH_DEFAULT_SIMPLE case.
When the commit that became 11037ee was originally written,
that would have been enough. We would fall through to
calling setup_push_upstream() with the "simple" parameter
set to 1. However, it was delayed for a while until we were
ready to make the transition in Git 2.0.
And in the meantime, commit ed2b182 (push: change `simple`
to accommodate triangular workflows, 2013-06-19) threw a
monkey wrench into the works. That commit drops the "simple"
parameter to setup_push_upstream, and instead checks whether
the global "push_default" is PUSH_DEFAULT_SIMPLE. This is
right when the user has explicitly configured push.default
to simple, but wrong when we are a fall-through for the
"unspecified" case.
We never noticed because our push.default tests do not cover
the case of the variable being totally unset; they only
check the "simple" behavior itself.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "__attribute__" flag may be a noop on some compilers.
That's OK as long as the code is correct without the
attribute, but in this case it is not. We would typically
end up with a struct that is 2 bytes too long due to struct
padding, breaking both reading and writing of bitmaps.
Instead of marshalling the data in a struct, let's just
provide helpers for reading and writing the appropriate
types. Besides being correct on all platforms, the result is
more efficient and simpler to read.
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous one tests only the case where a path to be updated by
the push-to-deploy has an incompatible change in the target's
working tree that has already been added to the index, but the
feature itself wants to require the working tree to be a lot cleaner
than what is tested. Add a handful more tests to protect the
feature from future changes that mistakenly (from the viewpoint of
the inventor of the feature) loosens the cleanliness requirement,
namely:
- A change only to the working tree but not to the index is still a
change to be protected;
- An untracked file in the working tree that would be overwritten
by a push-to-deploy needs to be protected;
- A change that happens to make a file identical to what is being
pushed is still a change to be protected (i.e. the feature's
cleanliness requirement is more strict than that of checkout).
Also, test that a stat-only change to the working tree is not a
reason to reject a push-to-deploy.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the user's password).
The common workaround – pushing into a temporary branch and then merging
on the other machine – is no longer necessary with this patch.
The new option is:
'updateInstead':
Update the working tree accordingly, but refuse to do so if there
are any uncommitted changes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function sometimes returns a newly allocated string and
sometimes returns a borrowed string, the latter of which the callers
must not free(). The existing callers all assume that the return
value belongs to the callee and most of them copy it with strdup()
when they want to keep it around. They end up leaking the returned
copy when the callee returned a new string because they cannot tell
if they should free it.
Change the contract between the callers and system_path() to make
the returned string owned by the callers; they are responsible for
freeing it when done, but they do not have to make their own copy to
store it away.
Adjust the callers to make sure they do not leak the returned string
once they are done, but do not bother freeing it just before dying,
exiting or exec'ing other program to avoid unnecessary churn.
Reported-by: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An example where this happens is when doing an ls-tree on a tree that
contains a commit link. In that case, find_unique_abbrev is called
to get a non-abbreviated hex sha1, but still, a lookup is done as
to whether the sha1 is in the repository (which ends up looking for
a loose object in .git/objects), while the result of that lookup is
not used when returning a non-abbreviated hex sha1.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Parse the option and pass it directly to git-mailinfo.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option adds the content of the Message-Id header at the end of the
commit message prepared by git-mailinfo. This is useful in order to
associate commit messages automatically with mailing list discussions.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings. In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eol and friends on it.
Right now, the best option is to use "git am --keep-cr". However, when
a patch create new files, the patch application process will reject the
new file because it finds a "/dev/null\r" string instead of "/dev/null".
The problem is that SMTP transport is CRLF-unsafe. Sending a patch by
email is the same as passing it through "dos2unix | unix2dos". The newly
introduced CRLFs are normally transparent because git-am strips them. The
keepcr=true setting preserves them, but it is mostly working by chance
and it would be very problematic to have a "git am" workflow in a
repository with mixed LF and CRLF line endings.
The MIME solution to this is the quoted-printable transfer enconding.
This is not something that we want to enable by default, since it makes
received emails horrible to look at. However, it is a very good match
for projects that store CRLF line endings in the repository.
The only disadvantage of quoted-printable is that quoted-printable
patches fail to apply if the maintainer uses "git am --keep-cr". This
is because the decoded patch will have two carriage returns at the end
of the line. Therefore, add support for base64 transfer encoding too,
which makes received emails downright impossible to look at outside
a MUA, but really just works.
The patch covers all bases, including users that still live in the late
80s, by also providing a 7bit content transfer encoding that refuses
to send emails with non-ASCII character in them. And finally, "8bit"
will add a Content-Transfer-Encoding header but otherwise do nothing.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After the next patch, git-send-email will sometimes modify
existing Content-Transfer-Encoding headers. Delay the addition
of the header to @xh until just before sending. Do the same
for MIME-Version, to avoid adding it twice.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano
Slavomir Vlcek
Michael J Gruber
Ralf Thielow
David Michael
Jeff King
Paul Smith
Nguyễn Thái Ngọc Duy
Ramsay Jones
Karsten Blees
Johannes Schindelin
Jiang Xin
Hartmut Henkel
Marc Branchaud
Mike Hommey
Paolo Bonzini