From: Torsten Bögershausen
On HFS (which is the default Mac filesystem prior to High Sierra),
unicode names are "decomposed" before recording.
On APFS, which appears to be the new default filesystem in Mac OS High
Sierra, filenames are recorded as specified by the user.
APFS continues to allow t
"brian m. carlson" writes:
> On Sun, Apr 29, 2018 at 09:40:13PM -0400, Patrick Hemmer wrote:
>> When you use `git format-patch --cover-letter --attach`, the cover
>> letter does not have the trailing MIME boundary. RFC2046 states that the
>> last part must be followed by a closing boundary. This
What's cooking in git.git (Apr 2018, #04; Mon, 30)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear i
On Sun, Apr 29, 2018 at 6:19 PM, Johannes Schindelin
wrote:
> These were not caught by the previous commit, as they did not match the
> regular expression.
>
> Signed-off-by: Johannes Schindelin
> ---
> diff --git a/submodule.c b/submodule.c
> @@ -2043,7 +2043,7 @@ const char *get_superproject_wo
On Sun, Apr 29, 2018 at 09:40:13PM -0400, Patrick Hemmer wrote:
> When you use `git format-patch --cover-letter --attach`, the cover
> letter does not have the trailing MIME boundary. RFC2046 states that the
> last part must be followed by a closing boundary. This causes some email
> clients (Thund
When you use `git format-patch --cover-letter --attach`, the cover
letter does not have the trailing MIME boundary. RFC2046 states that the
last part must be followed by a closing boundary. This causes some email
clients (Thunderbird in my case) to discard the message body.
This is experienced with
Johannes Schindelin writes:
> While working on the --convert-graft-file test, I missed that I was
> relying on the GPG prereq, by using output of test cases that were only
> run under that prereq.
>
> For debugging, it was really convenient to force that prereq to be
> unmet, but there was no eas
Thomas Gummerer writes:
> On 04/27, Eric Sunshine wrote:
>> On Tue, Apr 24, 2018 at 5:56 PM, Thomas Gummerer
>> wrote:
>> > Thanks Eric for the review and the suggestions on the previous round.
>> >
>> > Changes since the previous round:
>> >
>> > - UNLEAK new_branch after it was xstrndup'd
>>
Eric Sunshine writes:
> On Wed, Apr 25, 2018 at 4:37 AM, Junio C Hamano wrote:
>> * tg/worktree-add-existing-branch (2018-04-25) 4 commits
>> - worktree: teach "add" to check out existing branches
>> - worktree: factor out dwim_branch function
>> - worktree: improve message when creating a ne
Duy Nguyen writes:
> Target revision should be available in the index. But this gives me an
> idea to another thing that bugs me: sending the list to the hook means
> I have to deal with separator (\n or NUL?) or escaping. This mentions
> of index makes me take a different direction. I could prod
Elijah Newren writes:
> Here's a crazy idea -- maybe instead of a list of pathspecs you just
> provide the timestamp of when git checkout started. Then the hook
> could walk the tree, find all files with modification times at least
> that late, and modify them all back to the the timestamp of wh
These were not caught by the previous commit, as they did not match the
regular expression.
Signed-off-by: Johannes Schindelin
---
git-compat-util.h | 2 +-
pathspec.c| 2 +-
submodule.c | 2 +-
vcs-svn/fast_export.c | 6 --
4 files changed, 7 insertions(+), 5 delet
In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro
was introduced to use for reporting bugs instead of die(). It was then
subsequently used to convert one single caller in 588a538ae55
(setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
The cover letter of the patch series
We just prepared t1406 to be okay with BUG reports resulting in SIGABRT
instead of a regular exit code indicating failure. This commit now makes
it so: by calling BUG() (which eventually calls `abort()`), we no longer
exit with code 128 but instead throw that signal.
This trick was performed by th
[Forgot about one thing]
Derrick Stolee writes:
> Create new load_commit_graph_info() method to fill in the information
> for a commit that exists only in the commit-graph file.
The above sentence is a bit hard to parse because of ambiguity: is it
"the information" that exists only in the commi
The slightly misleading name die_bug() of the function intended to
report a bug is actually called always, and only reports a bug if the
passed-in parameter `err` is non-zero.
It uses die_errno() to report the bug, to helpfully include the error
message corresponding to `err`.
However, as these m
t1406 specifically verifies that certain code paths fail with a BUG: ...
message.
In the upcoming commit, we will convert that message to be generated via
BUG() instead of die("BUG: ..."), which implies SIGABRT instead of a
regular exit code.
Signed-off-by: Johannes Schindelin
---
t/t1406-submo
In the upcoming patch, we will prepare t1406 to handle the conversion of
refs/files-backend.c to call BUG() instead of die("BUG: ..."). This will
require handling SIGABRT as valid failure case.
Signed-off-by: Johannes Schindelin
---
t/test-lib-functions.sh | 5 -
1 file changed, 4 insertions
The BUG() macro was introduced in this patch series:
https://public-inbox.org/git/20170513032414.mfrwabt4hovuj...@sigill.intra.peff.net
The second patch in that series converted one caller from die("BUG: ")
to use the BUG() macro.
It seems that there was no concrete plan to address the same issue
Derrick Stolee writes:
> Most code paths load commits using lookup_commit() and then
> parse_commit().
And this automatically loads commit graph if needed, thanks to changes
in parse_commit_gently(), which parse_commit() uses.
> In some cases, including some branch lookups, the
Hi Johannes,
thanks for taking your time to explain things. It shows I am not
familiar with the rebase code, yet.
>
> Having said that, *this* time round, what we need to do is actually very
> similar to what builtin/am.c's read_author_script() does (even if we
> cannot use it as-is: it populates
Hi Duy,
On Sun, 29 Apr 2018, Duy Nguyen wrote:
> On Tue, Apr 24, 2018 at 8:50 AM, Elijah Newren wrote:
> > Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
> > The code in unpack_trees() does not correctly handle them being different.
> > There are two separate issues:
On Fri, Apr 27 2018, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Apr 24, 2018 at 9:57 PM, Wink Saville wrote:
>> If have a repository with a tag "v1.0.0" and I add a remote repository
>> which also has a tag "v1.0.0" tag is overwritten.
>
> I feel like this thread has gotten somewhat side-tracked by
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.
This changes the long-standing behavior of "fetch" added in
853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20), before this
change all tag fetches effectively had --force enabled. The or
The test suite only incidentally (and unintentionally) tested for the
current behavior of eager tag clobbering on "fetch". This follow-up to
the previous "push tests: assert re-pushing annotated tags" change
tests for it explicitly.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5516-fetch-push.s
Improve the tests added in dbfeddb12e ("push: require force for refs
under refs/tags/", 2012-11-29) to assert that the same behavior
applies various forms other refspecs, and that "+" in a refspec will
override the "--no-force" option (but not the other way around).
Signed-off-by: Ævar Arnfjörð Bj
There's complex rules governing whether a push is allowed to take
place depending on whether we're pushing to refs/heads/*, refs/tags/*
or refs/not-that/*. See is_branch() in refs.c, and the various
assertions in refs/files-backend.c. (e.g. "trying to write non-commit
object %s to branch '%s'").
T
Change the test that asserts that lightweight tags can only be
clobbered by a force-push to check do the same tests for annotated
tags.
There used to be less exhaustive tests for this with the code added in
40eff17999 ("push: require force for annotated tags", 2012-11-29), but
Junio removed them i
Remove an invocation of 'git push' that's exactly the same as the one
on the preceding line. This was seemingly added by mistake in
dbfeddb12e ("push: require force for refs under refs/tags/",
2012-11-29) and doesn't affect the result of the test, the second
"push" was a no-op as there was nothing
Correct a comment referring to the removal of just the branch to also
refer to the tag. This should have been changed in my
ca3065e7e7 ("fetch tests: add a tag to be deleted to the pruning
tests", 2018-02-09) when the tag deletion was added, but I missed it
at the time.
Signed-off-by: Ævar Arnfjör
Fix a logic error that's been here since this test was added in
dbfeddb12e ("push: require force for refs under refs/tags/",
2012-11-29).
The intent of this test is to force-create a new tag pointing to
HEAD~, and then assert that pushing it doesn't work without --force.
Instead, the code was not
Phillip (and others) the changes in this patch make "git help -g" now
lists a lot more guides than just the "common" one as advertised (see
below for the exact list). The man page for "git help -g" also
mentions that it would list "useful" guides, not all guides. But we
have no way to list all guid
The previous commit added code generation for all_cmd_desc[] which
includes almost everything we need to generate common command list.
Convert help code to use that array instead and drop common_cmds[] array.
The description of each common command group is removed from
command-list.txt. This keeps
This lists all recognized commands [1] by category. The group order
follows closely git.txt.
[1] We may actually show commands that are not built (e.g. if you set
NO_PERL you don't have git-instaweb but it's still listed here). I
ignore the problem because on Linux a git package could be split
any
The help command currently hard codes the list of guides and their
summary in C. Let's move this list to command-list.txt. This lets us
extract summary lines from Documentation/git*.txt. This also
potentially lets us list guides in git.txt, but I'll leave that for
now.
Signed-off-by: Nguyễn Thái N
I think v5 is getting close to what I wanted to achieve from the RFC
version (I skip v4 since I sent out v4/wip and another v4 may confuse
people).
Interdiff is too large to be helpful, but the summary of changes
compared to v3 is:
- common-cmds.h is renamed to command-list.h
- the common group d
The current generate-cmds.sh generates just enough to print "git help"
output. That is, it only extracts help text for common commands.
The script is now updated to extract help text for all commands and
keep command classification a new file, command-list.h. This will be
useful later:
- "git hel
This allows us to select any group of commands by a category defined
in command-list.txt. This is an internal/hidden option so we don't
have to be picky about the category name or worried about exposing too
much.
This will be used later by git-completion.bash to retrieve certain
command groups.
S
After the last patch, common-cmds.h is no longer used (and it was
actually broken). Remove all related code. command-list.h will take
its place from now on.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
.gitignore | 1 -
Makefile| 17 ++---
generate-cmdlist.sh | 46 ++
Even if these are hidden options, let's make them a bit more generic
since we're introducing more listing types shortly.
This also allows combining multiple listing types, which is usually
now (for combining parseopt and builtins) but future types will
benefit from this.
Signed-off-by: Nguyễn Thá
Instead of parsing "git help -a" output, which is tricky to get right,
less elegant and also slow, make git provide the list in a
machine-friendly form. This adds two separate listing types, main and
others, instead of just "all" for more flexibility.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cont
Instead of maintaining a separate list of command classification,
which often could go out of date, let's centralize the information
back in git.
While the function in git-completion.bash implies "list porcelain
commands", that's not exactly what it does. It gets all commands (aka
--list-cmds=main
This makes it easier to reuse the same code in another place (very
soon).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
generate-cmdlist.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index eeea4b67ea..31b6d886cb 100
On Tue, Apr 24, 2018 at 8:50 AM, Elijah Newren wrote:
> Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
> The code in unpack_trees() does not correctly handle them being different.
> There are two separate issues:
>
> First, there is the possibility of memory corruption.
In this small patch I want to introduce a way to dynamically load completion
scripts for external subcommands.
A few years ago, you would put a completion script (which defines a Bash
function _git_foo for a custom git subcommand foo) into
/etc/bash_completion.d, or save it somewhere in your $H
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can b
On Wed, Apr 25, 2018 at 8:07 PM, Eric Sunshine wrote:
> On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy
> wrote:
>> The current generate-cmds.sh generates just enough to print "git help"
>> output. That is, it only extracts help text for common commands.
>>
>> The script is now updated to
Hello Dear
Greetings to you, please I have a very important business proposal for our
mutual benefit, please let me know if you are interested.
Best Regards,
Miss. Zeliha ömer Faruk
Caddesi Kristal Kule Binasi
No:215
Derrick Stolee writes:
> Define compare_commits_by_gen_then_commit_date(), which uses generation
> numbers as a primary comparison and commit date to break ties (or as a
> comparison when both commits do not have computed generation numbers).
All right, this looks reasonable thing to do when we
On 2018-04-29 15:08, SZEDER Gábor wrote:
On Sun, Apr 29, 2018 at 1:15 PM, Florian Gamböck
wrote:
I sense a problem here. If I have a directory with a file xyzfoobar
in it, and I type `git xyz`, with no defined subcommand that starts
with these letters, then minimal bashcomp would give me `git
On Sun, Apr 29, 2018 at 1:15 PM, Florian Gamböck wrote:
> On 2018-04-25 16:40, SZEDER Gábor wrote:
>>
>> In my previous emails I overlooked the _completion_loader() helper
>> function.
>>
>> It seems that this function does almost exactly what we want. It was
>> introduced along with dynamic comp
Hi,
On Sun, 29 Apr 2018, Paul-Sebastian Ungureanu wrote:
> > > Since there seems to be interest from GSOC students who want to
> > > work on converting builtins, I figured I should finish what I
> > > have that works now so they could build on top of it.
>
> First of all, I must thank you for su
Hi Stefan,
On Sat, 28 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 27, 2018 at 3:31 PM, Johannes Schindelin
> wrote:
> > In this developer's earlier attempt to accelerate interactive rebases by
> > converting large parts from Unix shell script into portable, performant
> > C, the --root handling
Hi Stefan,
On Sat, 28 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 27, 2018 at 3:31 PM, Johannes Schindelin
> wrote:
> > When an interactive rebase wants to recreate a root commit, it
> > - first creates a new, empty root commit,
> > - checks it out,
> > - converts the next `pick` command so tha
On 2018-04-25 16:40, SZEDER Gábor wrote:
In my previous emails I overlooked the _completion_loader() helper
function.
It seems that this function does almost exactly what we want. It was
introduced along with dynamic completion loading back in 20c05b43, so
it's available for us even in older
Derrick Stolee writes:
> While preparing commits to be written into a commit-graph file, compute
> the generation numbers using a depth-first strategy.
Sidenote: for generation numbers it does not matter if we use
depth-first or breadth-first strategy, but it is more natural to use
depth-first s
56 matches
Mail list logo
