[PATCH v2] l10n: de.po: translate 72 new messages

[Ralf Thielow]

Translate 72 new messages came from git.pot update in 18a907225 (l10n:
git.pot: v2.16.0 round 1 (64 new, 25 removed)) and 005c62fe4 (l10n:
git.pot: v2.16.0 round 2 (8 new, 4 removed)).

Signed-off-by: Ralf Thielow 
---

Thanks for the review, Matthias!

 po/de.po | 227 +++
 1 file changed, 98 insertions(+), 129 deletions(-)

diff --git a/po/de.po b/po/de.po
index b24b28875..eef4897fb 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1716,7 +1716,7 @@ msgstr "Konnte Git-Verzeichnis nicht von '%s' nach '%s' 
migrieren."
 #: editor.c:61
 #, c-format
 msgid "hint: Waiting for your editor to close the file...%c"
-msgstr ""
+msgstr "Hinweis: Warte auf das Schließen der Datei durch Ihren Editor...%c"
 
 #: entry.c:177
 msgid "Filtering content"
@@ -2087,12 +2087,12 @@ msgstr "Ungültiges Datumsformat: %s"
 
 #: list-objects-filter-options.c:30
 msgid "multiple object filter types cannot be combined"
-msgstr ""
+msgstr "Mehrere Arten von Objekt-Filtern können nicht kombiniert werden."
 
 #: list-objects-filter-options.c:41 list-objects-filter-options.c:68
-#, fuzzy, c-format
+#, c-format
 msgid "invalid filter-spec expression '%s'"
-msgstr "Ungültige Datei: '%s'"
+msgstr "Ungültiger filter-spec Ausdruck '%s'."
 
 #: lockfile.c:151
 #, c-format
@@ -2356,9 +2356,9 @@ msgid "Adding %s"
 msgstr "Füge %s hinzu"
 
 #: merge-recursive.c:1958
-#, fuzzy, c-format
+#, c-format
 msgid "Dirty index: cannot merge (dirty: %s)"
-msgstr "Geänderter Index: kann Patches nicht anwenden (geändert: %s)"
+msgstr "Geänderter Index: kann nicht mergen (geändert: %s)"
 
 #: merge-recursive.c:1962
 msgid "Already up to date!"
@@ -3015,6 +3015,8 @@ msgid ""
 "The '%s' hook was ignored because it's not set as executable.\n"
 "You can disable this warning with `git config advice.ignoredHook false`."
 msgstr ""
+"Der '%s' Hook wurde ignoriert, weil er nicht als ausführbar markiert ist.\n"
+"Sie können diese Warnung mit `git config advice.ignoredHook false` 
deaktivieren."
 
 #: send-pack.c:141
 #, c-format
@@ -3137,14 +3139,12 @@ msgid "%s: Unable to write new index file"
 msgstr "%s: Konnte neue Index-Datei nicht schreiben"
 
 #: sequencer.c:496
-#, fuzzy
 msgid "could not resolve HEAD commit"
-msgstr "Konnte HEAD-Commit nicht auflösen\n"
+msgstr "Konnte HEAD-Commit nicht auflösen."
 
 #: sequencer.c:516
-#, fuzzy
 msgid "unable to update cache tree"
-msgstr "Konnte Cache-Verzeichnis nicht aktualisieren\n"
+msgstr "Konnte Cache-Verzeichnis nicht aktualisieren."
 
 #: sequencer.c:600
 #, c-format
@@ -3178,14 +3178,14 @@ msgstr ""
 "  git rebase --continue\n"
 
 #: sequencer.c:702
-#, fuzzy, c-format
+#, c-format
 msgid "could not parse commit %s"
-msgstr "Konnte Commit %s nicht parsen\n"
+msgstr "Konnte Commit %s nicht parsen."
 
 #: sequencer.c:707
-#, fuzzy, c-format
+#, c-format
 msgid "could not parse parent commit %s"
-msgstr "Konnte Eltern-Commit %s nicht parsen\n"
+msgstr "Konnte Eltern-Commit %s nicht parsen."
 
 #: sequencer.c:836
 #, c-format
@@ -3316,14 +3316,14 @@ msgid "git %s: failed to refresh the index"
 msgstr "git %s: Fehler beim Aktualisieren des Index"
 
 #: sequencer.c:1270
-#, fuzzy, c-format
+#, c-format
 msgid "%s does not accept arguments: '%s'"
-msgstr "%%(body) akzeptiert keine Argumente"
+msgstr "%s akzeptiert keine Argumente: '%s'"
 
 #: sequencer.c:1279
-#, fuzzy, c-format
+#, c-format
 msgid "missing arguments for %s"
-msgstr "Objekt %s fehlt für %s"
+msgstr "Fehlende Argumente für %s."
 
 #: sequencer.c:1322
 #, c-format
@@ -4965,7 +4965,7 @@ msgstr "versionierte Dateien aktualisieren"
 
 #: builtin/add.c:299
 msgid "renormalize EOL of tracked files (implies -u)"
-msgstr ""
+msgstr "erneutes Normalisieren der Zeilenenden von versionierten Dateien 
(impliziert -u)"
 
 #: builtin/add.c:300
 msgid "record only the fact that the path will be added later"
@@ -5507,36 +5507,34 @@ msgstr "git bisect--helper --next-all [--no-checkout]"
 
 #: builtin/bisect--helper.c:13
 msgid "git bisect--helper --write-terms  "
-msgstr ""
+msgstr "git bisect--helper --write-terms  "
 
 #: builtin/bisect--helper.c:14
-#, fuzzy
 msgid "git bisect--helper --bisect-clean-state"
-msgstr "git bisect--helper --next-all [--no-checkout]"
+msgstr "git bisect--helper --bisect-clean-state"
 
 #: builtin/bisect--helper.c:46
-#, fuzzy, c-format
+#, c-format
 msgid "'%s' is not a valid term"
-msgstr "'%s' ist keine gültige Referenz."
+msgstr "'%s' ist kein gültiger Begriff."
 
 #: builtin/bisect--helper.c:50
-#, fuzzy, c-format
+#, c-format
 msgid "can't use the builtin command '%s' as a term"
-msgstr "Kann eingebauten Befehl '$term' nicht als Begriff verwenden"
+msgstr "Kann den eingebauten Befehl '%s' nicht als Begriff verwenden."
 
 #: builtin/bisect--helper.c:60
-#, fuzzy, c-format
+#, c-format
 msgid "can't change the meaning of the term '%s'"
-msgstr "Kann Bedeutung von '$term' nicht ändern."
+msgstr "Kann die Bedeutung von dem Begriff '%s' nicht ändern."
 
 #: 

Hello,

[mallory genest]

--
Weekend Greetings ,



