The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
The --chain-lint option detects broken &&-chains by forcing the test to
exit early (as the very first step) with a sentinel value. If that
sentinel is the test's overall exit code, then the &&-chain is intact;
if not, then the chain is broken. Unfortunately, this detection does not
extend to &&-cha
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection.
Although the heuristics work well, they are still best-guesses and
future changes could accidentally break assumptions upon which they are
based. To protect agai
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
This is a re-roll of [1] which teaches --chain-lint to detect broken
&&-chains in subshells since the existing implementation[2] detects
breakage only at the top-level. It is built atop 'es/test-fixes', which
was split off of [1] and submitted separately[3], and which fixes many
broken &&-chains.
The --chain-lint option uses heuristics and knowledge of shell syntax to
detect broken &&-chains in subshells by pure textual inspection. The
heuristics handle a range of stylistic variations in existing tests
(evolved over the years), however, they are still best-guesses. As such,
it is possible f
> we care about reachability only from the detached HEAD here, so this
> must _not_ use test_commit, which creates an extra tag.
Right. I can add a comment to that effect.
> Please avoid unnecessary reflowing of earlier lines of the paragrpah
> when the only change is to insert "or from HEAD" in
read_index_unmerged() has two intended purposes:
* return 1 if there are any unmerged entries, 0 otherwise
* drops any higher-stage entries down to stage #0
There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that
Several "recovery" commands outright fail or do not fully recover
when directory-file conflicts are present. This includes:
* git read-tree --reset HEAD
* git am --skip
* git am --abort
* git merge --abort (or git reset --merge)
* git reset --hard
It turns out that multiple invocat
Several "recovery" commands outright fail or do not fully recover
when directory-file conflicts are present. This includes:
* git read-tree --reset HEAD
* git am --skip
* git am --abort
* git merge --abort
* git reset --hard
Add testcases documenting these shortcomings.
Signed-off-by:
On Mon, Jul 9, 2018 at 1:22 PM, Elijah Newren wrote:
> On Mon, Jul 9, 2018 at 10:53 AM, Junio C Hamano wrote:
>> Elijah Newren writes:
>>
>>> When a merge succeeds, we expect the resulting contents to depend only
>>> upon the trees and blobs of the branches involved and of their merge
>>> base(s
Signed-off-by: Elijah Newren
---
t/t7405-submodule-merge.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
index 45d1779d2..7855bd864 100755
--- a/t/t7405-submodule-merge.sh
+++ b/t/t7405-submodule-merge
For a directory/submodule conflict, we want contents from both the
directory and the submodule to be present for the user to use to resolve
the conflict, but we do not want paths under the directory being written
into the submodule and we do not want the merge being confused by paths
under the subm
This patch series documents a few problems with submodules and merging,
first mentioned at [1].
Changes since v1 (full range-diff below):
- Incorporate suggestions from Stefan: use test_commit and git
submodule add (note that git submodule add means there will also
be a .gitmodules file,
In the case of a file/submodule conflict, although both cannot exist at
the same path, we expect both to be present somewhere for the user to be
able to resolve the conflict with. Add a testcase for this.
Signed-off-by: Elijah Newren
---
t/t7405-submodule-merge.sh | 54 +
On Tue, Jul 10, 2018 at 1:39 PM, SZEDER Gábor wrote:
>> diff --git a/t/t6044-merge-unrelated-index-changes.sh
>> b/t/t6044-merge-unrelated-index-changes.sh
>> index f9c2f8179..92ec55255 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++ b/t/t6044-merge-unrelated-index-changes.sh
>> @
On Tue, Jul 10, 2018 at 02:08:28PM -0400, Ben Peart wrote:
>
>
> On 7/9/2018 7:39 PM, brian m. carlson wrote:
> > On Mon, Jul 09, 2018 at 10:45:33AM -0700, Junio C Hamano wrote:
> > > As Brandon alludes to downthread, we probably should use strbuf for
> > > things like this these days, so a preli
Alban Gruin writes:
> This removes the modes `--skip-unnecessary-picks`, `--append-todo-help`,
> `--checkout-onto`, `--shorten-ids` and `--expand-ids` from
> rebase--helper.c, the functions of git-rebase--interactive.sh that were
> rendered useless by the rewrite of complete_action(), and
> appen
Alban Gruin writes:
> This rewrites complete_action() from shell to C.
>
> A new mode is added to rebase--helper (`--complete-action`), as well as
> a new flag (`--autosquash`).
>
> Finally, complete_action() is stripped from git-rebase--interactive.sh.
>
> The original complete_action() checked
A quick correction:
Jonathan Nieder wrote:
> Similarly, various features of other tools (like bash's
> support for <(echo hi)) also rely on /proc.
That relies on /dev/fd, not /proc, but same idea.
Tools like "ps" rely on /proc.
Sorry for the noise,
Jonathan
Hi,
Jeff King wrote:
> My point is that aside from RUNTIME_PREFIX, we don't need /proc. So
> somebody who currently builds Git with a static path like
> "/usr/libexec/git-core" and runs it inside a chroot will be just fine as
> long as /usr/libexec/git-core is available at that name inside the
>
My wife and I won the Euro Millions Lottery of £53 Million British Pounds and
we have voluntarily decided to donate 1,000,000EUR(One Million Euros) to 5
individuals randomly as part of our own charity project.
To verify our lottery winnings,please see our interview by visiting the web
page be
When outputting lines that are checked for white space, we first use
emit_line_0 to emit the prefix, and then the ws specific code. The code
at each site carefully sets the color and then resets it, though it is
the same color.
Avoid setting the color twice by passing a newly introduced flag that
On 07/06, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > On 06/05, Thomas Gummerer wrote:
> >> The previous round was at
> >> <20180520211210.1248-1-t.gumme...@gmail.com>.
> >>
> >> Thanks Junio for the comments on the previous round.
> >>
> >> Changes since v2:
> >> - lowercase the fir
On 7/10/2018 4:21 PM, Jeff King wrote:
On Tue, Jul 10, 2018 at 12:41:52PM -0700, Junio C Hamano wrote:
Jeff King writes:
- while (buf < cp && isspace(cp[-1]))
- cp--;
- *cp++ = '\n';
- return cp - buf;
+ strbuf_rtrim(sb);
Using rtrim is a nice reduc
Ben Peart writes:
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index a9a066dcfb..054306d779 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -1582,26 +1582,17 @@ static int log_ref_write_fd(int fd, const struct
> object_id *old_oid,
>
Henning Schild writes:
> Add test cases to cover the new X509/gpgsm support. Most of them
> resemble existing ones. They just switch the format to x509 and set the
> signingkey when creating signatures. Validation of signatures does not
> need any configuration of git, it does need gpgsm to be co
Since we don't care about how many bytes were written, simplify the return
value logic.
log_ref_write_fd() was written long before strbuf was fleshed out. Remove
the old manual buffer management code and replace it with strbuf(). Also
update copy_reflog_msg() which is called only by log_ref_write_
> diff --git a/t/t6044-merge-unrelated-index-changes.sh
> b/t/t6044-merge-unrelated-index-changes.sh
> index f9c2f8179..92ec55255 100755
> --- a/t/t6044-merge-unrelated-index-changes.sh
> +++ b/t/t6044-merge-unrelated-index-changes.sh
> @@ -126,6 +126,17 @@ test_expect_failure 'recursive, when mer
On Tue, Jul 10, 2018 at 03:46:14PM -0400, David Turner wrote:
> This seems inconsistent:
>
> $ git log --oneline --stat 91ccfb85176 -c
> 91ccfb8517 Merge branch 'sb/diff-color-move'
>
> diff.c | 28 +++-
> t/t4015-diff-whitespace.sh | 9 +
>
On Tue, Jul 10, 2018 at 12:41:52PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> - while (buf < cp && isspace(cp[-1]))
> >> - cp--;
> >> - *cp++ = '\n';
> >> - return cp - buf;
> >> + strbuf_rtrim(sb);
> >
> > Using rtrim is a nice reduction in complexity. A pure translati
Top of the day to you, this is in respect of a very beneficial transaction
which you would not want to let go reply for more details,
Regards,
Lee
emit_line_0 grew complicated again, so here is an attempt to make it
a bit simpler. emit_line_0 is called for all lines that are added,
removed or context lines, and it follows the format:
\
with each of the components optional.
Another follow up cleanup (that also touches the tests)
For the diff of diffs, we have more than one character at the beginning
of the line with special meaning, so let's pass around a string that
contains all the markup for the line
Signed-off-by: Stefan Beller
---
diff.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff -
This seems inconsistent:
$ git log --oneline --stat 91ccfb85176 -c
91ccfb8517 Merge branch 'sb/diff-color-move'
diff.c | 28 +++-
t/t4015-diff-whitespace.sh | 9 +
2 files changed, 24 insertions(+), 13 deletions(-)
d1114d87c7 Merge branch 'js/
Jeff King writes:
>> -while (buf < cp && isspace(cp[-1]))
>> -cp--;
>> -*cp++ = '\n';
>> -return cp - buf;
>> +strbuf_rtrim(sb);
>
> Using rtrim is a nice reduction in complexity. A pure translation would
> include a final strbuf_addch(sb, '\n'). It looks like you move
After modify/delete merge conflict happens in a file skipped by sparse
checkout, "git reset --merge", which implements the "--abort" actions,
and "git reset --hard" fail with message "Entry * not uptodate. Cannot
update sparse checkout."
As explained in [1], the up-to-date checker mistakenly treat
On Fri, Jun 15, 2018 at 12:58:40PM -0700, Junio C Hamano wrote:
> Do we want to verify the state after the 'hard' reset succeeds as
> well? Things like
>
> - all paths in the HEAD and all paths in the index are identical;
>
> - paths that do exist in the working tree are all identical to HEAD
On Sat, Jun 16, 2018 at 07:14:44AM +0200, Duy Nguyen wrote:
> -- 8< --
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 3a85a02a77..eb544ee1b3 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1246,7 +1246,7 @@ static void mark_new_skip_worktree(struct exclude_list
> *el,
>
Jeff King writes:
> Should we allow:
>
> [gpg "OpenPGP"]
> program = whatever
>
> given that we allow:
>
> [gpg]
> format = OpenPGP
If the latter is allowed then we should allow the former.
But because allowing the former is cumbersome, we may be better off
not parsing the value case-
> On Jul 10, 2018, at 5:27 AM, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Jul 3, 2018 at 3:36 PM, Jeff King wrote:
>> On Mon, Jul 02, 2018 at 01:15:19PM -0700, Jeremy Huddleston Sequoia wrote:
>>
I hope that maybe they're also interested in reducing the overall
diff between upstream
William Chargin writes:
> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exist
Hi Peff,
On Mon, 2 Jul 2018, Jeff King wrote:
> On Mon, Jul 02, 2018 at 09:29:41PM +0200, Christian Couder wrote:
>
> > When people complained a month ago about the MacOS package on
> > https://git-scm.com/ not being up-to-date after the Git security
> > release, I got in touch with Apple people
This is developed on top of 4a68b95ce2a6 (your series here)
This is an attempt to explain the previous email better,
specially the second (yet unfinished) patch, but the resulting
emit_line_0 is way clearer in my mind, dropping the 'first' character
and instead having a 'char *sign' that (a) we ca
Alban Gruin writes:
> - if (command == SKIP_UNNECESSARY_PICKS && argc == 1)
> - return !!skip_unnecessary_picks();
> + if (command == SKIP_UNNECESSARY_PICKS && argc == 1) {
> + ret = !!skip_unnecessary_picks(&oid);
> + if (!ret && oid)
> +
Alban Gruin writes:
> diff --git a/rebase-interactive.h b/rebase-interactive.h
> index 155219e74..c0ba83be3 100644
> --- a/rebase-interactive.h
> +++ b/rebase-interactive.h
> @@ -1,7 +1,12 @@
> #ifndef REBASE_INTERACTIVE_H
> #define REBASE_INTERACTIVE_H
>
> -int append_todo_help(unsigned edit
Alban Gruin writes:
> This rewrites the edit-todo functionality from shell to C.
>
> To achieve that, a new command mode, `edit-todo`, is added, and the
> `write-edit-todo` flag is removed, as the shell script does not need to
> write the edit todo help message to the todo list anymore.
>
> The s
On Tue, Jul 10, 2018 at 8:53 AM, Stefan Beller wrote:
> On Tue, Jul 10, 2018 at 8:28 AM Elijah Newren wrote:
>> 2) I didn't just check what was currently failing but other things
>> that should be true for this test.
>>
>> For item 2, I've had multiple cases in the past where I created a
>> mini
For the diff of diffs, we have more than one character at the beginning
of the line with special meaning, so let's pass around a string that
contains all the markup for the line
Signed-off-by: Stefan Beller
---
diff.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff -
On Tue, Jul 10, 2018 at 06:20:22PM +, Ben Peart wrote:
> log_ref_write_fd() was written long before strbuf was fleshed out. Remove
> the old manual buffer management code and replace it with strbuf(). Also
> update copy_reflog_msg() which is called only by log_ref_write_fd() to use
> strbuf as
Jeff King writes:
>> @@ -16,13 +16,18 @@ struct gpg_format_data {
>>
>> #define PGP_SIGNATURE "-BEGIN PGP SIGNATURE-"
>> #define PGP_MESSAGE "-BEGIN PGP MESSAGE-"
>> +#define X509_SIGNATURE "-BEGIN SIGNED MESSAGE-"
>>
>> -enum gpgformats { PGP_FMT };
>> +enum gpgform
> > - if (!core_commit_graph)
> > + if (repo_config_get_bool(r, "core.commitgraph", &config_value) ||
> > + !config_value)
> > + /*
> > +* This repository is not configured to use commit graphs, so
> > +* do not load one. (But report commit_graph_attempte
On 7/9/2018 7:39 PM, brian m. carlson wrote:
On Mon, Jul 09, 2018 at 10:45:33AM -0700, Junio C Hamano wrote:
Derrick Stolee writes:
On 7/8/2018 7:36 PM, brian m. carlson wrote:
diff --git a/refs/files-backend.c b/refs/files-backend.c
index a9a066dcfb..252f835bae 100644
--- a/refs/files-ba
Alban Gruin writes:
> @@ -4467,7 +4467,7 @@ int skip_unnecessary_picks(void)
> }
>
> todo_list_release(&todo_list);
> - printf("%s\n", oid_to_hex(oid));
> + *output_oid = oid_to_hex(oid);
The return value from oid_to_hex() is volatile and does not survive
across multiple ca
This breaks t4034 (word diffs), but all other tests pass.
emit_line_0 grew complicated again, so here is an attempt to make it
a bit simpler. emit_line_0 is called for all lines that are added,
removed or context lines, and it follows the format:
with each of the components optional. How
Alban Gruin writes:
> This rewrites append_todo_help() from shell to C. It also incorporates
> some parts of initiate_action() and complete_action() that also write
> help texts to the todo file.
>
> This also introduces the source file rebase-interactive.c. This file
> will contain functions nec
Alban Gruin writes:
> This rewrites checkout_onto() from shell to C.
>
> A new command (“checkout-onto”) is added to rebase--helper.c. The shell
> version is then stripped.
>
> Signed-off-by: Alban Gruin
> ---
The only change relative to the previous round seems to be that this
round does not p
On Tue, Jul 10, 2018 at 08:41:06AM -0700, William Chargin wrote:
> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit
log_ref_write_fd() was written long before strbuf was fleshed out. Remove
the old manual buffer management code and replace it with strbuf(). Also
update copy_reflog_msg() which is called only by log_ref_write_fd() to use
strbuf as it keeps things consistent.
Signed-off-by: Ben Peart
---
Notes:
Alban Gruin writes:
> This rewrites (the misnamed) setup_reflog_action() from shell to C. The
> new version is called prepare_branch_to_be_rebased().
>
> A new command is added to rebase--helper.c, “checkout-base”, as well as
> a new flag, “verbose”, to avoid silencing the output of the checkout
On Tue, Jul 10, 2018 at 08:42:04AM -0700, Elijah Newren wrote:
> > test-lint is supposed to be run automatically as part of "make test" (or
> > "make prove"), unless you've specifically disabled it by setting
> > TEST_LINT. And it does complain for me with your patches. If it doesn't
> > for you,
For those reading from sidelines, this is unchanged from the
previous round, and looking good.
Alban Gruin writes:
> +const char *git_sequence_editor(void)
> {
> - const char *editor = git_editor();
> + const char *editor = getenv("GIT_SEQUENCE_EDITOR");
> +
> + if (!editor)
> +
Alban Gruin writes:
> This adds a new function, run_command_silent_on_success(), to
> redirect the stdout and stderr of a command to a strbuf, and then to run
> that command. This strbuf is printed only if the command fails. It is
> functionnaly similar to output() from git-rebase.sh.
>
> run_git
Alban Gruin writes:
> This makes rebase_path_todo(), get_missing_commit_check_level() and the
> enum check_level accessible outside sequencer.c. check_level is renamed
> missing_commit_check_level, and its value names are prefixed by
> MISSING_COMMIT_ to avoid namespace pollution.
It is not too
On Tue, Jul 10, 2018 at 6:18 AM, Johannes Schindelin
wrote:
>> 32-bit builds complain about this:
>>
>> t/helper/test-repository.c: In function 'test_parse_commit_in_graph':
>> t/helper/test-repository.c:28:9: error: format '%lu' expects argument of
>> type 'long unsigned int', but argument 2
On Tue, Jul 10, 2018 at 10:40:22AM -0700, Junio C Hamano wrote:
> > Extremely minor nit, but if there are no other uses of PGP_SIGNATURE etc
> > outside of this array (as I hope there wouldn't be after this series),
> > would it make more sense to just include the literals inline in the
> > array
Henning Schild writes:
> Create a struct that holds the format details for the supported formats.
> At the moment that is still just "openpgp". This commit prepares for the
> introduction of more formats, that might use other programs and match
> other signatures.
>
> Signed-off-by: Henning Schil
On Tue, Jul 10, 2018 at 01:09:01PM -0400, Jeff King wrote:
> > + gpgsm --homedir "${GNUPGHOME}" --import
> > "$TEST_DIRECTORY"/lib-gpg/gpgsm.crt.user &&
> > + gpgsm --homedir "${GNUPGHOME}" -K | grep fingerprint: | cut -d"
> > " -f4 | tr -d '\n' > ${GNUPGHOME}/trustlist.txt &
On Tue, Jul 10, 2018 at 08:58:32AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:
> >
> >> What we've been avoiding was the comma after the last element in the
> >> enum (in other words, if PGP_FMT had ',' after it in the ab
On Tue, Jul 10, 2018 at 10:52:22AM +0200, Henning Schild wrote:
> This series adds support for signing commits with gpgsm.
Thanks for working on this. I left a bunch of comments, but overall the
direction looks good.
We talked about this a bit off-list, but just for the public record:
> This se
On Tue, Jul 10, 2018 at 10:52:31AM +0200, Henning Schild wrote:
> diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> index a5d3b2cba..9dcb4e990 100755
> --- a/t/lib-gpg.sh
> +++ b/t/lib-gpg.sh
> @@ -38,7 +38,14 @@ then
> "$TEST_DIRECTORY"/lib-gpg/ownertrust &&
> gpg --h
On Tue, Jul 10, 2018 at 10:52:30AM +0200, Henning Schild wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index c0bd80954..b6f9b47d5 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1830,7 +1830,7 @@ gpg.program::
>
> gpg.format::
>
On Tue, Jul 10, 2018 at 12:54:13PM -0400, Jeff King wrote:
> Should we allow:
>
> [gpg "OpenPGP"]
> program = whatever
>
> given that we allow:
>
> [gpg]
> format = OpenPGP
>
> ? I think just using strcasecmp() here would be sufficient. But I wonder
> if it is a symptom of using the wr
Henning Schild writes:
> Test setting gpg.format to both invalid and valid values.
>
> Signed-off-by: Henning Schild
> ---
> t/t7510-signed-commit.sh | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index 6e2015ed9..7e1e9
On Tue, Jul 10, 2018 at 10:52:29AM +0200, Henning Schild wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ac373e3f4..c0bd80954 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1832,6 +1832,11 @@ gpg.format::
> Specifies which key
Henning Schild writes:
> This commit turns parse_gpg_output into an internal function, the only
> outside user was migrated in an earlier commit.
It is not too big a deal but as we prefer to see our history speak
in consistent voice, we would usually phrase the above as if we are
giving an order
"brian m. carlson" writes:
>> As Brandon alludes to downthread, we probably should use strbuf for
>> things like this these days, so a preliminary clean-up to do so is
>> probably a welcome change to sneak in and rebase this series on top
>> of.
>
> Sure, I agree that would be a better change, an
On Tue, Jul 10, 2018 at 3:08 AM Johannes Schindelin
wrote:
>
> Hi Junio,
>
> On Mon, 9 Jul 2018, Junio C Hamano wrote:
>
> > I also wonder if we should be feeding the context lines to ws.c
> > machinery in the first place though.
>
> It *is* confusing, I know. The entire "diff of diffs" concept *i
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> In 107642fe26 ("convert: add 'working-tree-encoding' attribute",
> 2018-04-15) we added an attribute which defines the working tree
> encoding of a file.
>
> Some platforms might spell the name of a certain encoding differently or
> some
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> Refactor conversion driver config parsing to ease the parsing of new
> configs in a subsequent patch.
>
> No functional change intended.
>
> Signed-off-by: Lars Schneider
> ---
The change unfortunately makes everything indented one lev
On Tue, Jul 10, 2018 at 10:52:27AM +0200, Henning Schild wrote:
> Create a struct that holds the format details for the supported formats.
> At the moment that is still just "openpgp". This commit prepares for the
> introduction of more formats, that might use other programs and match
> other sign
Hi,
I published a new blog post:
https://blog.pa1ch.fr/posts/2018/07/10/en/gsoc2018-week-10.html
Cheers,
Alban
Daniel Jacques writes:
> All things considered, I think executable path self-location is markedly more
> fragile than using static paths, both with increased dependencies and added
> inconsistent behavior and limitations, and should not be the default
> on any platform.
>
> Both Johannes' origina
Jeff King writes:
> On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:
>
>> What we've been avoiding was the comma after the last element in the
>> enum (in other words, if PGP_FMT had ',' after it in the above
>> quoted addition, that would have been violation of that rule), as
>> h
On Tue, Jul 10, 2018 at 10:52:25AM +0200, Henning Schild wrote:
> @@ -138,6 +139,12 @@ int git_gpg_config(const char *var, const char *value,
> void *cb)
> return 0;
> }
>
> + if (!strcmp(var, "gpg.format")) {
> + if (strcasecmp(value, "openpgp"))
> +
On Tue, Jul 10, 2018 at 10:52:26AM +0200, Henning Schild wrote:
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index 6e2015ed9..7e1e9caf4 100755
> --- a/t/t7510-signed-commit.sh
> +++ b/t/t7510-signed-commit.sh
> @@ -227,4 +227,14 @@ test_expect_success GPG 'log.showsignature
On Tue, Jul 10, 2018 at 8:28 AM Elijah Newren wrote:
>
> On Mon, Jul 9, 2018 at 2:11 PM, Stefan Beller wrote:
> > On Sat, Jul 7, 2018 at 1:44 PM Elijah Newren wrote:
> >>
> >> In the case of a file/submodule conflict, although both cannot exist at
> >> the same path, we expect both to be present
Jeff King writes:
> On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:
>
>> What we've been avoiding was the comma after the last element in the
>> enum (in other words, if PGP_FMT had ',' after it in the above
>> quoted addition, that would have been violation of that rule), as
>> h
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 9 Jul 2018, Junio C Hamano wrote:
>
>> I also wonder if we should be feeding the context lines to ws.c
>> machinery in the first place though.
>
> It *is* confusing, I know. The entire "diff of diffs" concept *is*
> confusing. I just don't know
On Tue, Jul 10, 2018 at 10:52:28AM +0200, Henning Schild wrote:
> gnupg does print the keyid followed by a space and the signer comes
> next. The same pattern is also used in gpgsm, but there the key length
> would be 40 instead of 16. Instead of hardcoding the expected length,
> find the first sp
This patch broadens the set of commits matched by ":/" pathspecs to
include commits reachable from HEAD but not any named ref. This avoids
surprising behavior when working with a detached HEAD and trying to
refer to a commit that was recently created and only exists within the
detached state.
Sign
On Mon, Jul 9, 2018 at 9:44 PM, Jeff King wrote:
> On Mon, Jul 09, 2018 at 01:22:29PM -0700, Elijah Newren wrote:
>
>> Oh, I didn't know about test-lint. Is there a place that documents
>> the various checks you run, so I can avoid slowing you down? Ones I
>> know about:
>>
>> Already documented
On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:
> What we've been avoiding was the comma after the last element in the
> enum (in other words, if PGP_FMT had ',' after it in the above
> quoted addition, that would have been violation of that rule), as
> having such a trailing comma
From: "Johannes Schindelin"
Hi Phillip,
On Wed, 14 Jun 2017, Philipp Gortan wrote:
thanks for following up,
> Indeed. Why don't you give it a try?
Actually, I already did: https://github.com/patthoyts/git-gui/pull/12
You might want to post your analysis and patch there as well...
I wonde
On Mon, Jul 9, 2018 at 2:11 PM, Stefan Beller wrote:
> On Sat, Jul 7, 2018 at 1:44 PM Elijah Newren wrote:
>>
>> In the case of a file/submodule conflict, although both cannot exist at
>> the same path, we expect both to be present somewhere for the user to be
>> able to resolve the conflict with
1 - 100 of 150 matches
Mail list logo