Re: Bug: format-patch MIME boundary not added to cover letter when attach enabled

"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

What's cooking in git.git (Apr 2018, #04; Mon, 30)

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

Re: [PATCH 6/6] Convert remaining die*(BUG) messages

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

Re: Bug: format-patch MIME boundary not added to cover letter when attach enabled

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

Bug: format-patch MIME boundary not added to cover letter when attach enabled

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

Re: [PATCH] tests: introduce test_unset_prereq, for debugging

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

Re: [PATCH v9 0/4] worktree: teach "add" to check out existing branches

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: >> > >> > -

Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

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 >> -

Re: [RFC PATCH] checkout: Force matching mtime between files

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

Re: [RFC PATCH] checkout: Force matching mtime between files

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

[PATCH 6/6] Convert remaining die*(BUG) messages

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

[PATCH 5/6] Replace all die("BUG: ...") calls by BUG() ones

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

[PATCH 3/6] refs/*: report bugs using the BUG() macro

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

Re: [PATCH v4 05/10] commit-graph: always load commit-graph information

[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

[PATCH 4/6] run-command: use BUG() to report bugs, not die()

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

[PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

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

[PATCH 1/6] test_must_fail: support ok=sigabrt

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 -

[PATCH 0/6] Finish the conversion from die("BUG: ...") to BUG()

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

Re: [PATCH v4 05/10] commit-graph: always load commit-graph information

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

Re: [PATCH 2/6] sequencer: learn about the special "fake root commit" handling

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

Re: [PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

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

[PATCH 0/8] "git fetch" should not clobber existing tags without --force

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

[PATCH 8/8] fetch: stop clobbering existing tags without --force

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

[PATCH 3/8] push tests: add more testing for forced tag pushing

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ð

[PATCH 5/8] push doc: correct lies about how push refspecs work

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'").

[PATCH 7/8] fetch tests: add a test clobbering tag behavior

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 ---

[PATCH 6/8] fetch tests: correct a comment "remove it" -> "remove them"

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

[PATCH 4/8] push tests: assert re-pushing annotated tags

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

[PATCH 1/8] push tests: remove redundant 'git push' invocation

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

[PATCH 2/8] push tests: fix logic error in "push" test assertion

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

Re: [PATCH v5 09/10] help: use command-list.txt for the source of guides

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

[PATCH v5 03/10] help: use command-list.h for common command list

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

[PATCH v5 08/10] help: add "-a --verbose" to list all commands with synopsis

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

[PATCH v5 09/10] help: use command-list.txt for the source of guides

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

[PATCH v5 00/10] Keep all info in command-list.txt in git binary

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

[PATCH v5 02/10] generate-cmds.sh: export all commands to command-list.h

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

[PATCH v5 07/10] git: support --list-cmds=list-

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.

[PATCH v5 04/10] Remove common-cmds.h

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 ++---

[PATCH v5 05/10] git.c: convert --list-*builtins to --list-cmds=*

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

[PATCH v5 06/10] completion: implement and use --list-cmds=main,others

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

[PATCH v5 10/10] completion: let git provide the completable command list

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

[PATCH v5 01/10] generate-cmds.sh: factor out synopsis extract code

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

Re: [PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

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

[PATCH v3 0/1] completion: dynamic completion loading

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

[PATCH v3 1/1] completion: load completion file for external subcommand

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

Re: [PATCH v4/wip 02/12] generate-cmds.sh: export all commands to command-list.h

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

Proposal

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

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

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

Re: [PATCH v2 1/1] completion: load completion file for external subcommand

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

Re: [PATCH v2 1/1] completion: load completion file for external subcommand

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

Re: [PATCH v5 0/5] Convert some stash functionality to a builtin

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

Re: [PATCH 3/6] rebase -i --root: let the sequencer handle even the initial part

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,

Re: [PATCH 2/6] sequencer: learn about the special "fake root commit" 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

Re: [PATCH v2 1/1] completion: load completion file for external subcommand

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

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

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