I was wondering if you got my previous Email to you regarding my 
proposal ?




best regards

[PATCH v1 1/1] convert_to_git(): safe_crlf/checksafe becomes int conv_flags

[tboegi]

From: Torsten Bögershausen 

When calling convert_to_git(), the checksafe parameter defined what
should happen if the EOL conversion (CRLF --> LF --> CRLF) does not
roundtrip cleanly. In addition, it also defined if line endings should
be renormalized (CRLF --> LF) or kept as they are.

checksafe was an safe_crlf enum with these values:
SAFE_CRLF_FALSE:   do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL:die in case of EOL roundtrip errors
SAFE_CRLF_WARN:print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF:   keep all line endings as they are

In some cases the integer value 0 was passed as checksafe parameter
instead of the correct enum value SAFE_CRLF_FALSE. That was no problem
because SAFE_CRLF_FALSE is defined as 0.

FALSE/FAIL/WARN are different from RENORMALIZE and KEEP_CRLF. Therefore,
an enum is not ideal. Let's use a integer bit pattern instead and rename
the parameter to conv_flags to make it more generically usable. This
allows us to extend the bit pattern in a subsequent commit.

Reported-By: Randall S. Becker 
Helped-By: Lars Schneider 
Signed-off-by: Torsten Bögershausen 
Signed-off-by: Lars Schneider 
---

 >I think this is being solved a bit differently with a1fbf854
 >("convert_to_git(): safe_crlf/checksafe becomes int conv_flags",
 >2018-01-06), and 0 becomes the right value to pass at this caller to
 >say "I am passing none of the flag bit".

 >I am hoping that the series that ends at f3b11d54 ("convert: add
 >support for 'checkout-encoding' attribute", 2018-01-06) will be
 >rerolled and hit 'master' early in the next cycle.

  Thanks for the report & suggested patch. After reading it, I suggest
  to break out the enum/int fix into an own "series".


apply.c|  6 +++---
 combine-diff.c |  2 +-
 config.c   |  7 +--
 convert.c  | 38 +++---
 convert.h  | 17 +++--
 diff.c |  8 
 environment.c  |  2 +-
 sha1_file.c| 12 ++--
 8 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/apply.c b/apply.c
index 321a9fa68..f8b67bfee 100644
--- a/apply.c
+++ b/apply.c
@@ -2263,8 +2263,8 @@ static void show_stats(struct apply_state *state, struct 
patch *patch)
 static int read_old_data(struct stat *st, struct patch *patch,
 const char *path, struct strbuf *buf)
 {
-   enum safe_crlf safe_crlf = patch->crlf_in_old ?
-   SAFE_CRLF_KEEP_CRLF : SAFE_CRLF_RENORMALIZE;
+   int conv_flags = patch->crlf_in_old ?
+   CONV_EOL_KEEP_CRLF : CONV_EOL_RENORMALIZE;
switch (st->st_mode & S_IFMT) {
case S_IFLNK:
if (strbuf_readlink(buf, path, st->st_size) < 0)
@@ -2281,7 +2281,7 @@ static int read_old_data(struct stat *st, struct patch 
*patch,
 * should never look at the index when explicit crlf option
 * is given.
 */
-   convert_to_git(NULL, path, buf->buf, buf->len, buf, safe_crlf);
+   convert_to_git(NULL, path, buf->buf, buf->len, buf, conv_flags);
return 0;
default:
return -1;
diff --git a/combine-diff.c b/combine-diff.c
index 2505de119..19f30c335 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1053,7 +1053,7 @@ static void show_patch_diff(struct combine_diff_path 
*elem, int num_parent,
if (is_file) {
struct strbuf buf = STRBUF_INIT;
 
-   if (convert_to_git(_index, elem->path, 
result, len, , safe_crlf)) {
+   if (convert_to_git(_index, elem->path, 
result, len, , global_conv_flags_eol)) {
free(result);
result = strbuf_detach(, );
result_size = len;
diff --git a/config.c b/config.c
index e617c2018..1f003fbb9 100644
--- a/config.c
+++ b/config.c
@@ -1149,11 +1149,14 @@ static int git_default_core_config(const char *var, 
const char *value)
}
 
if (!strcmp(var, "core.safecrlf")) {
+   int eol_rndtrp_die;
if (value && !strcasecmp(value, "warn")) {
-   safe_crlf = SAFE_CRLF_WARN;
+   global_conv_flags_eol = CONV_EOL_RNDTRP_WARN;
return 0;
}
-   safe_crlf = git_config_bool(var, value);
+   eol_rndtrp_die = git_config_bool(var, value);
+   global_conv_flags_eol = eol_rndtrp_die ?
+   CONV_EOL_RNDTRP_DIE : CONV_EOL_RNDTRP_WARN;
return 0;
}
 
diff --git a/convert.c b/convert.c
index 1a41a48e1..b976eb968 100644
--- a/convert.c
+++ b/convert.c
@@ -193,30 +193,30 @@ static enum eol output_eol(enum 

[PATCH v3 4/3] read-cache: don't try to write index if we can't write shared index

[Thomas Gummerer]

In a0a967568e ("update-index --split-index: do not split if $GIT_DIR is
read only", 2014-06-13), we tried to make sure we can still write an
index, even if the shared index can not be written.

We did so by just calling 'do_write_locked_index()' from
'write_shared_index()'.  'do_write_locked_index()' always at least
closes the tempfile nowadays, and used to close or commit the lockfile
if COMMIT_LOCK or CLOSE_LOCK were given at the time this feature was
introduced.  COMMIT_LOCK or CLOSE_LOCK is passed in by most callers of
'write_locked_index()'.

After calling 'write_shared_index()', we call 'write_split_index()',
which calls 'do_write_locked_index()' again, which then tries to use the
closed lockfile again, but in fact fails to do so as it's already
closed.

In the current version, git will in fact segfault if it can't create a
new file in $gitdir, and this feature seems to never have worked in the
first place.

Ever since introducing the split index feature, nobody has complained
about this failing, and it really just papers over repositories that
will sooner or later need fixing anyway.

Therefore just make being unable to write the split index a proper
error, and have users fix their repositories instead of trying (but
failing) to paper over the error.

Signed-off-by: Thomas Gummerer 
---
 read-cache.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index d13ce83794..a9c8facdfd 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2471,18 +2471,15 @@ static int clean_shared_index_files(const char 
*current_hex)
return 0;
 }
 
-static int write_shared_index(struct index_state *istate,
- struct lock_file *lock, unsigned flags)
+static int write_shared_index(struct index_state *istate)
 {
struct tempfile *temp;
struct split_index *si = istate->split_index;
int ret;
 
temp = mks_tempfile(git_path("sharedindex_XX"));
-   if (!temp) {
-   hashclr(si->base_sha1);
-   return do_write_locked_index(istate, lock, flags);
-   }
+   if (!temp)
+   return error("cannot create new shared index");
move_cache_to_base_index(istate);
ret = do_write_index(si->base, temp, 1);
if (ret) {
@@ -2565,7 +2562,7 @@ int write_locked_index(struct index_state *istate, struct 
lock_file *lock,
new_shared_index = istate->cache_changed & SPLIT_INDEX_ORDERED;
 
if (new_shared_index) {
-   ret = write_shared_index(istate, lock, flags);
+   ret = write_shared_index(istate);
if (ret)
goto out;
}
-- 
2.16.0.rc2.280.g09355b536d

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

[Thomas Gummerer]

On 01/08, Thomas Gummerer wrote:
> On 01/08, Duy Nguyen wrote:
> > On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer  
> > wrote:
> > > @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate, 
> > > const char *path)
> > > split_index->base = xcalloc(1, 
> > > sizeof(*split_index->base));
> > >
> > > base_sha1_hex = sha1_to_hex(split_index->base_sha1);
> > > -   base_path = git_path("sharedindex.%s", base_sha1_hex);
> > > +   base_path = xstrfmt("%s/sharedindex.%s", gitdir, base_sha1_hex);
> > 
> > Personally I prefer the repo_git_path() from v2 (sorry I was away and
> > could not comment anything).
> 
> It felt slightly nicer to me as well, but it threw up a bunch of
> questions about how worktrees will fit together with struct
> repository.  As I don't feel very strongly about this either way I
> decided to go with what Brandon suggested as an alternative, which
> allows us to defer that decision.  I'd be happy to revert this to the
> way I had it in v2, but I don't want to drag the discussion on too
> long either, as this series does fix some real regressions.
> 
> > The thing is, git_path() and friends
> > could do some path translation underneath to support multiple
> > worktrees. Think of the given path here as a "virtual path" that may
> > be translated to something else, not exactly  + "/" +
> > "sharedindex.%s". But in practice, we're not breaking the relationship
> > between $GIT_DIR/index and $GIT_DIR/sharedindex.* any time soon, doing
> > manual path transformation here is fine.
> >
> > What about the other git_path() in this file? With patch applied I still get
> > 
> > > ~/w/git/temp $ git grep git_path read-cache.c
> > read-cache.c:   shared_index_path = git_path("%s", de->d_name);
> > read-cache.c:   temp = mks_tempfile(git_path("sharedindex_XX"));
> > read-cache.c: git_path("sharedindex.%s",
> > sha1_to_hex(si->base->sha1)));
> > read-cache.c:   const char *shared_index = 
> > git_path("sharedindex.%s",
> 
> Good point, I hadn't looked at these, I only looked at the current
> test failures.  I'm going to be away for the rest of the week, but
> I'll have a look at them when I come back.
> 
> > I suppose submodule has not triggered any of these code paths yet. Not
> > sure if we should deal with them now or wait until later.

Having had a look at these now, they are all in the write_locked_index
codepath.  We should probably have something like
'repo_write_locked_index()' for this.  But that probably requires a
bit more work/discussion to see what this should look like.  I'd
rather keep this patch series focused on the current breakages, and
deal with that in a separate patch series.

While looking at this, I did find another breakage in the split index
code, which I'll send as 4/3.

> > Perhaps if we add a "struct repository *" pointer inside index_state,
> > we could retrieve back the_repository (or others) and call
> > repo_git_path() everywhere without changing index api too much. I
> > don't know. I like the  'struct repository' concept but couldn't
> > follow its development so I don't if this is what it should become.
> 
> Interesting.  I didn't follow the development of  struct repository
> too closely either, so I'm not sure.  Brandon might have more of an
> opinion on that? :)
> 
> > -- 
> > Duy

[BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

[Randall S. Becker]

On January 13, 2018 2:31 PM, I wrote:
> On January 13, 2018 1:08 PM, I wrote:
> > Here’s where things are. This is probably the best git release so far
> (ever).
> > After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new.
> > Many reduced. The test took about 24 hours to run on platform, which
> > is about 2 hours shorter than 2.13.5.
> >
> > t1308-config-set.sh (2 already discussed and expecting a fix, both
> > appear
> to
> > be issues in the test script, not code) t1404-update-ref-errors.sh #
> > 52 – reported but not discussed:
> >    not ok 52 - delete fails cleanly if packed-refs file is locked.
> >      The lock detection worked, but the test assumed the detection
> > would occur in a different spot.
> > t9001-send-email.sh (2 have existed for 2 years. 1 is new. We have not
> used
> > send-email on platform to this point).
> >    not ok 31 - reject long lines
> >      This is a new fail since 2.8.5
> >   not ok 106 - sendemail.transferencoding=7bit fails on 8bit data
> >  Still to be investigated. This may be a tooling issue on Platform.
> >   not ok 107 - --transfer-encoding overrides
> > sendemail.transferEncoding
> >  Still to be investigated. This may be a tooling issue on Platform.
> 
> I missed one:
> not ok 134 - --dump-aliases must be used alone #
> #   test_must_fail git send-email --dump-aliases
> --to=janice@example
> .com -1 refs/heads/accounting

Running the tests in debug, I found that they all (1308, 1404, 9001) use
test_must_fail, and hit similar situations:

expecting success:
test_must_fail git send-email --dump-aliases --to=jan...@example.com
-1 refs/heads/accounting
--dump-aliases incompatible with other options
test_must_fail: died by signal 34: git send-email --dump-aliases
--to=jan...@example.com -1 refs/heads/accounting
not ok 134 - --dump-aliases must be used alone
#
#   test_must_fail git send-email --dump-aliases
--to=jan...@example.com -1 refs/heads/accounting
#

It is looking like git is doing what it is supposed to be doing, but the
test scripts are not detecting failures properly. The test_must_fail routine
is interestingly used in all of the above test cases that are failing. The
actual exit_code reported by git was 162, (a.k.a. signal 34 - which is not
thrown on the platform. The max signal is 31 (SIGABEND). test_must_fail has
a weird combination of some errors pass and others don't, but I can't
correlate the intent of its use in these tests particularly with no
acceptable signals passed in. Adding a return 1 if 162 caused other tests to
fail as well, so that's not the fix.

Any clues?
Thanks,
Randall

Re: GSoC 2018 Org applications. Deadline = January 23, 2018 at 18:00 (CET)

[Christian Couder]

On Mon, Jan 8, 2018 at 12:03 AM, Christian Couder
 wrote:
> On Fri, Jan 5, 2018 at 12:18 PM, Johannes Schindelin
>  wrote:
>> On Fri, 5 Jan 2018, Matthieu Moy wrote:
>>
>>> If we go for it, we need:
>>>
>>> * Admins

>From the application site I filled in the application forms and
registered as an admin for this year and sent invites to Stefan,
Matthieu and Dscho. If one of you guys accept the invite, we will have
completed our application.

>>> * Potential mentors
>>
>> Count me in as a potential mentor.
>
> I am ok to be admin and mentor.

>>> * List of microproject and project ideas
>>>   (https://git.github.io/SoC-2017-Ideas/ and
>>>   https://git.github.io/SoC-2017-Microprojects/ are good starting
>>>   points)

I copied the above pages and the application page to new 2018 pages so we have:

https://git.github.io/SoC-2018-Ideas/
https://git.github.io/SoC-2018-Microprojects/
https://git.github.io/SoC-2018-Org-Application/

I updated a bit the above pages but there are probably more
improvements to be made. Especially I kept only the projects that both
Dscho and me accepted to mentor last year as it looks like we are the
only possible mentors this year.

>> I have spent a bit of time recently to document a couple of Git for
>> Windows-specific projects thoroughly, I could easily copy/paste them
>> there, too. (Yaaay, Markdown! Now, if only we could use it in Git's man
>> pages, too...)

Dscho, please copy paste what you have in the above pages.

Thanks,
Christian.

RE: Git 2.16.0-rc2 Test Summary on NonStop

[Randall S. Becker]

On January 13, 2018 1:08 PM, I wrote:
> Here’s where things are. This is probably the best git release so far
(ever).
> After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new.
> Many reduced. The test took about 24 hours to run on platform, which is
> about 2 hours shorter than 2.13.5.
> 
> t1308-config-set.sh (2 already discussed and expecting a fix, both appear
to
> be issues in the test script, not code) t1404-update-ref-errors.sh # 52 –
> reported but not discussed:
>    not ok 52 - delete fails cleanly if packed-refs file is locked.
>      The lock detection worked, but the test assumed the detection would
> occur in a different spot.
> t9001-send-email.sh (2 have existed for 2 years. 1 is new. We have not
used
> send-email on platform to this point).
>    not ok 31 - reject long lines
>      This is a new fail since 2.8.5
>   not ok 106 - sendemail.transferencoding=7bit fails on 8bit data
>  Still to be investigated. This may be a tooling issue on Platform.
>   not ok 107 - --transfer-encoding overrides sendemail.transferEncoding
>  Still to be investigated. This may be a tooling issue on Platform.

I missed one:
not ok 134 - --dump-aliases must be used alone
#
#   test_must_fail git send-email --dump-aliases
--to=janice@example
.com -1 refs/heads/accounting
#

This one has been around at least since 2.5.6.

Re: [PATCH] packed_ref_cache: don't use mmap() for small files

[Johannes Schindelin]

Hi,

On Sat, 13 Jan 2018, Kim Gybels wrote:

> Take a hint from commit ea68b0ce9f8ce8da3e360aed3cbd6720159ffbee and use

Maybe use

ea68b0ce9f8 (hash-object: don't use mmap() for small files,
2010-02-21)

instead of the full commit name?

> read() instead of mmap() for small packed-refs files.
> 
> This also fixes the problem[1] where xmmap() returns NULL for zero
> length[2], for which munmap() later fails.
> 
> Alternatively, we could simply check for NULL before munmap(), or
> introduce an xmunmap() that could be used together with xmmap().
> 
> [1] https://github.com/git-for-windows/git/issues/1410
> [2] Logic introduced in commit 9130ac1e1966adb9922e64f645730d0d45383495
> 
> Signed-off-by: Kim Gybels 
> ---
>  refs/packed-backend.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/refs/packed-backend.c b/refs/packed-backend.c
> index dab8a85d9a..7177e5bc2f 100644
> --- a/refs/packed-backend.c
> +++ b/refs/packed-backend.c
> @@ -455,6 +455,8 @@ static void verify_buffer_safe(struct snapshot *snapshot)
>last_line, eof - last_line);
>  }
>  
> +#define SMALL_FILE_SIZE (32*1024)
> +
>  /*
>   * Depending on `mmap_strategy`, either mmap or read the contents of
>   * the `packed-refs` file into the snapshot. Return 1 if the file
> @@ -489,21 +491,21 @@ static int load_contents(struct snapshot *snapshot)
>   die_errno("couldn't stat %s", snapshot->refs->path);
>   size = xsize_t(st.st_size);
>  
> - switch (mmap_strategy) {
> - case MMAP_NONE:
> + if (!size) {
> + snapshot->buf = NULL;
> + snapshot->eof = NULL;
> + snapshot->mmapped = 0;
> + } else if (size <= SMALL_FILE_SIZE || mmap_strategy == MMAP_NONE) {
>   snapshot->buf = xmalloc(size);
>   bytes_read = read_in_full(fd, snapshot->buf, size);
>   if (bytes_read < 0 || bytes_read != size)
>   die_errno("couldn't read %s", snapshot->refs->path);
>   snapshot->eof = snapshot->buf + size;
>   snapshot->mmapped = 0;
> - break;
> - case MMAP_TEMPORARY:
> - case MMAP_OK:
> + } else {
>   snapshot->buf = xmmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 
> 0);
>   snapshot->eof = snapshot->buf + size;
>   snapshot->mmapped = 1;
> - break;
>   }
>   close(fd);

Nicely explained, and nicely solved, for a potential extra performance
benefit ;-)

Thank you!
Dscho

Re: [PATCH/RFC] diff: add --compact-summary option to complement --stat

[Philip Oakley]

(one spelling spotted)..
From: "Nguyễn Thái Ngọc Duy" 

This is partly inspired by gerrit web interface which shows diffstat
like this, e.g. with commit 0433d533f1 (notice the "A" column on the
third line):

Documentation/merge-config.txt |  4 +
builtin/merge.c|  2 +
  A t/t5573-pull-verify-signatures.sh  | 81 ++
t/t7612-merge-verify-signatures.sh | 45 ++
  4 files changed, 132 insertions(+)

In other words, certain information currently shown with --summary is
embedded in the diffstat. This helps reading (all information of the
same file in the same line instead of two) and can reduce the number of
lines if you add/delete a lot of files.

The new option --compact-summary implements this with a tweak to support
mode change, which is shown in --summary too.

For mode changes, executable bit is denoted as "(+x)" or "(-x)" when
it's added or removed respectively. The same for when a regular file is
replaced with a symlink "(+l)" or the other way "(-l)". This also
applies to new files. New regulare files are "A", while new executable
files or symlinks are "A+x" or "A+l".

Note, there is still one piece of information missing from --summary,
the rename/copy percentage. That could probably be added later. It's not
as useful as the others anyway.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
I have had something similar for years but the data is shown after
the path name instead (it's incidentally shown in the diffstat right
below). I was going to clean it up and submit it again, but my recent
experience with Gerrit changed my mind a bit about the output.

Documentation/diff-options.txt | 11 
diff.c | 64 
+-

diff.h |  1 +
t/t4013-diff-various.sh|  5 ++
...y_--root_--stat_--compact-summary_initial (new) | 12 
...R_--root_--stat_--compact-summary_initial (new) | 12 
...ree_--stat_--compact-summary_initial_mode (new) |  4 ++
..._-R_--stat_--compact-summary_initial_mode (new) |  4 ++
8 files changed, 110 insertions(+), 3 deletions(-)
create mode 100644 
t/t4013/diff.diff-tree_--pretty_--root_--stat_--compact-summary_initial
create mode 100644 
t/t4013/diff.diff-tree_--pretty_-R_--root_--stat_--compact-summary_initial
create mode 100644 
t/t4013/diff.diff-tree_--stat_--compact-summary_initial_mode
create mode 100644 
t/t4013/diff.diff-tree_-R_--stat_--compact-summary_initial_mode


diff --git a/Documentation/diff-options.txt 
b/Documentation/diff-options.txt

index 9d1586b956..ff93ff74d0 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -188,6 +188,17 @@ and accumulating child directory counts in the parent 
directories:

 Output a condensed summary of extended header information
 such as creations, renames and mode changes.

+--compact-summary::
+ Output a condensed summary of extended header information in
+ front of the file name part of diffstat. This option is
+ ignored if --stat is not specified.
++
+Fle creations or deletions are denoted with "A" or "D" respectively,


s/Fle/File/ ?


+optionally "+l" if it's a symlink, or "+x" if it's executable.
+Mode changes are put in brackets, e.g. "+x" or "-x" for adding or
+removing executable bit respectively, "+l" or "-l" for becoming a
+symlink or a regular file.
+
ifndef::git-format-patch[]
--patch-with-stat::
 Synonym for `-p --stat`.
diff --git a/diff.c b/diff.c
index fb22b19f09..3f676d 100644
--- a/diff.c
+++ b/diff.c
@@ -2131,6 +2131,7 @@ struct diffstat_t {
 char *from_name;
 char *name;
 char *print_name;
+ const char *status_code;
 unsigned is_unmerged:1;
 unsigned is_binary:1;
 unsigned is_renamed:1;
@@ -2271,6 +2272,7 @@ static void show_stats(struct diffstat_t *data, 
struct diff_options *options)

{
 int i, len, add, del, adds = 0, dels = 0;
 uintmax_t max_change = 0, max_len = 0;
+ int max_status_len = 0;
 int total_files = data->nr, count;
 int width, name_width, graph_width, number_width = 0, bin_width = 0;
 const char *reset, *add_c, *del_c;
@@ -2287,6 +2289,18 @@ static void show_stats(struct diffstat_t *data, 
struct diff_options *options)

 add_c = diff_get_color_opt(options, DIFF_FILE_NEW);
 del_c = diff_get_color_opt(options, DIFF_FILE_OLD);

+ for (i = 0; (i < count) && (i < data->nr); i++) {
+ const struct diffstat_file *file = data->files[i];
+ int len;
+
+ if (!file->status_code)
+ continue;
+ len = strlen(file->status_code) + 1;
+
+ if (len > max_status_len)
+ max_status_len = len;
+ }
+
 /*
 * Find the longest filename and max number of changes
 */
@@ -2383,6 +2397,8 @@ static void show_stats(struct diffstat_t *data, 
struct diff_options *options)

   options->stat_name_width < max_len) ?
 options->stat_name_width : max_len;

+ name_width += max_status_len;
+
 /*
 * Adjust adjustable widths not to exceed maximum width
 */
@@ -2402,6 +2418,8 

Git for Windows v2.16.0-rc2, was Re: [ANNOUNCE] Git v2.16.0-rc2

[Johannes Schindelin]

Hi team,

On Thu, 11 Jan 2018, Junio C Hamano wrote:

> A release candidate Git v2.16.0-rc2 is now available for testing
> at the usual places.  It is comprised of 483 non-merge commits
> since v2.15.0, contributed by 80 people, 23 of which are new faces.
> 
> The tarballs are found at:
> 
> https://www.kernel.org/pub/software/scm/git/testing/

And the corresponding Git for Windows files can be found here:

https://github.com/git-for-windows/git/releases/tag/v2.16.0-rc2.windows.1

Please test! (Probably the best way is to install the portable Git
side-by-side with your actual Git for Windows installation, start Git Bash
or Git CMD via the git-bash.exe or git-cmd.exe in the top-level
directory.)

Thank you,
Johannes

Git 2.16.0-rc2 Test Summary on NonStop

[Randall S. Becker]

Here’s where things are. This is probably the best git release so far
(ever). After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new.
Many reduced. The test took about 24 hours to run on platform, which is
about 2 hours shorter than 2.13.5.

t1308-config-set.sh (2 already discussed and expecting a fix, both appear to
be issues in the test script, not code)
t1404-update-ref-errors.sh # 52 – reported but not discussed:
   not ok 52 - delete fails cleanly if packed-refs file is locked.
     The lock detection worked, but the test assumed the detection would
occur in a different spot.
t9001-send-email.sh (2 have existed for 2 years. 1 is new. We have not used
send-email on platform to this point).
   not ok 31 - reject long lines
     This is a new fail since 2.8.5
  not ok 106 - sendemail.transferencoding=7bit fails on 8bit data
 Still to be investigated. This may be a tooling issue on Platform.
  not ok 107 - --transfer-encoding overrides sendemail.transferEncoding
 Still to be investigated. This may be a tooling issue on Platform.

Otherwise, this release looks really clean. I would appreciate any help
resolving the remaining items.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: unused variable in hashmap.h [was: Re: [PATCH] Fixed pervasive enumeration warning in convert.h.]

[Randall S. Becker]

> Sent: On January 13, 2018 12:13 PM, René Scharfe wrote:
> Am 12.01.2018 um 20:52 schrieb Randall S. Becker:
> > On a related too many warnings subject, hashmap.h has a variable
> > unused (void *item). Is that addressed soon? If not, I can deal with
> > it.
> Here are the code lines containing the variable in question:
> 
> void *item;
> while ((item = hashmap_iter_next()))
> 
> Intriguing.  The variable "item" is set, but can be removed without effect.
> GCC 7.2 and Clang 5 don't warn about that.
> 
> The code was introduced by 8b604d1951 (hashmap: add API to disable item
> counting when threaded) and there is no patch in pu that touches it again,

I was thinking about just changing it to the following and submitting the 
trivial patch:

 while (hashmap_iter_next())

Avoids the frame allocation of void *item so should make it minimally faster 
when compiled without optimization. 

Cheers,
Randall

Re: Git uses wrong subkey for signing commits with GPG key

[Todd Zullinger]

Andrzej Ośmiałowski wrote:
> On Sat, Jan 13, 2018 at 1:22 AM, Todd Zullinger  wrote:
>> I could be wrong, but I think you need to append '!' to
>> KEYID to force gpg to use that specific signing subkey.
[...]
> thanks for reply. You just solved my issue. I will prepare a PR to the
> docs to add relevant information.

Glad it helped.  The git-tag documentation points to
git-config and the user.signingKey variable in the
CONFIGURATION section.  The git-config documentation for
that variable currently says:

If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
key you want it to automatically when creating a signed tag or
commit, you can override the default selection with this variable.
This option is passed unchanged to gpg's --local-user parameter,
so you may specify a key using any method that gpg supports.

Whether that can be improved without being too verbose (or
duplicating too much of the gpg documentation), I don't
know.

Maybe it could point to the gpg documentation, though that
can be in gpg(1), gpg1(1), or gpg2(1), depending on how
their system installs gpg.

The online link covering the many formats that gpg accepts
for the --local-user (-u) option is:

https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html

-- 
Todd
~~
It is impossible to enjoy idling thoroughly unless one has plenty of
work to do.
-- Jerome K. Jerome

unused variable in hashmap.h [was: Re: [PATCH] Fixed pervasive enumeration warning in convert.h.]

[René Scharfe]

Am 12.01.2018 um 20:52 schrieb Randall S. Becker:
> On a related too many warnings subject, hashmap.h has a variable
> unused (void *item). Is that addressed soon? If not, I can deal with
> it.
Here are the code lines containing the variable in question:

void *item;
while ((item = hashmap_iter_next()))

Intriguing.  The variable "item" is set, but can be removed without
effect.  GCC 7.2 and Clang 5 don't warn about that.

The code was introduced by 8b604d1951 (hashmap: add API to disable item
counting when threaded) and there is no patch in pu that touches it
again, yet.

René

Re

[Alex]

--
Hello,

I have a project i want to bring to you.. please respond for details

Alex

[PATCH] packed_ref_cache: don't use mmap() for small files

[Kim Gybels]

Take a hint from commit ea68b0ce9f8ce8da3e360aed3cbd6720159ffbee and use
read() instead of mmap() for small packed-refs files.

This also fixes the problem[1] where xmmap() returns NULL for zero
length[2], for which munmap() later fails.

Alternatively, we could simply check for NULL before munmap(), or
introduce an xmunmap() that could be used together with xmmap().

[1] https://github.com/git-for-windows/git/issues/1410
[2] Logic introduced in commit 9130ac1e1966adb9922e64f645730d0d45383495

Signed-off-by: Kim Gybels 
---
 refs/packed-backend.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index dab8a85d9a..7177e5bc2f 100644
--- a/refs/packed-backend.c
+++ b/refs/packed-backend.c
@@ -455,6 +455,8 @@ static void verify_buffer_safe(struct snapshot *snapshot)
 last_line, eof - last_line);
 }
 
+#define SMALL_FILE_SIZE (32*1024)
+
 /*
  * Depending on `mmap_strategy`, either mmap or read the contents of
  * the `packed-refs` file into the snapshot. Return 1 if the file
@@ -489,21 +491,21 @@ static int load_contents(struct snapshot *snapshot)
die_errno("couldn't stat %s", snapshot->refs->path);
size = xsize_t(st.st_size);
 
-   switch (mmap_strategy) {
-   case MMAP_NONE:
+   if (!size) {
+   snapshot->buf = NULL;
+   snapshot->eof = NULL;
+   snapshot->mmapped = 0;
+   } else if (size <= SMALL_FILE_SIZE || mmap_strategy == MMAP_NONE) {
snapshot->buf = xmalloc(size);
bytes_read = read_in_full(fd, snapshot->buf, size);
if (bytes_read < 0 || bytes_read != size)
die_errno("couldn't read %s", snapshot->refs->path);
snapshot->eof = snapshot->buf + size;
snapshot->mmapped = 0;
-   break;
-   case MMAP_TEMPORARY:
-   case MMAP_OK:
+   } else {
snapshot->buf = xmmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 
0);
snapshot->eof = snapshot->buf + size;
snapshot->mmapped = 1;
-   break;
}
close(fd);
 
-- 
2.15.1.windows.2

RE

[Mr Sheng Li Hung]

I am Mr.Sheng Li Hung, from china I got your information while search for
a reliable person, I have a very profitable business proposition for you
and i can assure you that you will not regret been part of this mutual
beneficial transaction after completion. Kindly get back to me for more
details on this email id: shengl...@hotmail.com

Thanks
Mr Sheng Li Hung

[PATCH/RFC] diff: add --compact-summary option to complement --stat

[Nguyễn Thái Ngọc Duy]

This is partly inspired by gerrit web interface which shows diffstat
like this, e.g. with commit 0433d533f1 (notice the "A" column on the
third line):

 Documentation/merge-config.txt |  4 +
 builtin/merge.c|  2 +
   A t/t5573-pull-verify-signatures.sh  | 81 ++
 t/t7612-merge-verify-signatures.sh | 45 ++
   4 files changed, 132 insertions(+)

In other words, certain information currently shown with --summary is
embedded in the diffstat. This helps reading (all information of the
same file in the same line instead of two) and can reduce the number of
lines if you add/delete a lot of files.

The new option --compact-summary implements this with a tweak to support
mode change, which is shown in --summary too.

For mode changes, executable bit is denoted as "(+x)" or "(-x)" when
it's added or removed respectively. The same for when a regular file is
replaced with a symlink "(+l)" or the other way "(-l)". This also
applies to new files. New regulare files are "A", while new executable
files or symlinks are "A+x" or "A+l".

Note, there is still one piece of information missing from --summary,
the rename/copy percentage. That could probably be added later. It's not
as useful as the others anyway.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 I have had something similar for years but the data is shown after
 the path name instead (it's incidentally shown in the diffstat right
 below). I was going to clean it up and submit it again, but my recent
 experience with Gerrit changed my mind a bit about the output.

 Documentation/diff-options.txt | 11 
 diff.c | 64 +-
 diff.h |  1 +
 t/t4013-diff-various.sh|  5 ++
 ...y_--root_--stat_--compact-summary_initial (new) | 12 
 ...R_--root_--stat_--compact-summary_initial (new) | 12 
 ...ree_--stat_--compact-summary_initial_mode (new) |  4 ++
 ..._-R_--stat_--compact-summary_initial_mode (new) |  4 ++
 8 files changed, 110 insertions(+), 3 deletions(-)
 create mode 100644 
t/t4013/diff.diff-tree_--pretty_--root_--stat_--compact-summary_initial
 create mode 100644 
t/t4013/diff.diff-tree_--pretty_-R_--root_--stat_--compact-summary_initial
 create mode 100644 t/t4013/diff.diff-tree_--stat_--compact-summary_initial_mode
 create mode 100644 
t/t4013/diff.diff-tree_-R_--stat_--compact-summary_initial_mode

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9d1586b956..ff93ff74d0 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -188,6 +188,17 @@ and accumulating child directory counts in the parent 
directories:
Output a condensed summary of extended header information
such as creations, renames and mode changes.
 
+--compact-summary::
+   Output a condensed summary of extended header information in
+   front of the file name part of diffstat. This option is
+   ignored if --stat is not specified.
++
+Fle creations or deletions are denoted with "A" or "D" respectively,
+optionally "+l" if it's a symlink, or "+x" if it's executable.
+Mode changes are put in brackets, e.g. "+x" or "-x" for adding or
+removing executable bit respectively, "+l" or "-l" for becoming a
+symlink or a regular file.
+
 ifndef::git-format-patch[]
 --patch-with-stat::
Synonym for `-p --stat`.
diff --git a/diff.c b/diff.c
index fb22b19f09..3f676d 100644
--- a/diff.c
+++ b/diff.c
@@ -2131,6 +2131,7 @@ struct diffstat_t {
char *from_name;
char *name;
char *print_name;
+   const char *status_code;
unsigned is_unmerged:1;
unsigned is_binary:1;
unsigned is_renamed:1;
@@ -2271,6 +2272,7 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
 {
int i, len, add, del, adds = 0, dels = 0;
uintmax_t max_change = 0, max_len = 0;
+   int max_status_len = 0;
int total_files = data->nr, count;
int width, name_width, graph_width, number_width = 0, bin_width = 0;
const char *reset, *add_c, *del_c;
@@ -2287,6 +2289,18 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
add_c = diff_get_color_opt(options, DIFF_FILE_NEW);
del_c = diff_get_color_opt(options, DIFF_FILE_OLD);
 
+   for (i = 0; (i < count) && (i < data->nr); i++) {
+   const struct diffstat_file *file = data->files[i];
+   int len;
+
+   if (!file->status_code)
+   continue;
+   len = strlen(file->status_code) + 1;
+
+   if (len > max_status_len)
+   max_status_len = len;
+   }
+
/*
 * Find the longest filename and max number of changes
 */
@@ -2383,6 +2397,8 @@ static 

Re: Git uses wrong subkey for signing commits with GPG key

[Andrzej Ośmiałowski]

Hi Todd,

On Sat, Jan 13, 2018 at 1:22 AM, Todd Zullinger  wrote:
> Hi Andrzej,
>
> Andrzej Ośmiałowski wrote:
>> I have an issue with git and signing commits with GPG subkey.
>>
>> My setup:
>> - master key used for certification only
>> - subkey for my main workstation
>> - subkey for my mobile workstation (a notebook).
>>
>> Both subkeys are used for signing only.
>>
>> I've configured git to use my specific subkey however it does not
>> work: git config --global user.signingkey = KEYID. Every commit is
>> being signed using the newest subkey. I've verified the same behavior
>> on three systems (although with the same setup). I've tried to use
>> --gpg-sign=KEYID flag, but it does not work either.
>
> I could be wrong, but I think you need to append '!' to
> KEYID to force gpg to use that specific signing subkey.
>
> --
> Todd
> ~~
> A vacuum is a hell of a lot better than some of the stuff that nature
> replaces it with.
> -- Tennessee Williams
>

thanks for reply. You just solved my issue. I will prepare a PR to the
docs to add relevant information.

[PATCH v2] add--interactive: ignore submodule changes except HEAD

[Nguyễn Thái Ngọc Duy]

For 'add -i' and 'add -p', the only action we can take on a dirty
submodule entry is update the index with a new value from its HEAD. The
content changes inside (from its own index, untracked files...) do not
matter, at least until 'git add -i' learns about launching a new
interactive add session inside a submodule.

Ignore all other submodules changes except HEAD. This reduces the number
of entries the user has to check through in 'git add -i', and the number
of 'no' they have to answer to 'git add -p' when dirty submodules are
present.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 v2 now has some tests. The commit message is rephrased a bit.

 git-add--interactive.perl  |  2 +-
 t/t3701-add-interactive.sh | 48 ++
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 28b325d754..964c3a7542 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -262,7 +262,7 @@ sub list_modified {
}
}
 
-   for (run_cmd_pipe(qw(git diff-files --numstat --summary --raw --), 
@ARGV)) {
+   for (run_cmd_pipe(qw(git diff-files --ignore-submodules=dirty --numstat 
--summary --raw --), @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+)  ([-\d]+)(.*)/) {
$file = unquote_path($file);
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index a49c12c79b..058698df6a 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -493,4 +493,52 @@ test_expect_success 'add -p works even with 
color.ui=always' '
test_cmp expect actual
 '
 
+test_expect_success 'setup different kinds of dirty submodules' '
+   test_create_repo for-submodules &&
+   (
+   cd for-submodules &&
+   test_commit initial &&
+   test_create_repo dirty-head &&
+   (
+   cd dirty-head &&
+   test_commit initial
+   ) &&
+   cp -R dirty-head dirty-otherwise &&
+   cp -R dirty-head dirty-both-ways &&
+   git add dirty-head &&
+   git add dirty-otherwise dirty-both-ways &&
+   git commit -m initial &&
+
+   cd dirty-head &&
+   test_commit updated &&
+   cd ../dirty-both-ways &&
+   test_commit updated &&
+   echo dirty >>initial &&
+   : >untracked &&
+   cd ../dirty-otherwise &&
+   echo dirty >>initial &&
+   : >untracked
+   ) &&
+   git -C for-submodules diff-files --name-only >actual &&
+   cat >expected <<-\EOF &&
+   dirty-both-ways
+   dirty-head
+   dirty-otherwise
+   EOF
+   test_cmp expected actual &&
+   git -C for-submodules diff-files --name-only --ignore-submodules=dirty 
>actual &&
+   cat >expected <<-\EOF &&
+   dirty-both-ways
+   dirty-head
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'status ignores dirty submodules (except HEAD)' '
+   git -C for-submodules add -i output &&
+   grep dirty-head output &&
+   grep dirty-both-ways output &&
+   ! grep dirty-otherwise output
+'
+
 test_done
-- 
2.15.1.600.g899a5f85c6

Re: [PATCH] travis-ci: build Git during the 'script' phase

[Jeff King]

On Sat, Jan 13, 2018 at 05:32:56AM -0500, Jeff King wrote:

> According to:
> 
>   https://blog.travis-ci.com/2013-05-22-improving-build-visibility-log-folds
> 
> they auto-fold individual commands _except_ the ones in the script
> section. Is there a way to manually mark folds in the output?
> 
> Hmph. I could not find an answer from travis, but googling seems to turn
> up that something like this would work:
> [...]
> I've queued a CI job to see if this actually works. :)

Indeed it does work:

  https://travis-ci.org/peff/git/jobs/328418291

The rest of the crufty output looks like "set -x" stuff. It might be
worth being less aggressive there.

I think there's also a similar feature to include timings for each fold,
which might be worth pursuing.

-Peff

Re: [PATCH] travis-ci: build Git during the 'script' phase

[Jeff King]

On Fri, Jan 12, 2018 at 02:32:54PM +0100, SZEDER Gábor wrote:

> That's the just beginning of a looong list of executed test scripts in
> seemingly pseudo-random order.  IMHO that's very rarely the interesting
> part; I, for one, am only interested in that list in exceptional cases,
> e.g. while tweaking the build dependencies or the 'prove --state=...'
> options.

Aren't folds supposed to do this? I.e., record all the output but only
show it to the user if the command exited non-zero.

According to:

  https://blog.travis-ci.com/2013-05-22-improving-build-visibility-log-folds

they auto-fold individual commands _except_ the ones in the script
section. Is there a way to manually mark folds in the output?

Hmph. I could not find an answer from travis, but googling seems to turn
up that something like this would work:

diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
index 07f27c7270..8c830aa3c0 100755
--- a/ci/lib-travisci.sh
+++ b/ci/lib-travisci.sh
@@ -77,6 +77,23 @@ check_unignored_build_artifacts ()
}
 }
 
+fold () {
+   printf 'travis_fold:start:%s\r' "$1"
+}
+
+unfold () {
+   printf 'travis_fold:end:%s\r' "$1"
+}
+
+fold_cmd () {
+   local name=$1; shift
+   fold "$name"
+   "$@"
+   local ret=$?
+   unfold "$name"
+   return $ret
+}
+
 # Set 'exit on error' for all CI scripts to let the caller know that
 # something went wrong.
 # Set tracing executed commands, primarily setting environment variables
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index d3a094603f..12b2590230 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -7,8 +7,8 @@
 
 ln -s $HOME/travis-cache/.prove t/.prove
 
-make --jobs=2
-make --quiet test
+fold_cmd compile make --jobs=2
+fold_cmd test make --quiet test
 
 check_unignored_build_artifacts
 

I've queued a CI job to see if this actually works. :)

-Peff

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

[Jeff King]

On Fri, Jan 12, 2018 at 09:23:05PM +0700, Duy Nguyen wrote:

> > > Why can't we generate a new cruft-pack on every gc run that
> > > detects too many unreachable objects? That would not be as
> > > efficient as a single cruft-pack but it should be way more
> > > efficient than the individual objects, no?
> > > 
> > > Plus, chances are that the existing cruft-packs are purged with
> > > the next gc run anyways.
> > 
> > Interesting idea. Here are some thoughts in random order.
> > 
> > That loses some delta opportunities between the cruft packs, but
> > that's certainly no worse than the all-loose storage we have today.
> 
> Does it also affect deltas when we copy some objects to the new
> repacked pack (e.g. some objects in the cruft pack getting referenced
> again)? I remember we do reuse deltas sometimes but not in very
> detail. I guess we probably won't suffer any suboptimal deltas ...

We always reuse deltas that are coming from one pack into another pack,
unless the base isn't present in the new pack. So we'd retain existing
deltas. What you'd miss out on is just two versions of a file in two
separate cruft packs could not be delta'd together.

> > One nice aspect is that it means cruft objects don't incur any I/O
> > cost during a repack.
> 
> But cruft packs do incur object lookup cost since we still go through
> all packs linearly. The multi-pack index being discussed recently
> would help. But even without that, packs are sorted by mtime and old
> cruft packs won't affect as much I guess, as long as there aren't a
> zillion cruft packs around. Then even prepare_packed_git() is hit.

The cruft packs should behave pretty well with the mru list. We'd never
as for an object in such a pack during normal operations, so they'd end
up at the end of the list (the big exception is abbreviation, which has
to look in every single pack).

I'm not sure how many cruft packs you'd end up with in practice. If it's
one per auto-gc, then probably you're only generating one every few
days, and cleaning up old ones as you go.

I do still kind of favor having a single cruft pack, though, just
because it makes it simpler to reason about these sorts of things (but
then you need to mark individual object timestamps).

> > I'm not sure how the pruning process would work, especially with
> > respect to objects reachable from other unreachable-but-recent
> > objects. Right now the repack-and-delete procedure is done by
> > git-repack, and is basically:
> > 
> >   1. Get a list of all of the current packs.
> > 
> >   2. Ask pack-objects to pack everything into a new pack. Normally this
> >  is reachable objects, but we also include recent objects and
> >  objects reachable from recent objects. And of course with "-k" all
> >  objects are kept.
> > 
> >   3. Delete everything in the list from (1), under the assumption that
> >  anything worth keeping was repacked in step (2), and anything else
> >  is OK to drop.
> > 
> > So if there are regular packs and cruft packs, we'd have to know in
> > step 3 which are which. We'd delete the regular ones, whose objects
> > have all been migrated to the new pack (either a "real" one or a
> > cruft one), but keep the crufty ones whose timestamps are still
> > fresh.
> > 
> > That's a small change, and works except for one thing: the reachable
> > from recent objects. You can't just delete a whole cruft pack. Some
> > of its objects may be reachable from objects in other cruft packs
> > that we're keeping. In other words, you have cruft packs where you
> > want to keep half of the objects they contain. How do you do that?
> 
> Do we have to? Those reachable from recent objects must have ended up
> in the new pack created at step 2, correct? Which means we can safely
> remove the whole pack.

No, I think just I wrote (2) poorly. We repack the reachable objects,
but the recent ones (and things reachable only from them) are not
actually packed, but turned loose.

And of course in a cruft-packed world they'd end up in a cruft pack.

> Those reachable from other cruft packs. I'm not sure if it's different
> from when these objects are loose. If a loose object A depends on B,
> but B is much older than A, then B may get pruned anyway while A stays
> (does not sound right if A gets reused).

Hopefully not, after d3038d22f9 (prune: keep objects reachable from
recent objects, 2014-10-15). :)

-Peff