On Thu, Jul 12, 2018 at 7:52 PM Jeff King wrote:
> (I do agree that being able to automatically catch these with a linter
> would be worth brain cycles, but I cannot immediately think a of a way
> to do so).
Perhaps something like this[1]?
[1]:
Error messages emitted by this linting script are long and noisy,
consisting of several sections:
:: error: :
Many problem explanations ask the reader to "please" use a suggested
alternative, however, such politeness is unnecessary and just adds to
the noise and length of the line, so drop
One-shot environment variable assignments, such as 'FOO' in
"FOO=bar cmd", exist only during the invocation of 'cmd'. However, if
'cmd' happens to be a shell function, then 'FOO' is assigned in the
executing shell itself, and that assignment remains until the process
exits (unless explicitly
Error messages emitted by this linting script are long and noisy,
consisting of several sections:
:: error: :
The line of failed shell text, usually coming from within a test body,
is often indented by one or two TABs, with the result that the actual
(important) text is separated from by a
Unlike "FOO=bar cmd" one-shot environment variable assignments
which exist only for the invocation of 'cmd', those assigned by
"FOO=bar shell_func" exist within the running shell and continue to
do so until the process exits (or are explicitly unset). It is
unlikely that this behavior was intended
One-shot "FOO=bar cmd" environment variable assignments exist only
during invocation of 'cmd'. However, if 'cmd' is a shell function, then
the variable is assigned in the running shell and exists until the
process exits (or is unset explicitly). Such a side-effect is almost
certainly unintended by
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
On 7/12/2018 5:05 PM, Junio C Hamano wrote:
Derrick Stolee writes:
The core.multiPackIndex config setting controls the multi-pack-
index (MIDX) feature. If false, the setting will disable all reads
from the multi-pack-index file.
Read this config setting in the new
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
deref_tag() prints a warning if the object that a tag refers to does not
exist. However, when a partial clone has an annotated tag from its
promisor remote, but not the object that it refers to, printing a
warning on such a tag is incorrect.
This occurs, for example, when the checkout that
In handle_commit(), it is fatal for an annotated tag to point to a
non-existent object. --exclude-promisor-objects should relax this rule
and allow non-existent objects that are promisor objects, but this is
not the case. Update handle_commit() to tolerate this situation.
This was observed when
These are based on jt/partial-clone-fsck-connectivity.
The patches in jt/partial-clone-fsck-connectivity were motivated by bugs
I discovered in partial clones when refs pointed to blobs directly.
While continuing to work on this, I noticed issues with annotated tags -
that is, refs pointing to
On Thu, Jul 12, 2018 at 01:31:49PM -0700, Junio C Hamano wrote:
> >> ...would you want to use test_when_finished here (both for robustness,
> >> but also to make it more clear to a reader what's going on)?
> >
> > Perhaps.
>
> Yes, but this one ends up to be overly ugly.
>
> The restoreing of
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
On Thu, Jul 12, 2018 at 3:40 PM Derrick Stolee wrote:
> In anticipation of writing multi-pack-indexes, add a skeleton
> 'git multi-pack-index write' subcommand and send the options to a
> write_midx_file() method. Also create a skeleton test script that
> tests the 'write' subcommand.
>
>
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
Stefan Beller writes:
> The 'mode' variable is not used in cmd_update for its original purpose,
> rename it to 'dummy' as it only serves the purpose to abort quickly
> documenting this knowledge.
It seems that
(1) the while loop in git-submodule.sh we see in this patch is the
only thing
Stefan Beller writes:
> All other error messages in cmd_update are reporting the submodule based
> on its path, so let's do that for invalid update modes, too.
>
> Signed-off-by: Stefan Beller
> ---
Makes sense.
> git-submodule.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Derrick Stolee writes:
> * The global 'core_multi_pack_index' is replaced with a one-time call to
> git_config_bool() per repository that loads a multi-pack-index.
OK. I guess that is more consistent, as the configuration would be
per-repo and multi-pack-index is per object-store.
After a
Derrick Stolee writes:
> The core.multiPackIndex config setting controls the multi-pack-
> index (MIDX) feature. If false, the setting will disable all reads
> from the multi-pack-index file.
>
> Read this config setting in the new prepare_multi_pack_index_one()
> which is called during
Stefan Beller writes:
> In practice we always want to stack the settings starting with the
> .gitmodules file as a base and then put the config on top of it.
Could you substantiate this claim with justification? Thanks.
Junio C Hamano writes:
> I _think_ the right and safe way to fix taht is to do something like
> this:
>
> test -f .git/rebase-merge/author-script &&
> (
> safe_unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL ... &&
> eval "$(cat .git/rebase-merge/author-script)" &&
Ben Peart writes:
>> > Thanks. I thought it was strange as well until I realized you only
>> > see the error message if there _isn't_ a valid drive letter so seeing
>> > the entire path makes sense as it will likely be something like
>> "\\server\volume\directory"
>>
>> Yup, that is why I
Junio C Hamano writes:
>>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>>> index 7e9f375a24..fd43443ff5 100755
>>> --- a/t/t3404-rebase-interactive.sh
>>> +++ b/t/t3404-rebase-interactive.sh
>>> @@ -280,8 +280,11 @@ test_expect_success 'retain authorship w/
Jeff King writes:
> On Thu, Jul 12, 2018 at 01:07:51PM -0700, Junio C Hamano wrote:
>
>> Bash may take it happily but running test with dash reveals a breakage.
>>
>> This was not discovered for a long time as no tests after this test
>> depended on GIT_AUTHOR_NAME to be reverted correctly back
Yup ;-)
On Thu, Jul 12, 2018 at 1:16 PM, Eric Sunshine wrote:
> On Thu, Jul 12, 2018 at 4:13 PM Junio C Hamano wrote:
>> I _think_ the right and safe way to fix taht is to do something like
>> this:
>>
>> test -f .git/rebase-merge/author-script &&
>> (
>>
On Thu, Jul 12, 2018 at 4:13 PM Junio C Hamano wrote:
> I _think_ the right and safe way to fix taht is to do something like
> this:
>
> test -f .git/rebase-merge/author-script &&
> (
> safe_unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL ... &&
s/safe_unset/sane_unset/
>
On Thu, Jul 12, 2018 at 01:07:51PM -0700, Junio C Hamano wrote:
> Bash may take it happily but running test with dash reveals a breakage.
>
> This was not discovered for a long time as no tests after this test
> depended on GIT_AUTHOR_NAME to be reverted correctly back to the
> original value
"Akinori MUSHA" writes:
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 352a52e59..345b103eb 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -75,6 +75,19 @@ test_expect_success 'rebase --keep-empty' '
>
> > Thanks. I thought it was strange as well until I realized you only
> > see the error message if there _isn't_ a valid drive letter so seeing
> > the entire path makes sense as it will likely be something like
> "\\server\volume\directory"
>
> Yup, that is why I thought Dscho meant to say
Bash may take it happily but running test with dash reveals a breakage.
This was not discovered for a long time as no tests after this test
depended on GIT_AUTHOR_NAME to be reverted correctly back to the
original value after this step is done.
Signed-off-by: Junio C Hamano
---
* We could
Contents look good to me. I don't understand why the file name in your
patch is sha1_name.c as opposed to sha1-name.c (I see e5e5e0883 from
2018-04-10, but that sounds pretty old), but I trust that whatever
you're doing there is correct.
> Thanks for working on this.
You're quite welcome. Thanks
Eric Sunshine writes:
> However, existing tests aside, the more important goal is detecting
> problems in new or updated tests hiding genuine bugs in changes to Git
> itself, so it may have some value.
Yes, indeed.
Ben Peart writes:
>> -Original Message-
>> From: Junio C Hamano On Behalf Of Junio C Hamano
>> Sent: Thursday, July 12, 2018 3:13 PM
>> To: Ben Peart
>> Cc: git@vger.kernel.org; sbel...@google.com; johannes.schinde...@gmx.de
>> Subject: Re: [PATCH v3] handle lower case drive letters on
Separate the command line parsing from the actual execution of the command
within the repository. For now there is not a lot of execution as
most of it is still in git-submodule.sh.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 59 +
1 file
The information that is printed for update_submodules in
'submodule--helper update-clone' and consumed by 'git submodule update'
is stored as a string per submodule. This made sense at the time of
48308681b07 (git submodule update: have a dedicated helper for cloning,
2016-02-29), but as we want
The 'mode' variable is not used in cmd_update for its original purpose,
rename it to 'dummy' as it only serves the purpose to abort quickly
documenting this knowledge.
The variable 'stage' is also not used any more in cmd_update, so remove it.
This went unnoticed as first each function used the
In a later patch we'll find this method handy.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index c9c3fe2bf28..4bbf580df79 100644
All other error messages in cmd_update are reporting the submodule based
on its path, so let's do that for invalid update modes, too.
Signed-off-by: Stefan Beller
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index
This chews off a bit of the shell part of the update command in
git-submodule.sh. When writing the C code, keep in mind that the
submodule--helper part will go away eventually and we want to have
a C function that is able to determine the submodule update strategy,
it as a nicety, make
I thought about writing it all in one go, but the series got too large,
so let's chew one bite at a time.
Thanks,
Stefan
Stefan Beller (6):
git-submodule.sh: align error reporting for update mode to use path
git-submodule.sh: rename unused variables
builtin/submodule--helper: factor out
Signed-off-by: Derrick Stolee
---
packfile.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/packfile.c b/packfile.c
index 2c819a0ad8..e6ecf12ab5 100644
--- a/packfile.c
+++ b/packfile.c
@@ -469,8 +469,19 @@ static int open_packed_git_1(struct packed_git
If a 'git repack' command replaces existing packfiles, then we must
clear the existing multi-pack-index before moving the packfiles it
references.
Signed-off-by: Derrick Stolee
---
builtin/repack.c| 9 +
midx.c | 12
midx.h
Due to how Windows handles replacing a lockfile when there is an open
handle, create the close_midx() method to close the existing midx before
writing the new one.
Signed-off-by: Derrick Stolee
---
midx.c | 116 ++---
midx.h | 1 +
2 files
The multi-pack-index, when present, tracks the existence of objects and
their offsets within a list of packfiles. This allows us to use the
multi-pack-index for object lookups, abbreviations, and object counts.
When the multi-pack-index tracks a packfile, then we do not need to add
that packfile
When constructing a multi-pack-index file for a given object directory,
read the files within the enclosed pack directory and find matches that
end with ".idx" and find the correct paired packfile using
add_packed_git().
Signed-off-by: Derrick Stolee
---
midx.c | 48
Signed-off-by: Derrick Stolee
---
Documentation/technical/pack-format.txt | 4 +++
midx.c | 47 +++--
midx.h | 1 +
t/helper/test-read-midx.c | 2 ++
t/t5319-multi-pack-index.sh |
The core.multiPackIndex config setting controls the multi-pack-
index (MIDX) feature. If false, the setting will disable all reads
from the multi-pack-index file.
Read this config setting in the new prepare_multi_pack_index_one()
which is called during prepare_packed_git(). This check is run once
Signed-off-by: Derrick Stolee
---
midx.c | 11 +
midx.h | 3 +++
packfile.c | 6 +
packfile.h | 1 +
sha1-name.c | 70 +
5 files changed, 91 insertions(+)
diff --git a/midx.c b/midx.c
index 182535933c..4e014ff6e3
In anticipation of sharing the pack directory listing with the
multi-pack-index, generalize prepare_packed_git_one() into
for_each_file_in_pack_dir().
Signed-off-by: Derrick Stolee
---
packfile.c | 101 +
packfile.h | 6
2 files
Signed-off-by: Derrick Stolee
---
midx.c | 91 +-
midx.h | 3 ++
packfile.c | 8 -
3 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/midx.c b/midx.c
index 4090cf4ca4..182535933c 100644
--- a/midx.c
+++ b/midx.c
@@
Before writing a list of objects and their offsets to a multi-pack-index,
we need to collect the list of objects contained in the packfiles. There
may be multiple copies of some objects, so this list must be deduplicated.
It is possible to artificially get into a state where there are many
Signed-off-by: Derrick Stolee
---
packfile.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/packfile.c b/packfile.c
index c0eb5ac885..97e7812b6b 100644
--- a/packfile.c
+++ b/packfile.c
@@ -861,10 +861,13 @@ unsigned long approximate_object_count(void)
{
if
The final pair of chunks for the multi-pack-index file stores the object
offsets. We default to using 32-bit offsets as in the pack-index version
1 format, but if there exists an offset larger than 32-bits, we use a
trick similar to the pack-index version 2 format by storing all offsets
at least
Signed-off-by: Derrick Stolee
---
Documentation/technical/pack-format.txt | 5 +++
midx.c | 53 +++--
midx.h | 1 +
t/helper/test-read-midx.c | 4 +-
t/t5319-multi-pack-index.sh |
Signed-off-by: Derrick Stolee
---
midx.c | 17 +
midx.h | 1 +
t/helper/test-read-midx.c | 5 +
t/t5319-multi-pack-index.sh | 17 -
4 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/midx.c b/midx.c
The multi-pack-index needs to track which packfiles it indexes. Store
these in our first required chunk. Since filenames are not well
structured, add padding to keep good alignment in later chunks.
Modify the 'git multi-pack-index read' subcommand to output the
existence of the pack-file name
As we build the multi-pack-index file format, we want to test the format
on real repositories. Add tests that create repository data including
multiple packfiles with both version 1 and version 2 formats.
The current 'git multi-pack-index write' command will always write the
same file with no
As we begin writing the multi-pack-index format to disk, start with
the basics: the 12-byte header and the 20-byte checksum footer. Start
with these basics so we can add the rest of the format in small
increments.
As we implement the format, we will use a technique to check that our
computed
In anticipation of writing multi-pack-indexes, add a skeleton
'git multi-pack-index write' subcommand and send the options to a
write_midx_file() method. Also create a skeleton test script that
tests the 'write' subcommand.
Signed-off-by: Derrick Stolee
---
Create a new multi_pack_index struct for loading multi-pack-indexes into
memory. Create a test-tool builtin for reading basic information about
that multi-pack-index to verify the correct data is written.
Signed-off-by: Derrick Stolee
---
Makefile| 1 +
midx.c
This new 'git multi-pack-index' builtin will be the plumbing access
for writing, reading, and checking multi-pack-index files. The
initial implementation is a no-op.
Signed-off-by: Derrick Stolee
---
.gitignore | 3 ++-
Documentation/git-multi-pack-index.txt | 36
v3 had a lot of interesting feedback, most of which was non-functional,
but made a big impact on the shape of the patch, especially the test
script.
These are the important changes:
* 'git multi-pack-index' will report usage if the 'write' verb is not
provided, or if extra parameters are
Signed-off-by: Derrick Stolee
---
Documentation/technical/multi-pack-index.txt | 109 +++
1 file changed, 109 insertions(+)
create mode 100644 Documentation/technical/multi-pack-index.txt
diff --git a/Documentation/technical/multi-pack-index.txt
The multi-pack-index feature generalizes the existing pack-index
feature by indexing objects across multiple pack-files.
Describe the basic file format, using a 12-byte header followed by
a lookup table for a list of "chunks" which will be described later.
The file ends with a footer containing a
On Thu, Jul 12, 2018 at 12:56 PM Jeff King wrote:
> Like Junio, I'm a little nervous that this is going to end up being a
> maintenance burden. People may hit false positives and then be
> confronted with this horrible mass of sed to try to figure out what went
> wrong [...]
A very valid
> -Original Message-
> From: Junio C Hamano On Behalf Of Junio C Hamano
> Sent: Thursday, July 12, 2018 3:13 PM
> To: Ben Peart
> Cc: git@vger.kernel.org; sbel...@google.com; johannes.schinde...@gmx.de
> Subject: Re: [PATCH v3] handle lower case drive letters on Windows
>
> Ben Peart
Ben Peart writes:
> On Windows, if a tool calls SetCurrentDirectory with a lower case drive
> letter, the subsequent call to GetCurrentDirectory will return the same
> lower case drive letter. Powershell, for example, does not normalize the
> path. If that happens, test-drop-caches will error
William Chargin writes:
>> As we discussed during the review on v1, ":/"
>> is *NOT* pathspec (that is why having these tests in t4208 is wrong
>> but we are following existing mistakes).
>
> Ah, I understand the terminology better now. Thanks. I'll change the
> commit message wording to use
The series merged at 614ea03a71e (Merge branch
'bw/submodule-config-cleanup', 2017-08-26) went to great length to make it
explicit to the caller where a value came from, as that would help the
caller to be careful to decide which values to take from where, i.e. be
careful about security
Howdy, I want to hack the getweb_make_index.perl script to create a
string search using:
https://github.com/git/git/blob/master/levenshtein.c.
How do i reference the compiled code?
I would like to call this routine using Java and maybe Perl.
Please advise.
Thanks.
Regards,
On Thu, Jul 12, 2018 at 2:50 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > The exact reason is that the prerequisite was not met (indeed, I
> > wasn't even aware of that prerequisite), so the commit message can be
> > more direct:
> >
> > This was missed by the previous clean-ups due
Eric Sunshine writes:
> On Thu, Jul 12, 2018 at 2:35 PM Junio C Hamano wrote:
>> Junio C Hamano writes:
>> Oops, sent before completing the message.
>>
>> For that to happen, we need a sign-off ;-)
>>
>> I guess this one would have been caught with the "sed script on
>> subshell"
Ramsay Jones writes:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> I had a test failure on 'pu' today - Eric's chain-lint series
> found another broken chain in one of Elijah's new tests (on the
> 'en/t6036-recursive-corner-cases' branch).
Thanks, I see the same breakage in my build,
On Thu, Jul 12, 2018 at 2:35 PM Junio C Hamano wrote:
> Junio C Hamano writes:
> Oops, sent before completing the message.
>
> For that to happen, we need a sign-off ;-)
>
> I guess this one would have been caught with the "sed script on
> subshell" linter that does not execute?
Yes,
Junio C Hamano writes:
> Eric Sunshine writes:
>
>> On Thu, Jul 12, 2018 at 8:37 AM SZEDER Gábor wrote:
>>> The change below should be squashed into this patch to fix a
>>> previously unnoticed broken &&-chain. I think you missed it, because
>>> this test script is rather expensive and you
Eric Sunshine writes:
> On Thu, Jul 12, 2018 at 8:37 AM SZEDER Gábor wrote:
>> The change below should be squashed into this patch to fix a
>> previously unnoticed broken &&-chain. I think you missed it, because
>> this test script is rather expensive and you didn't run it with
>>
Junio C Hamano writes:
> If I am reading the body of this if() block correctly, I think it
> does everything init_revisions_and_shortrevisions shell function
> does, i.e. compute $revisions for both cases with or without
> upstream and write squash-onto state if needed, so that we can call
> the
On Thu, Jul 12, 2018 at 01:44:49PM -0400, Eric Sunshine wrote:
> On Thu, Jul 12, 2018 at 8:37 AM SZEDER Gábor wrote:
> > The change below should be squashed into this patch to fix a
> > previously unnoticed broken &&-chain. I think you missed it, because
> > this test script is rather expensive
Alban Gruin writes:
> @@ -50,6 +71,13 @@ int cmd_rebase__helper(int argc, const char **argv, const
> char *prefix)
> N_("prepare the branch to be rebased"),
> PREPARE_BRANCH),
> OPT_CMDMODE(0, "complete-action", ,
> N_("complete
On 7/12/2018 2:02 PM, Eric Sunshine wrote:
On Thu, Jul 12, 2018 at 10:10 AM Derrick Stolee wrote:
On 7/6/2018 12:36 AM, Eric Sunshine wrote:
There seems to be a fair bit of duplication in these tests which
create objects. Is it possible to factor out some of this code into a
shell function?
On Thu, Jul 12, 2018 at 10:10 AM Derrick Stolee wrote:
> On 7/6/2018 12:36 AM, Eric Sunshine wrote:
> > There seems to be a fair bit of duplication in these tests which
> > create objects. Is it possible to factor out some of this code into a
> > shell function?
>
> In addition to the other small
On Thu, Jul 12, 2018 at 8:37 AM SZEDER Gábor wrote:
> The change below should be squashed into this patch to fix a
> previously unnoticed broken &&-chain. I think you missed it, because
> this test script is rather expensive and you didn't run it with
> GIT_TEST_CLONE_2GB=YesPlease.
>
> diff
On 7/11/2018 6:42 PM, Jonathan Tan wrote:
This is on _both_ ds/commit-graph-fsck and sb/object-store-lookup,
following Stolee's suggestion.
(It also seems better to build it this way to me, since both these
branches are going into "next" according to the latest What's Cooking.)
Junio wrote in
On Thu, Jul 12, 2018 at 8:23 AM Junio C Hamano wrote:
>
> Vitali Lovich writes:
>
> > Repro (starting with cwd within git project):
> >> (cd xdiff; git rev-parse --show-toplevel)
> > ... path to git repository
> >> git rebase -i 18404434bf406f6a6f892ed73320c5cf9cc187dd
> > # Stop at some commit
SZEDER Gábor writes:
>> Thanks for this point. It seems to work using
>> "link:technical/multi-pack-index[1]", which is what I'll use in the next
>> version.
>
> It doesn't work, it merely works around the build failure.
Sorry. I fell into the same trap X-<.
"Akinori MUSHA" writes:
> It looks like write_author_script() intends to write out a file in
> Bourne shell syntax, but it doesn't put a closing single quote on the
> last line.
s/closing single quote/& and the terminating newline/?
>
> This patch makes .git/rebase-merge/author-script actually
Aaron Schrab writes:
> Subject: [PATCH v2] sequencer: use configured comment character
>
> Use the configured comment character when generating comments about
> branches in a todo list. Failure to honor this configuration causes a
> failure to parse the resulting todo list.
OK.
>
> Note that
2018-07-12 18:57 GMT+03:00 Ramsay Jones :
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Olga,
>
> If you need to re-roll your 'ot/ref-filter-object-info' branch,
> could you please squash this into the relevant patch (commit c5d9a471d6,
> "ref-filter: use oid_object_info() to get object",
Johannes Schindelin writes:
> I would like to ask you to reinstate the post-rewrite hook, as it still
> improves the situation over the current one.
Without post-rewrite I seem to be getting correct amlog entries for
commits created by "git rebase"; do our rebase--am backend still
trigger
On Thu, Jul 12, 2018 at 06:50:20AM -0400, Eric Sunshine wrote:
> And, perhaps most important: We're not tied indefinitely to the
> "subset" implemented by the current linter. If it is indeed found to
> be too strict or limiting, it can always be loosened or retired
> altogether.
Yeah, I agree
1 - 100 of 144 matches
Mail list logo
