| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Test fixes.
* en/test-cleanup:
t6022, t6046: fix flaky files-are-updated checks
|
|
An earlier update to show the location of working tree in the error
message did not consider the possibility that a git command may be
run in a bare repository, which has been corrected.
* es/outside-repo-errmsg-hints:
prefix_path: show gitdir if worktree unavailable
|
|
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
|
|
- context should be translated to ngữ cảnh instead of nội dung
- add missing accents
- switch adjective and secondary objects position:
* The formatted English text will be "To remove '+/-' lines",
it should be translated to "Để bỏ dòng bắt đầu với '+/-'
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
|
|
If there is no worktree at present, we can still hint the user about
Git's current directory by showing them the absolute path to the Git
directory. Even though the Git directory doesn't make it as easy to
locate the worktree in question, it can still help a user figure out
what's going on while developing a script.
This fixes a segmentation fault introduced in e0020b2f
("prefix_path: show gitdir when arg is outside repo", 2020-02-14).
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
[jc: added minimum tests, with help from Szeder Gábor]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Revision 2.
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
|
|
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
|
|
Askpass can now send non-ASCII to Git on Windows.
* js/askpass-coerce-utf8:
git-gui--askpass: coerce answers to UTF-8 on Windows
|
|
This addresses the issue where Git for Windows asks the user for a
password, no credential helper is available, and then Git fails to pick
up non-ASCII characters from the Git GUI helper.
This can be verified e.g. via
echo host=http://abc.com |
git -c credential.helper= credential fill
and then pasting some umlauts.
The underlying reason is that Git for Windows tries to communicate using
the UTF-8 encoding no matter what the actual current code page is. So
let's indulge Git for Windows and do use that encoding.
This fixes https://github.com/git-for-windows/git/issues/2215
Signed-off-by: Luke Bonanomi <lbonanomi@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
|
|
Fixes an error popup in blame because of a missing closing bracket.
* py/blame-status-error:
git-gui: fix error popup when doing blame -> "Show History Context"
|
|
Several tests wanted to verify that files were actually modified by a
merge, which it would do by checking that the mtime was updated. In
order to avoid problems with the merge completing so fast that the mtime
at the beginning and end of the operation was the same, these tests
would first set the mtime of a file to something "old". This "old"
value was usually determined as current system clock minus one second,
truncated to the nearest integer. Unfortunately, it appears the system
clock and filesystem clock are different and comparing across the two
runs into race problems resulting in flaky tests.
From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond:
date will call the gettimeofday system call which will always return
the most accurate time available based on the cached kernel time,
adjusted by the CPU cycle time if available to give nanosecond
resolution. The timestamps stored in the file system however, are
only based on the cached kernel time. ie The time calculated at the
last timer interrupt.
and from https://apenwarr.ca/log/20181113:
Does mtime get set to >= the current time?
No, this depends on clock granularity. For example, gettimeofday()
can return times in microseconds on my system, but ext4 rounds
timestamps down to the previous ~10ms (but not exactly 10ms)
increment, with the surprising result that a newly-created file is
almost always created in the past:
$ python -c "
import os, time
t0 = time.time()
open('testfile', 'w').close()
print os.stat('testfile').st_mtime - t0
"
-0.00234484672546
So, instead of trying to compare across what are effectively two
different clocks, just avoid using the system clock. Any new updates to
files have to give an mtime at least as big as what is already in the
file, so we could define "old" as one second before the mtime found in
the file before the merge starts. But, to avoid problems with leap
seconds, ntp updates, filesystems that only provide two second
resolution, and other such weirdness, let's just pick an hour before the
mtime found in the file before the merge starts.
Also, clarify in one test where we check the mtime of different files
that it really was intentional. I totally forgot the reasons for that
and assumed it was a bug when asked.
Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Band-aid fixes for two fallouts from switching the default "rebase"
backend.
* en/rebase-backend:
git-rebase.txt: highlight backend differences with commit rewording
sequencer: clear state upon dropping a become-empty commit
i18n: unmark a message in rebase.c
|
|
* 'next' of github.com:ChrisADR/git-po:
l10n: es: 2.26.0 round#2
|
|
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
|
|
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
|
|
* 'git-l10n_git-po_master' of github.com:alshopov/git-po:
l10n: bg.po: Updated Bulgarian translation (4839t)
|
|
* 'tr_translations_2.26.1' of github.com:bitigchi/git-po:
l10n: tr: v2.26.0 round 2
|
|
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
|
|
Signed-off-by: Emir Sarı <bitigchi@me.com>
|
|
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
|
|
As noted by Junio:
Back when "git am" was written, it was not considered a bug that the
"git am --resolved" option did not offer the user a chance to update
the log message to match the adjustment of the code the user made,
but honestly, I'd have to say that it is a bug in "git am" in that
over time it wasn't adjusted to the new world order where we
encourage users to describe what they did when the automation
hiccuped by opening an editor. These days, even when automation
worked well (e.g. a clean auto-merge with "git merge"), we open an
editor. The world has changed, and so should the expectations.
Junio also suggested providing a workaround such as allowing --no-edit
together with git rebase --continue, but that should probably be done in
a patch after the git-2.26.0 release. For now, just document the known
difference in the Behavioral Differences section.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
In commit e98c4269c8 ("rebase (interactive-backend): fix handling of
commits that become empty", 2020-02-15), the merge backend was changed
to drop commits that did not start empty but became so after being
applied (because their changes were a subset of what was already
upstream). This new code path did not need to go through the process of
creating a commit, since we were dropping the commit instead.
Unfortunately, this also means we bypassed the clearing of the
CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further
commits to cherry-pick would mean that the rebase would end but assume
there was still an operation in progress. Ensure that we clear such
state files when we decide to drop the commit.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Commit v2.25.0-4-ge98c4269c8 (rebase (interactive-backend): fix handling
of commits that become empty, 2020-02-15) marked "{drop,keep,ask}" for
translation, but this message should not be changed.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Test fix.
* ds/sparse-add:
t1091: don't grep for `strerror()` string
|
|
Code clean-up.
* dr/push-remote-ref-update:
remote: drop "explicit" parameter from remote_ref_for_branch()
|
|
Both "git ls-remote -h" and "git grep -h" give short usage help,
like any other Git subcommand, but it is not unreasonable to expect
that the former would behave the same as "git ls-remote --head"
(there is no other sensible behaviour for the latter). The
documentation has been updated in an attempt to clarify this.
* jc/doc-single-h-is-for-help:
Documentation: clarify that `-h` alone stands for `help`
|
|
Generate po/git.pot from v2.26.0-rc1 for git v2.26.0 l10n round 2.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
|
|
* 'master' of github.com:git/git: (27 commits)
Git 2.26-rc1
remote-curl: show progress for fetches over dumb HTTP
show_one_mergetag: print non-parent in hex form.
config.mak.dev: re-enable -Wformat-zero-length
rebase-interactive.c: silence format-zero-length warnings
mingw: workaround for hangs when sending STDIN
t6020: new test with interleaved lexicographic ordering of directories
t6022, t6046: test expected behavior instead of testing a proxy for it
t3035: prefer test_must_fail to bash negation for git commands
t6020, t6022, t6035: update merge tests to use test helper functions
t602[1236], t6034: modernize test formatting
merge-recursive: apply collision handling unification to recursive case
completion: add diff --color-moved[-ws]
t1050: replace test -f with test_path_is_file
am: support --show-current-patch=diff to retrieve .git/rebase-apply/patch
am: support --show-current-patch=raw as a synonym for--show-current-patch
am: convert "resume" variable to a struct
parse-options: convert "command mode" to a flag
parse-options: add testcases for OPT_CMDMODE()
stash push: support the --pathspec-from-file option
...
|
|
Signed-off-by: Emir Sarı <bitigchi@me.com>
|
|
Ever since 862e730ec1 (commit-slab: introduce slabname##_peek()
function, 2015-05-14) the slabname##_peek() function is documented as:
This function is similar to indegree_at(), but it will return NULL
until a call to indegree_at() was made for the commit.
This, however, is usually not the case. If indegree_at() allocates
memory, then it will do so not only for the single commit it got as
parameter, but it will allocate a whole new, ~512kB slab. Later on,
if any other commit's 'index' field happens to point into an already
allocated slab, then indegree_peek() for such a commit will return a
valid non-NULL pointer, pointing to a zero-initialized location in the
slab, even if no indegree_at() call has been made for that commit yet.
Update slabname##_peek()'s documentation to clarify this.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Together with the previous commits, this commit fully fixes the problem
of using shared buffer for `real_path()` in `get_superproject_working_tree()`.
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This commit continues the work started with previous commit.
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Returning a shared buffer invites very subtle bugs due to reentrancy or
multi-threading, as demonstrated by the previous patch.
There was an unfinished effort to abolish this [1].
Let's finally rid of `real_path()`, using `strbuf_realpath()` instead.
This patch uses a local `strbuf` for most places where `real_path()` was
previously called.
However, two places return the value of `real_path()` to the caller. For
them, a `static` local `strbuf` was added, effectively pushing the
problem one level higher:
read_gitfile_gently()
get_superproject_working_tree()
[1] https://lore.kernel.org/git/1480964316-99305-1-git-send-email-bmwill@google.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Python2 reached end of life, and we have been preparing our Python
scripts to work with Python3. 'git p4', the main in-tree user of
Python, has just received a number of compatibility updates. Our
other notable Python script 'contrib/svn-fe/svnrdump_sim.py' is only
used in 't9020-remote-svn.sh', and is apparently already compatible
with both Python2 and 3.
Our CI jobs currently only use Python2. We want to make sure that
these Python scripts do indeed work with Python3, and we also want to
make sure that these scripts keep working with Python2 as well, for
the sake of some older LTS/Enterprise setups.
Therefore, pick two jobs and use Python3 there, while leaving other
jobs to still stick to Python2 for now.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* 'master' of github.com:nafmo/git-l10n-sv:
l10n: sv.po: Update Swedish translation (4835t0f0u)
|
|
* 'fr_2.26.0' of github.com:jnavila/git:
l10n: fr v2.26.0 rnd1
|
|
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
|
|
Signed-off-by: Emir Sarı <bitigchi@me.com>
|
|
Signed-off-by: Emir Sarı <bitigchi@me.com>
|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
"git fetch" over HTTP walker protocol did not show any progress
output. We inherently do not know how much work remains, but still
we can show something not to bore users.
* rs/show-progress-in-dumb-http-fetch:
remote-curl: show progress for fetches over dumb HTTP
|
|
"git show" and others gave an object name in raw format in its
error output, which has been corrected to give it in hex.
* hd/show-one-mergetag-fix:
show_one_mergetag: print non-parent in hex form.
|
|
Recently we inadvertently added a few instances of using 0-width
format string to functions that we mark as printf-like without any
developers noticing. The root cause was that the compiler warning
that is triggered by this is almost always useless and we disabled
the warning in our developer builds, but not for general public.
The new instances have been corrected, and the warning has been
resurrected in the developer builds.
* rt/format-zero-length-fix:
config.mak.dev: re-enable -Wformat-zero-length
rebase-interactive.c: silence format-zero-length warnings
|
|
MinGW's poll() emulation has been improved.
* am/mingw-poll-fix:
mingw: workaround for hangs when sending STDIN
|
|
Test cleanup.
* en/test-cleanup:
t6020: new test with interleaved lexicographic ordering of directories
t6022, t6046: test expected behavior instead of testing a proxy for it
t3035: prefer test_must_fail to bash negation for git commands
t6020, t6022, t6035: update merge tests to use test helper functions
t602[1236], t6034: modernize test formatting
|
|
Handling of conflicting renames in merge-recursive have further
been made consistent with how existing codepaths try to mimic what
is done to add/add conflicts.
* en/merge-path-collision:
merge-recursive: apply collision handling unification to recursive case
|
|
Completion update.
* kk/complete-diff-color-moved:
completion: add diff --color-moved[-ws]
|
|
Code cleanup.
* rj/t1050-use-test-path-is-file:
t1050: replace test -f with test_path_is_file
|
