Konstantin Khomoutov writes:
>> I do not see why the "name each rev relative to HEAD" formatting
>> option cannot produce HEAD^2~2 etc.
>> ...
> My reading was that the OP explicitly wanted to just glance at a single
> integer number and use it right away in a subsequent rebase command.
>
> I
On Thu, Dec 06, 2018 at 09:31:36AM +0900, Junio C Hamano wrote:
> >> It would be great if git-log has a formatting option to insert an
> >> index of the current commit since HEAD.
> >>
> >> It would allow after quitting the git-log to immediately fire up "git
> >> rebase -i HEAD~index" instead
Konstantin Khomoutov writes:
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
>> It would be great if git-log has a formatting option to insert an
>> index of the current commit since HEAD.
>>
>> It would allow after quitting the git-log to immediately fire up "git
>>
On Dez 05 2018, Elijah Newren wrote:
> Or, just use name-rev so it works with non-linear histories too:
>
> git log | git name-rev --refs=$(git symbolic-ref HEAD) --stdin | less
That wouldn't work for a detached HEAD, though, and you need to use
--no-abbrev.
Andreas.
--
Andreas Schwab,
On Wed, Dec 5, 2018 at 6:56 AM Konstantin Khomoutov wrote:
>
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
> > It would be great if git-log has a formatting option to insert an
> > index of the current commit since HEAD.
> >
> > It would allow after quitting the
On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
> It would be great if git-log has a formatting option to insert an
> index of the current commit since HEAD.
>
> It would allow after quitting the git-log to immediately fire up "git
> rebase -i HEAD~index" instead of "git
It would be great if git-log has a formatting option to insert an index of the
current commit since HEAD.
It would allow after quitting the git-log to immediately fire up "git rebase -i
HEAD~index" instead of "git rebase -i go-copy-paste-this-long-number-id".
"opts" will soon be moved out of cmd_checkout(). To keep changes in
that patch smaller, convert "opts" to a pointer and keep the real
thing behind "real_opts".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 109 +++--
1 file changed, 55
"git restore-files" without arguments does not make much sense when
it's about restoring files (what files now?). We could default to
either
git restore-files .
or
git restore-files :/
Neither is intuitive. Make the user always give pathspec, force the
user to think
,7 +494,7 @@ And here are the "don'ts:"
The harness will catch this as a programming error of the test.
Use test_done instead if you need to stop the tests early (see
- "Skipping tests" below).
+ "Using test prerequisites" below).
- Don't use '! git
"opts" will soon be moved out of cmd_checkout(). To keep changes in
that patch smaller, convert "opts" to a pointer and keep the real
thing behind "real_opts".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 109 +++--
1 file changed, 55
Ævar Arnfjörð Bjarmason writes:
> On Sun, Oct 21 2018, Nguyễn Thái Ngọc Duy wrote:
>
> This change has a regression in 2.20:
>
>> [...]
>> static void files_reflog_path(struct files_ref_store *refs,
>>struct strbuf *sb,
>>const char
On Sun, Oct 21 2018, Nguyễn Thái Ngọc Duy wrote:
This change has a regression in 2.20:
> [...]
> static void files_reflog_path(struct files_ref_store *refs,
> struct strbuf *sb,
> const char *refname)
> @@ -158,6 +178,9 @@ static void
There is a change in behaviour with this commit. When there was
no initial commit, the shell version of stash would still display
a message. This commit makes `push` to not display any message if
`--quiet` or `-q` is specified. Add tests for `--quiet`.
Signed-off-by: Paul-Sebastian Ungureanu
---
On 11/20/2018 1:14 AM, Jonathan Nieder wrote:
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent
On Tue, Nov 20, 2018 at 12:25:38PM +0100, SZEDER Gábor wrote:
> > but we do not
> > usually bother to do so for our helper functions (like test_cmp).
>
> test_i18ngrep() does since your 03aa3783f2 (t: send verbose
> test-helper output to fd 4, 2018-02-22).
Oh, indeed. Usually I find myself
On Mon, Nov 19, 2018 at 02:49:20PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
>
> > The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> > checking the output of two 'git rev-parse' commands, which means that
> > its output on failure is
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of turning on threading is respected.
In other words
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> checking the output of two 'git rev-parse' commands, which means that
> its output on failure is not particularly informative, as it's
> basically two OIDs with a bit
On Mon, Nov 19, 2018 at 12:42 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > When :(attr) was added, it supported one of the two main pathspec
> > matching functions, the one that works on a list of paths. The other
> > one works on a tree,
gt; From my reading of parse_pathspec_attr_match() and match_attrs() this
> isn't possible and I'd need to support ':(attr:diff!=perl)' via a new
> MATCH_NOT_VALUE mode. But I wanted to make sure I wasn't missing some
> subtlety, i.e. that this was implemented already via some other feature.
>
> I
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index d158c8d0bf..fc84db67a1 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -854,9 +854,23 @@ test_must_be_empty () {
>
> # Tests that
The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
checking the output of two 'git rev-parse' commands, which means that
its output on failure is not particularly informative, as it's
basically two OIDs with a bit of extra clutter of the diff header, but
without any indication of
> wanting to use the current working tree's / index's is the most sane
> default, and if we get the ability to read it from revisions as we
> e.g. walk the log it would make most sense to just call that
> :(treeattr:*) or something like that.
I think that ship already sailed with
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
> When :(attr) was added, it supported one of the two main pathspec
> matching functions, the one that works on a list of paths. The other
> one works on a tree, tree_entry_interesting(), which gets :(attr)
> support in this series.
>
> With
ut a concern is whether we should be making :(attr:*) behave like this
> for now. Are we going to regret it later? I don't think so, I think
> wanting to use the current working tree's / index's is the most sane
> default, and if we get the ability to read it from revisions as we
> e.g. walk th
Nguyễn Thái Ngọc Duy writes:
> But this also reveals an interesting thing: even though we walk on a
> tree, we check attributes from _worktree_ (and optionally fall back to
> the index). This is how attributes are implemented since forever. I
> think this is not a big deal if we communicate
efault, and if we get the ability to read it from revisions as we
e.g. walk the log it would make most sense to just call that
:(treeattr:*) or something like that.
Make the split index write out its .git/sharedindex_* files with the
same permissions as .git/index. This only changes the behavior when
core.sharedRepository isn't set, i.e. the user's umask settings will
be respected.
This hasn't been the case ever since the split index was originally
In order to support :(attr) when matching pathspec on a tree,
tree_entry_interesting() needs to take an index (because
git_check_attr() needs it). This is the preparation step for it. This
also makes it clearer what index we fall back to when looking up
attributes during an unpack-trees operation:
rocedure because we don't want to stick the_index (or
the_repository) here and there.
Nguyễn Thái Ngọc Duy (5):
tree.c: make read_tree*() take 'struct repository *'
tree-walk.c: make tree_entry_interesting() take an index
pathspec.h: clean up "extern" in function declarations
di
These functions call tree_entry_interesting() which will soon require
a 'struct index_state *' to be passed in. Instead of just changing the
function signature to take an index, update to take a repo instead
because these functions do need object database access.
Signed-off-by: Nguyễn Thái Ngọc
Changes since v2:
* squash patch 1/2 and patch 2/2 into a single patch
* modify first part of test when there is valid ident
present: create a stash, grab %an and %ae out of the
resulting commit object and compare to original ident
Slavica Djukic
Changes since v1:
*extend test to check whether git stash executes under valid ident
(and not under fallback one) when there is such present
*add prepare_fallback_ident() function to git-stash.sh to
provide fallback identity
Slavica Djukic (2):
Since we're going to have multiple hash algorithms to test, it makes
sense to share as much of the test code as possible. Convert the sha1
helper for the test-tool to be generic and move it out into its own
module. This will allow us to share most of this code with our NewHash
implementation.
In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we
modified hashcmp to assert that the hash size was always 20 to help it
optimize and inline calls to memcmp. In a future series, we replaced
many calls to hashcmp and oidcmp with calls to hasheq and oideq to
improve inlining
git_pathdup uses the_repository internally, but the macro
REPO_GIT_PATH_FUNC is specifically made for arbitrary repositories.
Switch to repo_git_path which works on arbitrary repositories.
Signed-off-by: Stefan Beller
---
path.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Make the behavior when diff options (e.g. "--stat") are passed
consistent with how "diff" behaves.
Before 73a834e9e2 ("range-diff: relieve callers of low-level
configuration burden", 2018-07-22) running range-diff with "--stat"
would produce stat outpu
Ævar Arnfjörð Bjarmason writes:
> diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
> index ab44e085d5..9352f65280 100755
> --- a/t/t3206-range-diff.sh
> +++ b/t/t3206-range-diff.sh
> @@ -140,37 +140,15 @@ test_expect_success 'changed commit with --stat diff
> option' '
> 1:
Eric Sunshine writes:
> On Fri, Nov 9, 2018 at 5:18 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Make the behavior when diff options (e.g. "--stat") are passed
>> consistent with how "diff" behaves.
>> [...]
>> Signed-off-by: Ævar Arnfjörð Bjar
On Fri, Nov 9, 2018 at 5:18 AM Ævar Arnfjörð Bjarmason wrote:
> Make the behavior when diff options (e.g. "--stat") are passed
> consistent with how "diff" behaves.
> [...]
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
> diff --git a/range-diff.c b/
On Friday, November 9, 2018 3:18:03 AM MST Ævar Arnfjörð Bjarmason wrote:
>
> But we should behave consistently with "diff" in anticipation of such
> output being useful in the future, because it would make for confusing
> UI if two "diff" and "range-diff&quo
Make the behavior when diff options (e.g. "--stat") are passed
consistent with how "diff" behaves.
Before 73a834e9e2 ("range-diff: relieve callers of low-level
configuration burden", 2018-07-22) running range-diff with "--stat"
would produce stat outpu
;
}
-/*
- * Note that ordering matters in this enum. Not only must it match the mapping
- * below, it is also divided into several sections that matter. When adding
- * new commands, make sure you add it in the right section.
- */
-enum todo_command {
- /* commands that handle commits
This makes sequencer_make_script() write its script to a strbuf (ie. the
buffer of a todo_list) instead of a FILE. This reduce the amount of
read/write made by rebase interactive.
Signed-off-by: Alban Gruin
---
builtin/rebase--interactive.c | 13 +++-
sequencer.c | 38
Addresses all the feedback against v3. Includes a patch by Junio
sitting in "pu" (and I fixed the grammar error Eric pointed out in its
commit message).
Range-diff:
1: cc24ba8de8 ! 1: 2210ee8bd9 i18n: make GETTEXT_POISON a runtime option
@@ -34,11 +34,11 @@
epend on the US
English
version of the strings, e.g. to grep some error message or other
output.
-To smoke out issues like these Git can be compiled with gettext poison
-support, at the top-level:
+To smoke out issues like these, Git tested with a translation mode that
+emits gibberish o
On Thu, Nov 08, 2018 at 09:26:19PM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Nov 02 2018, SZEDER Gábor wrote:
> >> * We error out in the Makefile if you're still saying
> >>GETTEXT_POISON=YesPlease.
> >>
> >>This makes more sense than just making it a synonym since now this
> >>
On Fri, Nov 02 2018, SZEDER Gábor wrote:
> On Thu, Nov 01, 2018 at 07:31:15PM +, Ævar Arnfjörð Bjarmason wrote:
>> Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
>> test parameter to only be a GIT_TEST_GETTEXT_POISON=
>> runtime parameter, to be consistent with other
On Wed, Nov 7, 2018 at 10:24 PM Junio C Hamano wrote:
> Makefile: ease dynamic-gettext-poison transition
>
> Earlier we made the entire build to fail when GETTEXT_POISON=Yes is
> given to make, to notify those who did not notice that text poisoning
> is now a runtime behaviour.
&
elper and do everything
> inside cmd_branch(), so perhaps this can be made function local, no?
>
I was not sure if these 3 lines were global intentionally or if it was
just an artifact from the past. Since it looks like the latter, I'll
make them local.
--
Rafael Ascensão
TEXT_POISON=Yes is
given to make, to notify those who did not notice that text poisoning
is now a runtime behaviour.
It turns out that this too irritating for those who need to build
and test different versions of Git that cross the boundary between
history with and without this topic to switch between t
Rafael Ascensão writes:
> print_current_branch_name() tries to resolve HEAD and die() when it
> doesn't resolve it successfully. But the conditions being tested are
> always unreachable because early in branch:cmd_branch() the same logic
> is performed.
>
> Eliminate the duplicate and
print_current_branch_name() tries to resolve HEAD and die() when it
doesn't resolve it successfully. But the conditions being tested are
always unreachable because early in branch:cmd_branch() the same logic
is performed.
Eliminate the duplicate and unreachable code, and update the current
logic
nr_objects' [-Wunused-parameter]
likely an oversight as the information needed to iterate over is
embedded in nr_large_offset
I've been preparing a series to make the whole code base compile with
-Wunused-parameter, and I handled this case a bit differently.
-- >8 --
Subject: [PATCH] midx: double-check
Since we're going to have multiple hash algorithms to test, it makes
sense to share as much of the test code as possible. Convert the sha1
helper for the test-tool to be generic and move it out into its own
module. This will allow us to share most of this code with our NewHash
implementation.
In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we
modified hashcmp to assert that the hash size was always 20 to help it
optimize and inline calls to memcmp. In a future series, we replaced
many calls to hashcmp and oidcmp with calls to hasheq and oideq to
improve inlining
parameter]
>
> likely an oversight as the information needed to iterate over is
> embedded in nr_large_offset
I've been preparing a series to make the whole code base compile with
-Wunused-parameter, and I handled this case a bit differently.
-- >8 --
Subject: [PATCH] midx: do
introduced in 662148c435 ("midx: write object offsets", 2018-07-12)
but included on all previous versions as well.
midx.c:713:54: warning: unused parameter 'nr_objects' [-Wunused-parameter]
likely an oversight as the information needed to iterate over is
embedded in nr_large_offset
On Thu, Nov 01, 2018 at 07:31:15PM +, Ævar Arnfjörð Bjarmason wrote:
> Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
> test parameter to only be a GIT_TEST_GETTEXT_POISON=
> runtime parameter, to be consistent with other parameters documented
> in "Running tests with
On 11/2/2018 10:58 AM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 12:02 PM Derrick Stolee wrote:
On 11/1/2018 2:57 PM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
No rush. I'd just like to understand how removing the commit-graph file
can make the new
On Thu, Nov 1, 2018 at 12:02 PM Derrick Stolee wrote:
>
> On 11/1/2018 2:57 PM, Elijah Newren wrote:
> > On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
> >> No rush. I'd just like to understand how removing the commit-graph file
> >> can make the new algor
().
Thanks, -Stolee
[1]
https://public-inbox.org/git/cabpp-becpsoxudovjbdg_3w9wus102rw+e+qpmd4g3qyd-q...@mail.gmail.com/
Derrick Stolee (3):
commit-reach: implement get_reachable_subset
test-reach: test get_reachable_subset
remote: make add_missing_tags() linear
commit-reach.c| 70
From: Derrick Stolee
The add_missing_tags() method currently has quadratic behavior.
This is due to a linear number (based on number of tags T) of
calls to in_merge_bases_many, which has linear performance (based
on number of commits C in the repository).
Replace this O(T * C) algorithm with an
Ævar Arnfjörð Bjarmason writes:
> Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
> test parameter to only be a GIT_TEST_GETTEXT_POISON=
> runtime parameter, to be consistent with other parameters documented
> in "Running tests with special setups" in t/README.
> ...
>
ef4c0f0b5..aa704ffcb7 100644
--- a/po/README
+++ b/po/README
@@ -289,16 +289,11 @@ something in the test suite might still depend on the US
English
version of the strings, e.g. to grep some error message or other
output.
-To smoke out issues like these Git can be compiled with gettext poison
-support, at t
On 11/1/2018 2:57 PM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
No rush. I'd just like to understand how removing the commit-graph file
can make the new algorithm faster. Putting a similar count in the old
algorithm would involve giving a count for every call
nvironment, do you mind applying the diff
> >> below and re-running the tests? It will output a count for how many
> >> commits are walked by the algorithm. This should help us determine if
> >> this is another case where generation numbers are worse than commit-date,
> >
H--I--K--L
+# \ \ / /
+# \ \ / /
+#C--E---F J
+#\_/
+#
+# The commits are laid out from left-to-right starting with
+# the root commit A and terminating at the tip commit L.
+#
+# There are a few places where we adjust the commit date or
+# author da
imilar patch for the old
get_merge_bases_many() in order to compare? Does an absolute number
help by itself?
It's going to have to be tomorrow, though; not enough time tonight.
No rush. I'd just like to understand how removing the commit-graph file
can make the new algorithm faster. Putting a s
Enhancement request that ask for 'git stash' to work even if
'user.name' and 'user.email' are not configured.
Due to an implementation detail, git-stash undesirably requires
'user.name' and 'user.email' to be set, but shouldn't.
Slavica Djukic(3):
[Outreachy] t3903-stash: test without
On Wed, Oct 31, 2018 at 5:05 AM Derrick Stolee wrote:
>
> On 10/31/2018 2:04 AM, Elijah Newren wrote:
> > On Tue, Oct 30, 2018 at 7:16 AM Derrick Stolee via GitGitGadget
> > wrote:
> >>
> >> As reported earlier [1], the add_missing_tags() method in remote.c has
> >> quadratic performance. Some
This is yet another piece from the Git for Windows cake. It avoids a
wrap-around in the poll emulation on Windows that occurs every 49 days.
Steve Hoelzer (1):
poll: use GetTickCount64() to avoid wrap-around issues
compat/poll/poll.c | 10 +++---
1 file changed, 7 insertions(+), 3
On 10/31/2018 2:04 AM, Elijah Newren wrote:
> On Tue, Oct 30, 2018 at 7:16 AM Derrick Stolee via GitGitGadget
> wrote:
>>
>> As reported earlier [1], the add_missing_tags() method in remote.c has
>> quadratic performance. Some of that performance is curbed due to the
>> generation-number cutoff
On Tue, Oct 30, 2018 at 7:16 AM Derrick Stolee via GitGitGadget
wrote:
>
> As reported earlier [1], the add_missing_tags() method in remote.c has
> quadratic performance. Some of that performance is curbed due to the
> generation-number cutoff in in_merge_bases_many(). However, that fix doesn't
>
"Derrick Stolee via GitGitGadget" writes:
> Add a new method in commit-reach.c called get_reachable_subset() which does
> a many-to-many reachability test. Starting at the 'from' commits, walk until
> the generation is below the smallest generation in the 'to' commits, or all
> 'to' commits have
Pass the object pool to free_commit_buffer and release_commit_memory,
such that we can eliminate access to 'the_repository'.
Also remove the TODO in release_commit_memory, as commit->util was
removed in 9d2c97016f (commit.h: delete 'util' field in struct commit,
2018-05-19)
Signed-off-by: Stefan
git_pathdup uses the_repository internally, but the macro
REPO_GIT_PATH_FUNC is specifically made for arbitrary repositories.
Switch to repo_git_path which works on arbitrary repositories.
Signed-off-by: Stefan Beller
---
path.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Derrick Stolee
The add_missing_tags() method currently has quadratic behavior.
This is due to a linear number (based on number of tags T) of
calls to in_merge_bases_many, which has linear performance (based
on number of commits C in the repository).
Replace this O(T * C) algorithm with an
().
Thanks, -Stolee
[1]
https://public-inbox.org/git/cabpp-becpsoxudovjbdg_3w9wus102rw+e+qpmd4g3qyd-q...@mail.gmail.com/
Derrick Stolee (3):
commit-reach: implement get_reachable_subset
test-reach: test get_reachable_subset
remote: make add_missing_tags() linear
commit-reach.c| 70
This makes sequencer_make_script() write its script to a strbuf (ie. the
buffer of a todo_list) instead of a FILE. This reduce the amount of
read/write made by rebase interactive.
Signed-off-by: Alban Gruin
---
builtin/rebase--interactive.c | 13 +++-
sequencer.c | 38
)
return 1;
}
-/*
- * Note that ordering matters in this enum. Not only must it match the mapping
- * below, it is also divided into several sections that matter. When adding
- * new commands, make sure you add it in the right section.
- */
-enum todo_command {
- /* commands
On Sat, Oct 27 2018, Jeff King wrote:
> On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> >> I was thinking:
>> >>
>> >> $ git var -e GIT_WHATEVER_ENV
>> >>
>> >> [-e for environment].
>> >>
>> >> ... but that is really no different than git-config. ;-)
>> >
>> >
On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> I was thinking:
> >>
> >> $ git var -e GIT_WHATEVER_ENV
> >>
> >> [-e for environment].
> >>
> >> ... but that is really no different than git-config. ;-)
> >
> > Actually, "git var" already does pull bits from the
On Thu, Oct 25 2018, Jeff King wrote:
> On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
>
>> >> Yeah, my thinko. The latter would be closer to what this patch
>> >> wants to have, but obviously the former would be more flexible and
>> >> useful in wider context. Both have the
On Thu, Oct 25, 2018 at 6:59 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> >> In this series I am addressing the comments by Stefan Beller about the
> >> tests in patch 9.
> >>
> >> If the new tests look OK, I'd say we try moving the series to "next" and
> >> see what happens?
> >
> >
Stefan Beller writes:
>> In this series I am addressing the comments by Stefan Beller about the
>> tests in patch 9.
>>
>> If the new tests look OK, I'd say we try moving the series to "next" and
>> see what happens?
>
> Sounds good to me.
Which means (1) the plan sounds OK but I didn't look at
On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
> >> Yeah, my thinko. The latter would be closer to what this patch
> >> wants to have, but obviously the former would be more flexible and
> >> useful in wider context. Both have the "Huh?" factor---what they
> >> are doing has
> In this series I am addressing the comments by Stefan Beller about the
> tests in patch 9.
>
> If the new tests look OK, I'd say we try moving the series to "next" and
> see what happens?
Sounds good to me.
Thanks,
Stefan
vcsh[1] which manage multiple repositories with
their working trees sharing the same path.
[1] https://github.com/RichiH/vcsh
In the previous series there were some comments about not using the enum
in patch 8, but I decided to leave the code as it was as I still think
that it make sense to use
On Thu, 25 Oct 2018 17:40:47 +0900
Junio C Hamano wrote:
> Antonio Ospite writes:
>
> > this series teaches git to try and read the .gitmodules file from the
> > index (:.gitmodules) or from the current branch (HEAD:.gitmodules) when
> > the file is not readily available in the working tree.
>
Antonio Ospite writes:
> this series teaches git to try and read the .gitmodules file from the
> index (:.gitmodules) or from the current branch (HEAD:.gitmodules) when
> the file is not readily available in the working tree.
What you said in [*1*] the discussion on [09/10] sounded like you
are
Since we're going to have multiple hash algorithms to test, it makes
sense to share as much of the test code as possible. Convert the sha1
helper for the test-tool to be generic and move it out into its own
module. This will allow us to share most of this code with our NewHash
implementation.
In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we
modified hashcmp to assert that the hash size was always 20 to help it
optimize and inline calls to memcmp. In a future series, we replaced
many calls to hashcmp and oidcmp with calls to hasheq and oideq to
improve inlining
On 25/10/2018 02:09, Jeff King wrote:
> On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> but then you lose the default handling. I think if we added a new
>>> option, it would either be:
>>>
>>> # interpret a value directly; use default on empty,
On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > but then you lose the default handling. I think if we added a new
> > option, it would either be:
> >
> > # interpret a value directly; use default on empty, I guess?
> > git config --default=false
Jeff King writes:
> but then you lose the default handling. I think if we added a new
> option, it would either be:
>
> # interpret a value directly; use default on empty, I guess?
> git config --default=false --type=bool --interpret-value "$GIT_WHATEVER_ENV"
>
> or
>
> # less flexible,
return !git_env_bool("GIT_TEST_GETTEXT_POISON", 0);
>
> Hmm? If "--[no-]git-test-gettext-poison" is given, poison is either
> 0 or 1, and we return the value we read from the environment? What
> convoluted way to implement the option is that, or is there anythi
On Wed, Oct 24, 2018 at 02:45:49PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Notes on the implementation:
> >
> > * The only reason we need a new "git-sh-i18n--helper" and the
> >corresponding "test-tool gettext-poison" is to expose
> >git_env_bool() to
onment? What
convoluted way to implement the option is that, or is there anything
subtle that I am not getting?
If the "default" parameter to git_env_bool() were poison, and then
the option was renamed to "--get-git-text-gettext-poison", then I
sort of understand the code, though (it's l
1 - 100 of 5712 matches
Mail list logo
