Remove extra + 1 from resp_len, the length of the byte sequence to be
Base64 encoded and passed to the server as the response. Or the response
incorrectly contains an extra \0.
Signed-off-by: Kazuki Yamaguchi <k@rhe.jp>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't check for NOLOGIN (LOGINDISABLED) capability when imap.authMethod
is specified.
LOGINDISABLED capability doesn't forbid using AUTHENTICATE, so it should
be allowed, or we can't connect to IMAP servers which only accepts
AUTHENTICATE command.
Signed-off-by: Kazuki Yamaguchi <k@rhe.jp>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git blame $path" with unnormalized data in the index
for the path, the data in the working tree was blamed, even though
"git add" would not have changed what is already in the index, due
to "safe crlf" that disables the line-end conversion. It has been
corrected.
* tb/blame-force-read-cache-to-workaround-safe-crlf:
correct blame for files commited with CRLF
The completion scripts (in contrib/) did not include the
"--cherry-mark" option when completing "git log <HT>".
* mg/complete-cherry-mark-to-log:
completion: complete --cherry-mark for git log
When "git log" shows the log message indented by 4-spaces, the
remainder of a line after a HT does not align in the way the author
originally intended. The command now expands tabs by default in
such a case, and allows the users to override it with a new option,
'--no-expand-tabs'.
* lt/pretty-expand-tabs:
pretty: test --expand-tabs
pretty: allow tweaking tabwidth in --expand-tabs
pretty: enable --expand-tabs by default for selected pretty formats
pretty: expand tabs in indented logs to make things line up properly
"git pull --rebase" learned "--[no-]autostash" option, so that
the rebase.autostash configuration variable set to true can be
overridden from the command line.
* mj/pull-rebase-autostash:
t5520: test --[no-]autostash with pull.rebase=true
t5520: reduce commom lines of code
t5520: factor out common "failing autostash" code
t5520: factor out common "successful autostash" code
t5520: use better test to check stderr output
t5520: ensure consistent test conditions
t5520: use consistent capitalization in test titles
pull --rebase: add --[no-]autostash flag
git-pull.c: introduce git_pull_config()
"git mergetools" learned to drive ExamDiff.
* jn/mergetools-examdiff:
mergetools: add support for ExamDiff
mergetools: create mergetool_find_win32_cmd() helper function for winmerge
"git format-patch --help" showed `-s` and `--no-patch` as if these
are valid options to the command. We already hide `--patch` option
from the documentation, because format-patch is about showing the
diff, and the documentation now hides these options as well.
* es/format-patch-doc-hide-no-patch:
git-format-patch.txt: don't show -s as shorthand for multiple options
Minor code clean-up.
* cc/apply:
builtin/apply: free patch when parse_chunk() fails
builtin/apply: handle parse_binary() failure
apply: remove unused call to free() in gitdiff_{old,new}name()
builtin/apply: get rid of useless 'name' variable
Assorted minor clean-ups.
* sb/misc-cleanups:
credential-cache, send_request: close fd when done
bundle: don't leak an fd in case of early return
abbrev_sha1_in_line: don't leak memory
notes: don't leak memory in git_config_get_notes_strategy
"git send-pack --all <there>" was broken when its command line
option parsing was written in the 2.6 timeframe.
* sk/send-pack-all-fix:
git-send-pack: fix --all option when used with directory
"git diff -M" used to work better when two originally identical
files A and B got renamed to X/A and X/B by pairing A to X/A and B
to X/B, but this was broken in the 2.0 timeframe.
* sg/diff-multiple-identical-renames:
diffcore: fix iteration order of identical files during rename detection
When "git worktree" feature is in use, "git branch -d" allowed
deletion of a branch that is checked out in another worktree
* ky/branch-d-worktree:
branch -d: refuse deleting a branch which is currently checked out
"git worktree add" can be given "--no-checkout" option to only
create an empty worktree without checking out the files.
* rz/worktree-no-checkout:
worktree: add: introduce --checkout option
The commit object name reported when "rebase -i" stops has been
shortened.
* rt/rebase-i-shorten-stop-report:
rebase-i: print an abbreviated hash when stop for editing
The repository set-up sequence has been streamlined (the biggest
change is that there is no longer git_config_early()), so that we
do not attempt to look into refs/* when we know we do not have a
Git repository.
* jk/check-repository-format:
verify_repository_format: mark messages for translation
setup: drop repository_format_version global
setup: unify repository version callbacks
init: use setup.c's repo version verification
setup: refactor repo format reading and verification
config: drop git_config_early
check_repository_format_gently: stop using git_config_early
lazily load core.sharedrepository
wrap shared_repository global in get/set accessors
setup: document check_repository_format()
With one exception, we require the index to exactly match the
current HEAD commit at the time git merge is invoked. This
expectation was even documented in git-merge.txt until commit
ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23).
Most merge strategies enforced this requirement, but it turns out
not all did. The current exceptions were the following two:
* ff updates
* octopus merges
ff updates actually will error out if the staged change is to a path
modified between HEAD and the commit being merged. If the path(s)
that are staged are files unrelated to the changes between these two
commits, though, then an ff update will just keep these staged
changes around after the merge. This is the one exception we
expected to the abort-merge-if- index-doesn't-match-HEAD rule.
For octopus merges, the rule should be enforced. Unfortunately, the
current behavior of the code is to ignore the difference and use the
staged changes in place of whatever is in HEAD as it proceeds to
perform the merge. So if the staged changes can be cleanly merged
with all the other heads, then the staged changes will just be
incorported into the resulting commit. If the staged changes cannot
be cleanly merged with all the other heads, the merge is not aborted
-- merge conflicts are simply reported as if HEAD had originally
contained whatever the index did.
Add testcases that check our expectations. A subsequent commit will
correct the erroneous octopus merge behavior.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If read_tree_trivial() succeeds and produces a tree that is already
in the object store, then the index is not written to disk, leaving
it out-of-sync with both HEAD and the working tree.
In order to write the index back out to disk after a merge,
write_index_locked() needs to be called. For most merge strategies, this
is done from try_merge_strategy(). For fast forward updates, this is
done from checkout_fast_forward(). When trivial merges work, the call to
write_index_locked() is buried a little deeper:
merge_trivial()
-> write_tree_trivial()
-> write_cache_as_tree()
-> write_index_as_tree()
-> write_locked_index()
However, it is only called when !cache_tree_fully_valid(), which is how
this bug is triggered. But that also shows why this bug doesn't affect
any other merge strategies or cases.
Add a direct call to write_index_locked() from merge_trivial() to fix
this issue. Since the indirect call to write_locked_index() was
conditional on cache_tree_fully_valid(), it won't be written twice.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Repeating a trivial merge more than once will leave the index out of
sync, despite being clean before the merge and operating on the
exact same heads as the first run. The recorded merge has the
correct tree and the working tree is brought up to date, it is just
the index that is left as it was before the merge. Every attempt to
repeat the merge beyond the first will leave the index in the same
weird out-of-sync state.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were a few cases in merge-recursive that could result in a
check for the presence of files in the working copy while trying to
create a virtual merge base. These were rare and innocuous, but
somewhat illogical. The two cases were:
* When there was naming conflicts (e.g. a D/F conflict) and we had to
pick a new unique name for a file. Since the new name is somewhat
arbitrary, it didn't matter that we consulted the working copy to
avoid picking a filename it has, but since the virtual merge base is
never checked out, it's a waste of time and slightly odd to do so.
* When two different files get renamed to the same name (on opposite
sides of the merge), we needed to delete the original filenames from
the cache and possibly also the working directory. The caller's check
for determining whether to delete from the working directory was a
call to would_lose_untracked(). It turns out this didn't matter
because remove_file() had logic to avoid modifying the working
directory when creating a virtual merge base, but there is no reason
for the caller to check the working directory in such circumstances.
It's a waste of time, if not also a bit weird.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit 51931bf (merge-recursive: Improve handling of rename
target vs. directory addition, 2011-08-11), I apparently added two
lines of code that were immediately duplicated a few lines later.
No idea why, other than it seems pretty clear this was a mistake:
there is no need to remove the same file twice; removing it once is
sufficient...especially since the intervening line was working with
a different file entirely.
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test uses hardcoded #!/bin/sh to create a pre-commit hook
script. Because the generated script uses $(command substitution),
which is not supported by /bin/sh on some platforms (e.g. Solaris),
the resulting pre-commit always fails.
Which is not noticeable as the test that uses the hook is about
checking the behaviour of the command when the hook fails ;-), but
nevertheless it is not testing what we wanted to test.
Use write_script so that the resulting script is run under the same
shell our scripted Porcelain commands are run, which must support
the necessary $(construct).
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test prepares a sample file "dir/two" with a single incomplete
line in it with "printf", and also prepares a small helper script
"diff" to create a file with a single incomplete line in it, again
with "printf". The output from the latter is compared with an
expected output, again prepared with "printf" hence lacking the
final LF. There is no reason for this test to be using files with
an incomplete line at the end, and these look more like a mistake
of not using
printf "%s\n" "string to be written"
and using
printf "string to be written"
Depending on what would be in $GIT_PREFIX, using the latter form
could be a bug waiting to happen. Correct them.
Also, the test uses hardcoded #!/bin/sh to create a small helper
script. For a small task like what the generated script does, it
does not matter too much in that what appears as /bin/sh would not
be _so_ broken, but while we are at it, use write_script instead,
which happens to make the result easier to read by reducing need
of one level of quoting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The recent cleanup in b7cbbff switched t5532's use of
backticks to $(). This matches our normal shell style, which
is good. But it also breaks the test on Solaris, where
/bin/sh does not understand $().
Our normal shell style assumes a modern-ish shell which
knows about $(). However, some tests create small helper
scripts and just write "#!/bin/sh" into them. These scripts
either need to go back to using backticks, or they need to
respect $SHELL_PATH. The easiest way to do the latter is to
use write_script.
While we're at it, let's also stick the script creation
inside a test_expect block (our usual style), and split the
perl snippet into its own script (to prevent quoting
madness).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When locking a symbolic ref to expire a reflog, lock the symbolic
ref (using REF_NODEREF) instead of its referent.
Add a test for this.
Signed-off-by: David Turner <dturner@twopensource.com>
Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that resolve_ref_unsafe's only interaction with the backend is
through read_raw_ref, we can move it into the common code. Later,
we'll replace read_raw_ref with a backend function.
Signed-off-by: David Turner <dturner@twopensource.com>
Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only use the result of resolve_ref_namespace() if it is non-NULL.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If there is an error in resolve_ref_unsafe(), it returns NULL. We check
for this case, but not until after calling strip_namespace(). Instead,
call strip_namespace() *after* the NULL check.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is never read, so we can pass NULL to resolve_ref_unsafe().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is never read, so we can pass NULL to resolve_ref_unsafe().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is never read, so we can pass NULL to resolve_ref_unsafe().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read_raw_ref() is going to be part of the vtable for reference backends,
so clean up its interface to use "unsigned int flags" rather than "int
flags". Its caller still uses signed int for its flags arguments. But
changing that would touch a lot of code, so leave it for now.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref_unsafe() wasn't doing anything useful anymore.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of creating scratch space in resolve_ref_unsafe() and passing
it down through resolve_ref_1 to read_raw_ref(), teach read_raw_ref()
to manage its own scratch space. This reduces coupling across the
functions at the cost of some extra allocations.
Also, when read_raw_ref() is implemented for different reference
backends, the other implementations might have different scratch
space requirements.
Note that we now preserve errno across the calls to strbuf_release(),
which calls free() and can thus theoretically overwrite errno.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor resolve_ref_1 in terms of a new function read_raw_ref, which
is responsible for reading ref data from the ref storage.
Later, we will make read_raw_ref a pluggable backend function, and make
resolve_ref_unsafe common.
Signed-off-by: David Turner <dturner@twopensource.com>
Helped-by: Duy Nguyen <pclouds@gmail.com>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We can use (*flags & REF_BAD_NAME) for that purpose.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano