[PATCH v6 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Elijah Newren
Automatic re-encoding of commit messages (and dropping of the encoding header) hurts attempts to do reversible history rewrites (e.g. sha1sum <-> sha256sum transitions, some subtree rewrites), and seems inconsistent with the general principle followed elsewhere in fast-export of requiring explicit

[PATCH v6 4/5] fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8

2019-05-13 Thread Elijah Newren
The find_encoding() function returned the encoding used by a commit message, returning a default of git_commit_encoding (usually UTF-8). Although the current code does not differentiate between a commit which explicitly requested UTF-8 and one where we just assume UTF-8 because no encoding is set,

[PATCH v6 1/5] t9350: fix encoding test to actually test reencoding

2019-05-13 Thread Elijah Newren
This test used an author with non-ascii characters in the name, but no special commit message. It then grep'ed for those non-ascii characters, but those are guaranteed to exist regardless of the reencoding process since the reencoding only affects the commit message, not the author or committer na

[PATCH v6 2/5] fast-import: support 'encoding' commit header

2019-05-13 Thread Elijah Newren
Since git supports commit messages with an encoding other than UTF-8, allow fast-import to import such commits. This may be useful for folks who do not want to reencode commit messages from an external system, and may also be useful to achieve reversible history rewrites (e.g. sha1sum <-> sha256su

[PATCH v6 3/5] fast-export: avoid stripping encoding header if we cannot reencode

2019-05-13 Thread Elijah Newren
When fast-export encounters a commit with an 'encoding' header, it tries to reencode in UTF-8 and then drops the encoding header. However, if it fails to reencode in UTF-8 because e.g. one of the characters in the commit message was invalid in the old encoding, then we need to retain the original

[PATCH v6 0/5] Fix and extend encoding handling in fast export/import

2019-05-13 Thread Elijah Newren
While stress testing `git filter-repo`, I noticed an issue with encoding; further digging led to the fixes and features in this series. See the individual commit messages for details. Changes since v5 (full range-diff below): * s/utf-8/UTF-8/, as pointed out by Torsten (in commit messages and co

Re: [PATCH v5 4/5] fast-export: differentiate between explicitly utf-8 and implicitly utf-8

2019-05-13 Thread Torsten Bögershausen
On Mon, May 13, 2019 at 04:17:25PM -0700, Elijah Newren wrote: > The find_encoding() function returned the encoding used by a commit > message, returning a default of git_commit_encoding (usually utf-8). I think "UTF-8" is preferred over "utf-8". Unless it is a function name like is_encoding_utf8()

Re: [PATCH v5 3/5] fast-export: avoid stripping encoding header if we cannot reencode

2019-05-13 Thread Torsten Bögershausen
On Mon, May 13, 2019 at 04:17:24PM -0700, Elijah Newren wrote: > When fast-export encounters a commit with an 'encoding' header, it tries > to reencode in utf-8 and then drops the encoding header. However, if it > fails to reencode in utf-8 because e.g. one of the characters in the > commit messag

Re: [PATCH v5 1/5] t9350: fix encoding test to actually test reencoding

2019-05-13 Thread Torsten Bögershausen
On Mon, May 13, 2019 at 04:17:22PM -0700, Elijah Newren wrote: > This test used an author with non-ascii characters in the name, but > no special commit message. It then grep'ed for those non-ascii > characters, but those are guaranteed to exist regardless of the > reencoding process since the ree

Re: [PATCH] test-lib: try harder to ensure a working jgit

2019-05-13 Thread Jonathan Nieder
Todd Zullinger wrote: > The JGIT prereq uses 'type jgit' to determine whether jgit is present. > While this should be sufficient, if the jgit found is broken we'll waste > time running tests which fail due to no fault of our own. > > Use 'jgit --version' instead, to catch some badly broken jgit >

Re: [PATCH v2 0/7] Multiple hook support

2019-05-13 Thread Jonathan Nieder
Hi, brian m. carlson wrote: > On Mon, May 13, 2019 at 05:51:01PM -0700, Jonathan Nieder wrote: >> brian m. carlson wrote: >>> the fact that inheritance in the configuration >>> is in-order and can't be easily modified means that it's not likely to >>> be very useful, but

Re: [PATCH] test-lib: try harder to ensure a working jgit

2019-05-13 Thread brian m. carlson
On Mon, May 13, 2019 at 10:05:20PM -0400, Todd Zullinger wrote: > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 908ddb9c46..599fd70e14 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -1522,7 +1522,7 @@ test_lazy_prereq NOT_ROOT ' > ' > > test_lazy_prereq JGIT ' > - type jgit >

[PATCH] test-lib: try harder to ensure a working jgit

2019-05-13 Thread Todd Zullinger
The JGIT prereq uses 'type jgit' to determine whether jgit is present. While this should be sufficient, if the jgit found is broken we'll waste time running tests which fail due to no fault of our own. Use 'jgit --version' instead, to catch some badly broken jgit installations. Signed-off-by: Tod

Re: [PATCH v2] status: add an empty line when there is no hint

2019-05-13 Thread brian m. carlson
On Mon, May 13, 2019 at 02:51:37PM +0900, Junio C Hamano wrote: > If the difference between "status" and "commit" bothers you so much, > i.e. > > When typing "git status", there is an empty line between the > "Changes not staged for commit:" block and the list of changed > files. Howev

Re: [PATCH v2 0/7] Multiple hook support

2019-05-13 Thread brian m. carlson
On Mon, May 13, 2019 at 05:51:01PM -0700, Jonathan Nieder wrote: > Hi, > > brian m. carlson wrote: > > > I've thought a lot about the discussion over whether this series should > > use the configuration as the source for multiple hooks. Ultimately, I've > > come to the decision that it's not a go

Git Test Coverage Report (May 13, 2019)

2019-05-13 Thread Derrick Stolee
Here is today's test coverage report. You can view it in HTML [1] or text [2] form, and below. Thanks, -Stolee [1] https://derrickstolee.github.io/git-test-coverage/reports/2019-05-13.htm [2] https://derrickstolee.github.io/git-test-coverage/reports/2019-05-13.txt --- pu 7965c284718b7b0dfb

Re: [PATCH v2 0/7] Multiple hook support

2019-05-13 Thread Jonathan Nieder
Hi, brian m. carlson wrote: > I've thought a lot about the discussion over whether this series should > use the configuration as the source for multiple hooks. Ultimately, I've > come to the decision that it's not a good idea. Even adopting the empty > entry as a reset marker, the fact that inher

Git Test Coverage Report (v2.22.0-rc0)

2019-05-13 Thread Derrick Stolee
Please see the test-coverage report for code added between v2.21.0 and v2.22.0-rc0. These lines are not tested by the test suite on Linux with standard build options. Thanks, -Stolee --- builtin/blame.c a544fb08f8b builtin/blame.c 1005) die("no such ref: HEAD"); builtin/branch.c 0ecb1fc7269

[PATCH v2 4/7] builtin/worktree: add support for multiple post-checkout hooks

2019-05-13 Thread brian m. carlson
Add support for multiple post-checkout hooks. We test only one possible path in the multiple hook case because the same code path is used for all checkouts and we know the hooks work from earlier assertions. Signed-off-by: brian m. carlson --- builtin/worktree.c| 44 +

[PATCH v2 1/7] run-command: add preliminary support for multiple hooks

2019-05-13 Thread brian m. carlson
A variety of types of software take advantage of Git's hooks. However, if a user would like to integrate multiple pieces of software which use a particular hook, they currently must manage those hooks themselves, which can be burdensome. Sometimes various pieces of software try to overwrite each ot

[PATCH v2 3/7] rebase: add support for multiple hooks

2019-05-13 Thread brian m. carlson
Add support for multiple post-rewrite hooks, both for "git commit --amend" and "git rebase". Unify the hook handling between the am-based and sequencer-based code paths. Additionally add support for multiple prepare-commit-msg hooks. Note that the prepare-commit-msg hook is not passed a set of ho

[PATCH v2 7/7] docs: document multiple hooks

2019-05-13 Thread brian m. carlson
Document the semantics and behavior of multiple hooks, including the configuration options and requirements for them to be run. Signed-off-by: brian m. carlson --- Documentation/config.txt | 2 ++ Documentation/config/hook.txt | 19 +++ Documentation/githooks.txt| 9 ++

[PATCH v2 6/7] config: allow configuration of multiple hook error behavior

2019-05-13 Thread brian m. carlson
There are a variety of situations in which a user may want an error behavior for multiple hooks other than the default. Add a config option, hook..errorBehavior to allow users to customize this behavior on a per-hook basis. Provide options for the default behavior (exiting early), executing all hoo

[PATCH v2 5/7] transport: add support for multiple pre-push hooks

2019-05-13 Thread brian m. carlson
Add support for multiple pre-push hooks. Remove find_hook since there are no longer any callers of it. Signed-off-by: brian m. carlson --- run-command.c| 12 run-command.h| 6 -- t/t5571-pre-push-hook.sh | 19 +++ transport.c

[PATCH v2 3/7] sequencer: add support for multiple hooks

2019-05-13 Thread brian m. carlson
Add support for multiple post-rewrite hooks, both for "git commit --amend" and "git rebase". Additionally add support for multiple prepare-commit-msg hooks. Note that the prepare-commit-msg hook is not passed a set of hooks directly because these are discovered later when the code calls run_hooks

[PATCH v2 2/7] builtin/receive-pack: add support for multiple hooks

2019-05-13 Thread brian m. carlson
Add support for multiple hooks for the pre-receive, post-receive, update, post-update, and push-to-checkout hooks. Add tests for these hooks using the multiple hook test framework. Because the invocations of test_multiple_hooks contain multiple test assertions, they (and the cd commands that surro

Re: [PATCH v2] status: add an empty line when there is no hint

2019-05-13 Thread 林自均
Hi Junio, Junio C Hamano 於 2019年5月13日 週一 下午1:51寫道: > > 林自均 writes: > > > Hi Junio, > >> ... > > Could you please give me some advice on my patch? Thank you. > > I tend to agree with what Phillip said in > . > > If the difference between "status" and "commit" bothers you so much, > i.e. > > W

[PATCH v2 0/7] Multiple hook support

2019-05-13 Thread brian m. carlson
This series introduces multiple hook support. I've thought a lot about the discussion over whether this series should use the configuration as the source for multiple hooks. Ultimately, I've come to the decision that it's not a good idea. Even adopting the empty entry as a reset marker, the fact t

Re: [PATCH v5 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Eric Sunshine
On Mon, May 13, 2019 at 7:17 PM Elijah Newren wrote: > Automatic re-encoding of commit messages (and dropping of the encoding > header) hurts attempts to do reversible history rewrites (e.g. sha1sum > <-> sha256sum transitions, some subtree rewrites), and seems > inconsistent with the general prin

Re: Proposal: object negotiation for partial clones

2019-05-13 Thread Jonathan Nieder
Hi, Matthew DeVore wrote: > On 2019/05/09, at 11:00, Jonathan Tan wrote: >> - Supporting any combination of filter means that we have more to >> implement and test, especially if we want to support more filters in >> the future. In particular, the different filters (e.g. blob, tree) >> have d

Re: Proposal: object negotiation for partial clones

2019-05-13 Thread Matthew DeVore
> On 2019/05/09, at 11:00, Jonathan Tan wrote: > > Thanks for the numbers. Let me think about it some more, but I'm still > reluctant to introduce multiple filter support in the protocol and the > implementation for the following reasons: Correction to the original command - I was tweaking it

Re: [PATCH 2/2] parse-options: adjust `parse_opt_unknown_cb()`s declared return type

2019-05-13 Thread Junio C Hamano
"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > In f41179f16ba2 (parse-options: avoid magic return codes, 2019-01-27), > the signature of the low-level parse-opt callback function was changed > to return an `enum`. > > And while the implementations were changed, on

Re: [PATCH 1/2] pkt-line: fix declaration of `set_packet_header()`

2019-05-13 Thread Junio C Hamano
"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > When this function was changed in a97d00799a19 (remote-curl: use > post_rpc() for protocol v2 also, 2019-02-21) from file-local to global, > the declaration was incorrectly missing the `const` qualifier. I do not qui

[PATCH v5 4/5] fast-export: differentiate between explicitly utf-8 and implicitly utf-8

2019-05-13 Thread Elijah Newren
The find_encoding() function returned the encoding used by a commit message, returning a default of git_commit_encoding (usually utf-8). Although the current code does not differentiate between a commit which explicitly requested utf-8 and one where we just assume utf-8 because no encoding is set,

[PATCH v5 3/5] fast-export: avoid stripping encoding header if we cannot reencode

2019-05-13 Thread Elijah Newren
When fast-export encounters a commit with an 'encoding' header, it tries to reencode in utf-8 and then drops the encoding header. However, if it fails to reencode in utf-8 because e.g. one of the characters in the commit message was invalid in the old encoding, then we need to retain the original

[PATCH v5 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Elijah Newren
Automatic re-encoding of commit messages (and dropping of the encoding header) hurts attempts to do reversible history rewrites (e.g. sha1sum <-> sha256sum transitions, some subtree rewrites), and seems inconsistent with the general principle followed elsewhere in fast-export of requiring explicit

[PATCH v3] update-server-info: avoid needless overwrites

2019-05-13 Thread Eric Wong
Do not change the existing info/refs and objects/info/packs files if they match the existing content on the filesystem. This is intended to preserve mtime and make it easier for dumb HTTP pollers to rely on the If-Modified-Since header. Combined with stdio and kernel buffering; the kernel should b

[PATCH v5 0/5] Fix and extend encoding handling in fast export/import

2019-05-13 Thread Elijah Newren
While stress testing `git filter-repo`, I noticed an issue with encoding; further digging led to the fixes and features in this series. See the individual commit messages for details. Changes since v4 (full range-diff below): * Used git_parse_maybe_bool() * Updated Documentation/git-fast-expor

[PATCH v5 1/5] t9350: fix encoding test to actually test reencoding

2019-05-13 Thread Elijah Newren
This test used an author with non-ascii characters in the name, but no special commit message. It then grep'ed for those non-ascii characters, but those are guaranteed to exist regardless of the reencoding process since the reencoding only affects the commit message, not the author or committer na

[PATCH v5 2/5] fast-import: support 'encoding' commit header

2019-05-13 Thread Elijah Newren
Since git supports commit messages with an encoding other than utf-8, allow fast-import to import such commits. This may be useful for folks who do not want to reencode commit messages from an external system, and may also be useful to achieve reversible history rewrites (e.g. sha1sum <-> sha256su

Re: How to exchange rerere/redo resolutions?

2019-05-13 Thread Junio C Hamano
Philip Oakley writes: > Does the contrib/rerere-train.sh actually work? Yes, but it predates many esoteric things like multiple worktrees.

Re: git --help not actually showing the git(1) help page..

2019-05-13 Thread Junio C Hamano
Philip Oakley writes: > On GfW I commonly use the `git --help` when things go wrong, so > making the response to that give the right advice would be good. There are three levels of details ;-) "git --help" is meant as a shorter and sweeter version of "git help git" that is more detailed than "g

[PATCH 0/2] pkt-line: fix incorrect function declaration

2019-05-13 Thread Johannes Schindelin via GitGitGadget
MS Visual C detected a mismatch between the declaration and the definition of set_packet_header(): it is declared with its second parameter missing the const attribute. It also detected a mismatch between the declaration and the definition of parse_opt_unknown_cb(). These problems must have bee

[PATCH 1/2] pkt-line: fix declaration of `set_packet_header()`

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin When this function was changed in a97d00799a19 (remote-curl: use post_rpc() for protocol v2 also, 2019-02-21) from file-local to global, the declaration was incorrectly missing the `const` qualifier. Let's fix that. Signed-off-by: Johannes Schindelin --- pkt-line.h |

[PATCH 2/2] parse-options: adjust `parse_opt_unknown_cb()`s declared return type

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin In f41179f16ba2 (parse-options: avoid magic return codes, 2019-01-27), the signature of the low-level parse-opt callback function was changed to return an `enum`. And while the implementations were changed, one declaration was left unchanged, still claiming to return `i

Re: [ANNOUNCE] Git v2.22.0-rc0

2019-05-13 Thread Junio C Hamano
Ævar Arnfjörð Bjarmason writes: > -CC lkml & git-packagers. > > Some suggestions for fixes in RelNotes & last-minute observations: Thanks. >> * "git stash" has been rewritten in C. > > I just noticed that stash.useBuiltin added in 90a462725e ("stash: > optionally use the scripted version again

Re: [PATCH v4 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Junio C Hamano
Elijah Newren writes: > +static int parse_opt_reencode_mode(const struct option *opt, > +const char *arg, int unset) > +{ > + if (unset || !strcmp(arg, "abort")) > + reencode_mode = REENCODE_ABORT; > + else if (!strcmp(arg, "yes") || !strcmp(arg

Re: [ANNOUNCE] Git v2.22.0-rc0

2019-05-13 Thread Ævar Arnfjörð Bjarmason
-CC lkml & git-packagers. Some suggestions for fixes in RelNotes & last-minute observations: On Mon, May 13 2019, Junio C Hamano wrote: > * "git stash" has been rewritten in C. I just noticed that stash.useBuiltin added in 90a462725e ("stash: optionally use the scripted version again", 2019-

Re: How to exchange rerere/redo resolutions?

2019-05-13 Thread Philip Oakley
Hi All, On 10/05/2019 15:59, Philip Oakley wrote: You can publish your merged branch somewhere, and others can use contrib/rerere-train.sh to learn from the resolution. Supposedly, I've never actually used it... Does the contrib/rerere-train.sh actually work? I'm reading the code to ensure I

Re: What's cooking in git.git (May 2019, #02; Tue, 14)

2019-05-13 Thread Elijah Newren
On Mon, May 13, 2019 at 12:27 PM Junio C Hamano wrote: > * en/fast-export-encoding (2019-05-13) 5 commits > - fast-export: do automatic reencoding of commit messages only if requested > - fast-export: differentiate between explicitly utf-8 and implicitly utf-8 > - fast-export: avoid stripping e

[PATCH] sha1dc: update from upstream

2019-05-13 Thread Ævar Arnfjörð Bjarmason
Update sha1dc from the latest version by the upstream maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in sha1dc with UBSan", 2019-03-12) for the last update. This fixes an issue where HP-UX IA64 was wrongly detected as a Little-endian instead of a Big-endian system, see [2] and [3].

[no subject]

2019-05-13 Thread Duncan Ferguson
Git http://www.takuro-bbs.com/cgi-bin/click3/click3.cgi?cnt=akatuki&url=https://u.to/yVVfFQ Duncan

Re: git --help not actually showing the git(1) help page..

2019-05-13 Thread Philip Oakley
Hi Peff On 13/05/2019 21:53, Jeff King wrote: On Mon, May 13, 2019 at 09:47:27PM +0100, Philip Oakley wrote: Is there a cli way, especially on Git for Windows bash, to get the html man page of git(1)? I have it on my system, so can go via another page but.. All the `git --help` appear to work

Re: [PATCH v3 3/3] send-email: do defaults -> config -> getopt in that order

2019-05-13 Thread Ævar Arnfjörð Bjarmason
On Mon, May 13 2019, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> # Variables we fill in automatically, or via prompting: >> -my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@initial_bcc,$no_bcc,@xh, >> +my (@to,@cc,,@xh,$envelope_sender, > > ,,??? Just a typo. I see you fi

Re: [PATCH] clone: add `--remote-submodules` flag

2019-05-13 Thread Ævar Arnfjörð Bjarmason
On Mon, May 13 2019, Ben Avison wrote: > @@ -792,6 +795,11 @@ static int checkout(int submodule_progress) > if (option_verbosity < 0) > argv_array_push(&args, "--quiet"); > > + if (option_remote_submodules == 1) { I see you copied this from code a

Re: git --help not actually showing the git(1) help page..

2019-05-13 Thread Jeff King
On Mon, May 13, 2019 at 09:47:27PM +0100, Philip Oakley wrote: > Is there a cli way, especially on Git for Windows bash, to get the html man > page of git(1)? I have it on my system, so can go via another page but.. > > All the `git --help` appear to work, but I can't determine the correct > inv

git --help not actually showing the git(1) help page..

2019-05-13 Thread Philip Oakley
Is there a cli way, especially on Git for Windows bash, to get the html man page of git(1)? I have it on my system, so can go via another page but.. All the `git --help` appear to work, but I can't determine the correct invocation for bringing up the stupid content tracker's page in the brows

[PATCH] tests: add a special setup where prerequisites fail

2019-05-13 Thread Ævar Arnfjörð Bjarmason
As discussed in [1] there's a regression in the "pu" branch now because a new test implicitly assumed that a previous test guarded by a prerequisite had been run. Add a "GIT_TEST_FAIL_PREREQS" special test setup where we'll skip (nearly) all tests guarded by prerequisites, allowing us to easily emu

[PATCH] clone: add `--remote-submodules` flag

2019-05-13 Thread Ben Avison
When using `git clone --recurse-submodules` there was previously no way to pass a `--remote` switch to the implicit `git submodule update` command for any use case where you want the submodules to be checked out on their remote-tracking branch rather than with the SHA-1 recorded in the superproject

[PATCH v2 08/11] built-in add -i: show unique prefixes of the commands

2019-05-13 Thread Slavica Djukic via GitGitGadget
From: Slavica Djukic Just like in the Perl script `git-add--interactive.perl`, for each command a unique prefix is determined (if there exists any within the given parameters), and shown in the list, and accepted as a shortcut for the command. We use the prefix map implementation that we just ad

[PATCH v2 11/11] built-in add -i: implement the `help` command

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin This imitates the code to show the help text from the Perl script `git-add--interactive.perl` in the built-in version. To make sure that it renders exactly like the Perl version of `git add -i`, we also add a test case for that to `t3701-add-interactive.sh`. Signed-off

[PATCH v2 03/11] built-in add -i: implement the `status` command

2019-05-13 Thread Daniel Ferreira via GitGitGadget
From: Daniel Ferreira This implements the `status` command of `git add -i`. The data structures introduced in this commit will be extended as needed later. At this point, we re-implement only part of the `list_and_choose()` function of the Perl script `git-add--interactive.perl` and call it `lis

[PATCH v2 07/11] Add a function to determine unique prefixes for a list of strings

2019-05-13 Thread Slavica Djukic via GitGitGadget
From: Slavica Djukic In the `git add -i` command, we show unique prefixes of the commands and files, to give an indication what prefix would select them. Naturally, the C implementation looks a lot different than the Perl implementation: in Perl, a trie is much easier implemented, while we alrea

[PATCH v2 10/11] built-in add -i: use color in the main loop

2019-05-13 Thread Slavica Djukic via GitGitGadget
From: Slavica Djukic The error messages as well as the unique prefixes are colored in `git add -i` by default; We need to do the same in the built-in version. Signed-off-by: Slavica Djukic Signed-off-by: Johannes Schindelin --- add-interactive.c | 37 - 1 f

[PATCH v2 01/11] Start to implement a built-in version of `git add --interactive`

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin This is hardly the first conversion of a Git command that is implemented as a script to a built-in. So far, the most successful strategy for such conversions has been to add a built-in helper and call that for more and more functionality from the script, as more and more

[PATCH v2 06/11] built-in add -i: implement the main loop

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin The reason why we did not start with the main loop to begin with is that it is the first user of `list_and_choose()`, which uses the `list()` function that we conveniently introduced for use by the `status` command. Apart from the "and choose" part, there are more diffe

[PATCH v2 05/11] built-in add -i: color the header in the `status` command

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin For simplicity, we only implemented the `status` command without colors. This patch starts adding color, matching what the Perl script `git-add--interactive.perl` does. Original-Patch-By: Daniel Ferreira Signed-off-by: Slavica Djukic Signed-off-by: Johannes Schindelin

[PATCH v2 09/11] built-in add -i: support `?` (prompt help)

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin With this change, we print out the same colored help text that the Perl-based `git add -i` prints in the main loop when question mark is entered. Signed-off-by: Johannes Schindelin --- add-interactive.c | 22 +- 1 file changed, 21 insertions(+), 1

[PATCH v2 00/11] git add -i: add a rudimentary version in C (supporting only status and help so far)

2019-05-13 Thread Johannes Schindelin via GitGitGadget
This is the first leg on the long journey to a fully built-in git add -i (next up: parts 2 [https://github.com/gitgitgadget/git/pull/171], 3 [https://github.com/gitgitgadget/git/pull/172], 4 [https://github.com/gitgitgadget/git/pull/173], 5 [https://github.com/gitgitgadget/git/pull/174], and 6 [ht

[PATCH v2 04/11] built-in add -i: refresh the index before running `status`

2019-05-13 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin This is what the Perl version does, and therefore it is what the built-in version should do, too. Signed-off-by: Johannes Schindelin --- add-interactive.c | 4 +++- repository.c | 19 +++ repository.h | 7 +++ 3 files changed, 29 insert

[PATCH v2 02/11] diff: export diffstat interface

2019-05-13 Thread Daniel Ferreira via GitGitGadget
From: Daniel Ferreira Make the diffstat interface (namely, the diffstat_t struct and compute_diffstat) no longer be internal to diff.c and allow it to be used by other parts of git. This is helpful for code that may want to easily extract information from files using the diff machinery, while fl

Re: [PATCH] doc: explain why file: URLs and bundles don't mix

2019-05-13 Thread Alyssa Ross
> > +- When cloning, the former implies --local option. See > > + linkgit:git-clone[1] for details. > > + > > +- The latter is implemented using linkgit:git-upload-pack[1], which > > + expects its repository to be a directory, and therefore does not > > + work for bundles (see linkgit:git-bundle

[PATCH v4 3/5] fast-export: avoid stripping encoding header if we cannot reencode

2019-05-13 Thread Elijah Newren
When fast-export encounters a commit with an 'encoding' header, it tries to reencode in utf-8 and then drops the encoding header. However, if it fails to reencode in utf-8 because e.g. one of the characters in the commit message was invalid in the old encoding, then we need to retain the original

[PATCH v4 2/5] fast-import: support 'encoding' commit header

2019-05-13 Thread Elijah Newren
Since git supports commit messages with an encoding other than utf-8, allow fast-import to import such commits. This may be useful for folks who do not want to reencode commit messages from an external system, and may also be useful to achieve reversible history rewrites (e.g. sha1sum <-> sha256su

[PATCH v4 4/5] fast-export: differentiate between explicitly utf-8 and implicitly utf-8

2019-05-13 Thread Elijah Newren
The find_encoding() function returned the encoding used by a commit message, returning a default of git_commit_encoding (usually utf-8). Although the current code does not differentiate between a commit which explicitly requested utf-8 and one where we just assume utf-8 because no encoding is set,

[PATCH v4 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Elijah Newren
Automatic re-encoding of commit messages (and dropping of the encoding header) hurts attempts to do reversible history rewrites (e.g. sha1sum <-> sha256sum transitions, some subtree rewrites), and seems inconsistent with the general principle followed elsewhere in fast-export of requiring explicit

[PATCH v4 0/5] Fix and extend encoding handling in fast export/import

2019-05-13 Thread Elijah Newren
While stress testing `git filter-repo`, I noticed an issue with encoding; further digging led to the fixes and features in this series. See the individual commit messages for details. Changes since v3 (full range-diff below): * YES/NO changes suggested by Torsten * more boolean synonyms as sug

[PATCH v4 1/5] t9350: fix encoding test to actually test reencoding

2019-05-13 Thread Elijah Newren
This test used an author with non-ascii characters in the name, but no special commit message. It then grep'ed for those non-ascii characters, but those are guaranteed to exist regardless of the reencoding process since the reencoding only affects the commit message, not the author or committer na

Re: [PATCH v3 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Elijah Newren
On Mon, May 13, 2019 at 3:23 AM Johannes Schindelin wrote: > > Hi Elijah, > > On Sat, 11 May 2019, Elijah Newren wrote: > > > [...] the craziness is based on how Windows behaves; it seems insane to > > me that Windows decides to munge user data (in the form of the command > > line provided), so mu

What's cooking in git.git (May 2019, #02; Tue, 14)

2019-05-13 Thread Junio C Hamano
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 in any of the integration branches, but I am still holding onto them. An early preview 2.22-rc0 has been

[ANNOUNCE] Git v2.22.0-rc0

2019-05-13 Thread Junio C Hamano
An early preview release Git v2.22.0-rc0 is now available for testing at the usual places. It is comprised of 648 non-merge commits since v2.21.0, contributed by 58 people, 11 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The followi

Re: nd/merge-quit, was Re: What's cooking in git.git (May 2019, #01; Thu, 9)

2019-05-13 Thread Johannes Schindelin
Hi Eric, On Mon, 13 May 2019, Eric Sunshine wrote: > On Mon, May 13, 2019 at 10:06 AM Johannes Schindelin > wrote: > > I should have posted the link, as it may not be totally obvious where you > > can download artifacts: > > > > https://dev.azure.com/mseng/AzureDevOps/_build/results?buildId=9464

Re: nd/merge-quit, was Re: What's cooking in git.git (May 2019, #01; Thu, 9)

2019-05-13 Thread Eric Sunshine
On Mon, May 13, 2019 at 10:06 AM Johannes Schindelin wrote: > I should have posted the link, as it may not be totally obvious where you > can download artifacts: > > https://dev.azure.com/mseng/AzureDevOps/_build/results?buildId=9464474&view=artifacts This link leads to a Login page requiring som

Re: nd/merge-quit, was Re: What's cooking in git.git (May 2019, #01; Thu, 9)

2019-05-13 Thread Johannes Schindelin
Hi, On Mon, 13 May 2019, Johannes Schindelin wrote: > On Fri, 10 May 2019, Duy Nguyen wrote: > > > On Fri, May 10, 2019 at 3:54 AM Johannes Schindelin > > wrote: > > > > > > Hi Junio & Duy, > > > > > > On Thu, 9 May 2019, Junio C Hamano wrote: > > > > > > > * nd/merge-quit (2019-05-07) 2 commits

Re: nd/merge-quit, was Re: What's cooking in git.git (May 2019, #01; Thu, 9)

2019-05-13 Thread Johannes Schindelin
Hi Duy, On Fri, 10 May 2019, Duy Nguyen wrote: > On Fri, May 10, 2019 at 3:54 AM Johannes Schindelin > wrote: > > > > Hi Junio & Duy, > > > > On Thu, 9 May 2019, Junio C Hamano wrote: > > > > > * nd/merge-quit (2019-05-07) 2 commits > > > - merge: add --quit > > > - merge: remove drop_save() i

Re: [PATCH v3 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Elijah Newren
On Mon, May 13, 2019 at 5:56 AM Torsten Bögershausen wrote: > > On Mon, May 13, 2019 at 12:23:29PM +0200, Johannes Schindelin wrote: > > Hi Elijah, > > > > On Sat, 11 May 2019, Elijah Newren wrote: > > > > > [...] the craziness is based on how Windows behaves; it seems insane to > > > me that Wind

Re: What's cooking in git.git (May 2019, #01; Thu, 9)

2019-05-13 Thread Phillip Wood
Hi Dscho On 10/05/2019 14:49, Johannes Schindelin wrote: Hi Phillip, On Thu, 9 May 2019, Phillip Wood wrote: On 08/05/2019 18:23, Junio C Hamano wrote: * pw/rebase-abort-clean-rewritten (2019-05-08) 1 commit - rebase --abort: cleanup refs/rewritten (this branch uses pw/rebase-i-interna

Re: [PATCH v3 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Elijah Newren
On Mon, May 13, 2019 at 12:48 AM Junio C Hamano wrote: > > Elijah Newren writes: > > > On Sat, May 11, 2019 at 2:07 PM Torsten Bögershausen wrote: > >> On Fri, May 10, 2019 at 01:53:35PM -0700, Elijah Newren wrote: > > > >> This one is good: > >> > + if (unset || !strcmp(arg, "abort")) > >>

Re: [PATCH v3 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Torsten Bögershausen
On Mon, May 13, 2019 at 12:23:29PM +0200, Johannes Schindelin wrote: > Hi Elijah, > > On Sat, 11 May 2019, Elijah Newren wrote: > > > [...] the craziness is based on how Windows behaves; it seems insane to > > me that Windows decides to munge user data (in the form of the command > > line provided)

Re: "add worktree" fails with "fatal: Invalid path" error

2019-05-13 Thread Shaheed Haque
Hi Duy, On Mon, 13 May 2019 at 10:21, Duy Nguyen wrote: > > On Sun, May 12, 2019 at 5:14 PM Shaheed Haque wrote: > > > > Hi, > > > > I'm running git v.2.20.1 on Ubuntu from a program which follows the pattern: > > > > > > 1. create a temporary directory /tmp/tmpabc > > When is this

Re: [PATCH 07/11] Add a function to determine unique prefixes for a list of strings

2019-05-13 Thread Johannes Schindelin
Hi Jeff, On Thu, 18 Apr 2019, Jeff Hostetler wrote: > On 4/10/2019 1:37 PM, Slavica Djukic via GitGitGadget wrote: > > From: Slavica Djukic > > > > In the `git add -i` command, we show unique prefixes of the commands and > > files, to give an indication what prefix would select them. > > > > Nat

Re: [PATCH] worktree add: be tolerant of corrupt worktrees

2019-05-13 Thread Shaheed Haque
Hi Nguyễn, Thanks for the quick response. While I leave the code to the experts, I can confirm that restoring the missing directory (but no content in it) does allow "worktree add" to function again. One point may be worth clarifying... On Mon, 13 May 2019 at 11:50, Nguyễn Thái Ngọc Duy wrote:

Re: [PATCH 06/11] built-in add -i: implement the main loop

2019-05-13 Thread Johannes Schindelin
Hi Jeff, On Thu, 18 Apr 2019, Jeff Hostetler wrote: > On 4/10/2019 1:37 PM, Johannes Schindelin via GitGitGadget wrote: > > > [...] > > + > > +/* > > + * Returns the selected index. > > + */ > > +static ssize_t list_and_choose(struct item **items, size_t nr, > > + struct

Re: [PATCH v4 02/11] commit-graph: return with errors during write

2019-05-13 Thread Derrick Stolee
On 5/13/2019 7:04 AM, Derrick Stolee wrote: > On 5/12/2019 11:13 PM, Junio C Hamano wrote: >> "Derrick Stolee via GitGitGadget" writes: >> >>> diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c >>> @@ -188,14 +187,14 @@ static int graph_write(int argc, const char **argv) >>>

Re: [PATCH 01/11] Start to implement a built-in version of `git add --interactive`

2019-05-13 Thread Johannes Schindelin
Hi Peff, On Tue, 30 Apr 2019, Jeff King wrote: > On Tue, Apr 30, 2019 at 07:40:06PM -0400, Johannes Schindelin wrote: > > > And I also tried pretty hard to *not* bleed any internal state of > > `add-interactive` into `builtin/add`, as I wanted the new code to be > > as libified as possible (in a

Re: [PATCH v4 02/11] commit-graph: return with errors during write

2019-05-13 Thread Derrick Stolee
On 5/12/2019 11:13 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" writes: > >> diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c >> @@ -188,14 +187,14 @@ static int graph_write(int argc, const char **argv) >> UNLEAK(buf); >> } >> >> -write_commit_g

Re: [PATCH v4 03/11] commit-graph: collapse parameters into flags

2019-05-13 Thread Derrick Stolee
On 5/12/2019 11:44 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" writes: > >> From: Derrick Stolee >> >> The write_commit_graph() and write_commit_graph_reachable() methods >> currently take two boolean parameters: 'append' and 'report_progress'. >> We will soon expand the possib

[PATCH] worktree add: be tolerant of corrupt worktrees

2019-05-13 Thread Nguyễn Thái Ngọc Duy
find_worktree() can die() unexpectedly because it uses real_path() instead of the gentler version. When it's used in 'git worktree add' [1] and there's a bad worktree, this die() could prevent people from adding new worktrees. The "bad" condition to trigger this is when a parent of the worktree's

Re: [PATCH v3 5/5] fast-export: do automatic reencoding of commit messages only if requested

2019-05-13 Thread Johannes Schindelin
Hi Elijah, On Sat, 11 May 2019, Elijah Newren wrote: > [...] the craziness is based on how Windows behaves; it seems insane to > me that Windows decides to munge user data (in the form of the command > line provided), so much so that it makes me wonder if I really > understood Hannes' and Dscho's

Re: [PATCH v3 0/5] Fix and extend encoding handling in fast export/import

2019-05-13 Thread Johannes Schindelin
Hi Elijah, On Fri, 10 May 2019, Elijah Newren wrote: > * Modified the testcases to pass on Windows[1], as verified via > gitgitgadget pull request[2]. Required adding a couple new files > (which store the desired bytes) and checking the size of the output > instead of checking for

  1   2   >