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>
Ralf reported that '--recurse-submodules' option in push.c should not be
translated [1]. Before his commit is merged, remove superfluous
translations for push.c.
In order to catch up with the release of Git 2.2.0 final, make a batch
l10n update for the new l10n change brought by commit d52adf1 (trailer:
display a trailer without its trailing newline).
Merge branch 'master' of git://github.com/git-l10n/git-po
* 'master' of git://github.com/git-l10n/git-po:
l10n: de.po: translate 62 new messages
l10n: de.po: Fixup one translation
l10n: de.po: use imperative form for command options
The test misused a URL "file://." to mean "relative to here",
which we no longer accept.
In a file:// URL, typically there is no host, and RFC1738 says that
file:///<path> should be used.
Update t5705 to use a working URL.
Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, git-fast-import and -export link to each
other, and gitremote-helpers links to existing remote
helpers, and vice versa. Also link to fast-import from the
remote helper spec, as this is relevant for remote helpers
using the fast-import format.
Signed-off-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command: use void to declare that functions take no parameters
Explicitly declare that git_atexit_dispatch() and git_atexit_clear()
take no parameters instead of leaving their parameter list empty and
thus unspecified.
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
trailer: use CHILD_PROCESS_INIT in apply_command()
Initialize the struct child_process variable cp at declaration time.
This is shorter, saves a function call and prevents using the variable
before initialization by mistake.
Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
trailer: display a trailer without its trailing newline
Trailers passed to the parse_trailer() function often have
a trailing newline. When erroring out, we should display
the invalid trailer properly, that means without any
trailing newline.
Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1410: fix breakage on case-insensitive filesystems
Two tests recently added to t1410 create branches "a" and
"a/b" to test d/f conflicts on reflogs. Earlier, unrelated
tests in that script create the path "A/B" in the working
tree. There's no conflict on a case-sensitive filesystem,
but on a case-insensitive one, "git log" will complain that
"a/b" is both a revision and a working tree path.
We could fix this by using a "--" to disambiguate, but we
are probably better off using names that are less confusing
to make it more clear that they are unrelated to the working
tree files. This patch turns "a/b" into "one/two".
Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/use-child-process-init-more:
bundle: split out ref writing from bundle_create
bundle: split out a helper function to compute and write prerequisites
bundle: split out a helper function to create pack data
use child_process_init() to initialize struct child_process variables
The option name "--store" was used early in development, but
never even made it into an applied patch, let alone a
released version of git. I forgot to update the matching
documentation at the time, though.
Noticed-by: Jesse Hopkins <jesse.hopkins@lmco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
While using diff-highlight with other tools, I have discovered that Python
ignores SIGPIPE by default. Unfortunately, this also means that tools
attempting to launch a pager under Python--and don't realize this is
happening--means that the subprocess inherits this setting. In this case, it
means diff-highlight will be launched with SIGPIPE being ignored. Let's work
with those broken scripts by restoring the default SIGPIPE handler.
Signed-off-by: John Szakmeister <john@szakmeister.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ignore stale directories when checking reflog existence
When we update a ref, we have two rules for whether or not
we actually update the reflog:
1. If the reflog already exists, we will always append to
it.
2. If log_all_ref_updates is set, we will create a new
reflog file if necessary.
We do the existence check by trying to open the reflog file,
either with or without O_CREAT (depending on log_all_ref_updates).
If it fails, then we check errno to see what happened.
If we were not using O_CREAT and we got ENOENT, the file
doesn't exist, and we return success (there isn't a reflog
already, and we were not told to make a new one).
If we get EISDIR, then there is likely a stale directory
that needs to be removed (e.g., there used to be "foo/bar",
it was deleted, and the directory "foo" was left. Now we
want to create the ref "foo"). If O_CREAT is set, then we
catch this case, try to remove the directory, and retry our
open. So far so good.
But if we get EISDIR and O_CREAT is not set, then we treat
this as any other error, which is not right. Like ENOENT,
EISDIR is an indication that we do not have a reflog, and we
should silently return success (we were not told to create
it). Instead, the current code reports this as an error, and
we fail to update the ref at all.
Note that this is relatively unlikely to happen, as you
would have to have had reflogs turned on, and then later
turned them off (it could also happen due to a bug in fetch,
but that was fixed in the previous commit). However, it's
quite easy to fix: we just need to treat EISDIR like ENOENT
for the non-O_CREAT case, and silently return (note that
this early return means we can also simplify the O_CREAT
case).
Our new tests cover both cases (O_CREAT and non-O_CREAT).
The first one already worked, of course.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we start the git-fetch program, we call git_config to
load all config, but our callback only processes the
fetch.prune option; we do not chain to git_default_config at
all.
This means that we may not load some core configuration
which will have an effect. For instance, we do not load
core.logAllRefUpdates, which impacts whether or not we
create reflogs in a bare repository.
Note that I said "may" above. It gets even more exciting. If
we have to transfer actual objects as part of the fetch,
then we call fetch_pack as part of the same process. That
function loads its own config, which does chain to
git_default_config, impacting global variables which are
used by the rest of fetch. But if the fetch is a pure ref
update (e.g., a new ref which is a copy of an old one), we
skip fetch_pack entirely. So we get inconsistent results
depending on whether or not we have actual objects to
transfer or not!
Let's just load the core config at the start of fetch, so we
know we have it (we may also load it again as part of
fetch_pack, but that's OK; it's designed to be idempotent).
Our tests check both cases (with and without a pack). We
also check similar behavior for push for good measure, but
it already works as expected.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'for-junio' of git://bogomips.org/git-svn
* 'for-junio' of git://bogomips.org/git-svn:
git-svn: use SVN::Ra::get_dir2 when possible
git-svn: add space after "W:" prefix in warning
git-svn: (cleanup) remove editor param passing
git-svn: prepare SVN::Ra config pieces once
Git.pm: add specified name to tempfile template
git-svn: disable _rev_list memoization
git-svn: save a little memory as fetch progresses
git-svn: remove unnecessary DESTROY override
git-svn: reload RA every log-window-size
git-svn.txt: advertise pushurl with dcommit
git-svn: remove mergeinfo rev caching
git-svn: cache only mergeinfo revisions
git-svn: reduce check_cherry_pick cache overhead
git-svn: only look at the root path for svn:mergeinfo
git-svn: only look at the new parts of svn:mergeinfo
The bundle_create() function has a number of logical steps:
process the input, write the refs, and write the packfile.
Recent commits split the first and third into separate
sub-functions. It's worth splitting the middle step out,
too, if only because it makes the progression of the steps
more obvious.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bundle: split out a helper function to compute and write prerequisites
The new helper compute_and_write_prerequistes() is ugly, but it
cannot be avoided. Ideally we should avoid a function that computes
and does I/O at the same time, but the prerequisites lines in the
output needs the human readable title only to help the recipient of
the bundle. The code copies them straight from the rev-list output
and immediately discards as no other internal computation needs that
information.
bundle: split out a helper function to create pack data
The create_bundle() function, while it does one single logical
thing, takes a rather large implementation to do so.
Let's start separating what it does into smaller steps to make it
easier to see what is going on. This is a first step to separate
out the actual pack-data generation, after the earlier part of the
function figures out which part of the history to place in the
bundle.
cache-tree: avoid infinite loop on zero-entry tree
The loop in cache-tree's update_one iterates over all the
entries in the index. For each one, we find the cache-tree
subtree which represents our path (creating it if
necessary), and then recurse into update_one again. The
return value we get is the number of index entries that
belonged in that subtree. So for example, with entries:
a/one
a/two
b/one
We start by processing the first entry, "a/one". We would
find the subtree for "a" and recurse into update_one. That
would then handle "a/one" and "a/two", and return the value
2. The parent function then skips past the 2 handled
entries, and we continue by processing "b/one".
If the recursed-into update_one ever returns 0, then we make
no forward progress in our loop. We would process "a/one"
over and over, infinitely.
This should not happen normally. Any subtree we create must
have at least one path in it (the one that we are
processing!). However, we may also reuse a cache-tree entry
we found in the on-disk index. For the same reason, this
should also never have zero entries. However, certain buggy
versions of libgit2 could produce such bogus cache-tree
records. The libgit2 bug has since been fixed, but it does
not hurt to protect ourselves against bogus input coming
from the on-disk data structures.
Note that this is not a die("BUG") or assert, because it is
not an internal bug, but rather a corrupted on-disk
structure. It's possible that we could even recover from it
(by throwing out the bogus cache-tree entry), but it is not
worth the effort; the important thing is that we report an
error instead of looping infinitely.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://ozlabs.org/~paulus/gitk:
gitk: Remove boilerplate for configuration variables
gitk: Show detached HEAD if --all is specified
gitk: Do not depend on Cygwin's "kill" command on Windows
If HEAD is detached, 'gitk --all' does not show it. This is inconvenient
for frontend program, and for example git log does show the detached HEAD.
gitk uses git rev-parse to find a list of branches to show.
Apparently, the command does not include detached HEAD to output if
--all argument is specified. This has been discussed in [1] and stated
as expected behavior. So rev-parse's parameters should be tuned in gitk.
gitk: Do not depend on Cygwin's "kill" command on Windows
Windows does not necessarily mean Cygwin, it could also be MSYS. The
latter ships with a version of "kill" that does not understand "-f".
In msysgit this was addressed by shipping Cygwin's version of kill.
Properly fix this by using the stock Windows "taskkill" command instead,
which is available since Windows XP Professional.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
Memoizing these initialization functions saves some memory for
long fetches which require scanning many unwanted revisions
before any wanted revisions happen.