Re: requesting permission to use some Git for Windows code

[Brandon Casey]

Hi Philippe,

Please feel free to use my portions of the mentioned works under the GPLv3.

-Brandon

On Tue, Jul 25, 2017 at 6:53 AM, Johannes Schindelin
 wrote:
> Hi Philippe,
>
> I am not quite certain whether I have replied to this earlier or not.
> Under the assumption that I did not, I'll send this mail; Cc:ed to the
> mailing lists as discussed privately.
>
> On Fri, 23 Jun 2017, Philippe Joyez wrote:
>
>> This message is to request the permission to use code chunks from Git
>> for Windows in GNU TeXmacs , to which I contribute.
>> The main developer of TeXmacs is Joris van der Hoeven (in cc).
>>
>> Context:
>>
>> Just like Git, TeXmacs originated on *nix platforms and was subsequently
>> ported to windows using MinGW. Naturally, some issues we have in that
>> port are the very same Git for Windows has faced.
>>
>> One specific problem you have solved and that TeXmacs still hasn't, is
>> dealing with unicode filenames. By taking relevant pieces of code in Git
>> for windows, I could easily come up with a patch that enables TeXmacs to
>> handle unicode filenames in windows.
>>
>> Now, the problem is that Git code is GPL V2, while TeXmacs is GPL V3:
>> Incorporating my patch in TeXmacs' trunk would be a violation of GPL
>> V2... /unless/ we are granted the permission to do so by the authors of
>> the code. This is precisely the reason for this message.
>
> It is great that you can make use of the code!
>
> As to the licensing problem, I agree it is a hassle. The biggest obstacle
> is that you have to have the consent of all the authors.
>
> You hereby have mine.
>
>> The chunks of code we would like to reuse are from these Git for Windows
>> files:
>> git-compat-util.h
>
> This file is quite large, maybe you can cut down on the authors to contact
> by restricting the `git annotate`/`git log`/`git shortlog` calls to
> specific parts, using the `-L ,` option?
>
>> ctype.c
>
> $ git shortlog -nse ctype.c
>  5  Junio C Hamano 
>  4  René Scharfe 
>  2  Nguyễn Thái Ngọc Duy 
>  1  Ben Walton 
>  1  Brandon Casey 
>  1  Gary V. Vaughan 
>  1  Linus Torvalds 
>  1  Namhyung Kim 
>
> I *think* Ben Walton's change (189c860c9ec (kwset: use unsigned char to
> store values with high-bit set, 2015-03-02)) is not copyright-able, as it
> only changes the type from signed to unsigned. But I am not a lawyer ;-)
>
> Likewise, Namhyung Kim's change (1a191a22959 (ctype.c only wants
> git-compat-util.h, 2012-02-10)) only changes which header is included.
> That seems to be a too-obvious/too-trivial change to me.
>
> Also, it looks as if removing a comma as was done in 4b05548fc05 (enums:
> omit trailing comma for portability, 2010-05-14) by Gary V. Vaughan would
> not merit any copyright.
>
> If in doubt, you could simply take the version of ctype.c with those
> changes reverted as basis of your work.
>
> You still have to get the consent of Junio, René, Duy, Brandon and Linus
> to relicense the file's contents.
>
>> compat ¬
>>mingw.c
>
> I count 35 authors other than myself for that file... Maybe you can narrow
> down what you need?
>
>>mingw.h
>
> Still 29 authors other than me...
>
>>win32.h
>
> This is more manageable, as it only saw three authors. But then, you could
> simply reimplement the functionality, it's just two functions, and I do
> not think that get_file_attr() is implemented in the best way: we have a
> function called err_win_to_posix() in compat/mingw.c which is much more
> complete.
>
> Having said that, err_win_to_posix() is still not implemented in the best
> way. The best way is to abuse Windows' own (undocumented) _doserrmap()
> function along with the information in the header files winerror.h and
> errno.h to generate the mapping. Those two files, as per mingw-w64's
> headers, have the very nice preamble:
>
> /**
>  * This file has no copyright assigned and is placed in the Public 
> Domain.
>  * This file is part of the mingw-w64 runtime package.
>  * No warranty is given; refer to the file DISCLAIMER.PD within this
>  * package.
>  */
>
> Therefore, the result has no copyright assigned and is placed in the
> Public Domain and we can do the very same, too.
>
> As I wanted to have a Windows error -> errno mapping that I could
> relicense as I see fit, anyway, I took this as an excellent opportunity to
> generate exactly that.
>
> Please find the header attached. Here is how I generated that header file:
>
> -- snip --
> cat >/tmp/generrmap.c < #include 
> #include 
>
> static void map_code(unsigned long code, const char *id);
>
> int _main(int argc, char **argv)
> {
> printf("/* This file has no copyright assigned and is placed in the "
> "Public Domain. */\\n"
> 

Re: [PATCH] doc: remove unsupported parameter from patch-id

[Jeff King]

On Fri, Jul 28, 2017 at 12:46:16AM +0200, Andreas Heiduk wrote:

> The patch is read from standard input and not from a parameter.
> 
> Signed-off-by: Andreas Heiduk 
> ---
>  Documentation/git-patch-id.txt | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt
> index cf71fba1c..442caff8a 100644
> --- a/Documentation/git-patch-id.txt
> +++ b/Documentation/git-patch-id.txt
> @@ -56,9 +56,6 @@ OPTIONS
>  
>   This is the default.
>  
> -::
> - The diff to create the ID of.
> -

Heh, I think this is a leftover from 33e8fc874 (usage: do not insist
that standard input must come from a file, 2015-10-16).

Before then, the usage at the top said something like:

  git patch-id < 

and this "parameter" made sense. But after, we just talk about stdin in
the text, and mentioning "" is simply confusing.

I looked through the other documentation touched by 33e8fc874 to see if
there were other cases of this same problem, but I think this is the
only one.

-Peff

Re: [RFC PATCH 2/4] fsck: support refs pointing to lazy objects

[Jonathan Tan]

On Thu, 27 Jul 2017 11:59:47 -0700
Junio C Hamano  wrote:

> > @@ -438,6 +438,14 @@ static int fsck_handle_ref(const char *refname, const 
> > struct object_id *oid,
> >  
> > obj = parse_object(oid);
> > if (!obj) {
> > +   if (repository_format_lazy_object) {
> > +   /*
> > +* Increment default_refs anyway, because this is a
> > +* valid ref.
> > +*/
> > +   default_refs++;
> > +   return 0;
> > +   }
> > error("%s: invalid sha1 pointer %s", refname, oid_to_hex(oid));
> > errors_found |= ERROR_REACHABLE;
> 
> At this point, do we know (or can we tell) if this is a missing
> object or a file exists as a loose object but is corrupt?  If we
> could, it would be nice to do this only for the former to avoid
> sweeping a real corruption that is unrelated to the lazy fetch under
> the rug.

Before all this is run, there is a check over all loose and packed
objects and I've verified that this check reports failure in
corrupt-object situations (see test below).

It is true that parse_object() cannot report the difference, but since
fsck has already verified non-corruptness, I don't think it needs to
know the difference at this point.

> > +test_expect_success 'fsck fails on lazy object pointed to by ref' '
> > +   rm -rf repo &&
> > +   test_create_repo repo &&
> > +   test_commit -C repo 1 &&
> > +
> > +   A=$(git -C repo commit-tree -m a HEAD^{tree}) &&
> > +
> > +   # Reference $A only from ref, and delete it
> > +   git -C repo branch mybranch "$A" &&
> > +   delete_object repo "$A" &&
> > +
> > +   test_must_fail git -C repo fsck
> > +'
> 
> And a new test that uses a helper different from delete_object
> (perhaps call it corrupt_object?) can be used to make sure that we
> complain in that case here.

I agree that object corruption can cause this specific part of the
production code to falsely work. But I think that this specific part of
the code can and should rely on object corruption being checked
elsewhere. (I usually don't like to assume that other components work
and will continue to work, but in this case, I think that fsck checking
for object corruption is very foundational and should be relied upon.)

But if we think that defense "in depth" is a good idea, I have no
problem adding such tests (like the one below).

---
delete_object () {
rm $1/.git/objects/$(echo $2 | cut -c1-2)/$(echo $2 | cut -c3-40)
}

corrupt_object () {
chmod a+w $1/.git/objects/$(echo $2 | cut -c1-2)/$(echo $2 | cut 
-c3-40) &&
echo CORRUPT >$1/.git/objects/$(echo $2 | cut -c1-2)/$(echo $2 | cut 
-c3-40)
}

setup_object_in_reflog () {
rm -rf repo &&
test_create_repo repo &&
test_commit -C repo 1 &&

A=$(git -C repo commit-tree -m a HEAD^{tree}) &&
B=$(git -C repo commit-tree -m b HEAD^{tree}) &&

# Reference $A only from reflog
git -C repo branch mybranch "$A" &&
git -C repo branch -f mybranch "$B"
}

test_expect_success 'lazy object in reflog' '
setup_object_in_reflog &&
delete_object repo "$A" &&
test_must_fail git -C repo fsck &&
git -C repo config core.repositoryformatversion 1 &&
git -C repo config extensions.lazyobject "arbitrary string" &&
git -C repo fsck
'

test_expect_success 'corrupt loose object in reflog' '
setup_object_in_reflog &&
corrupt_object repo "$A" &&
test_must_fail git -C repo fsck &&
git -C repo config core.repositoryformatversion 1 &&
git -C repo config extensions.lazyobject "arbitrary string" &&
test_must_fail git -C repo fsck
'

test_expect_success 'missing packed object in reflog' '
setup_object_in_reflog &&
git -C repo repack -a &&
delete_object repo "$A" &&
chmod a+w repo/.git/objects/pack/*.pack &&
echo CORRUPT >"$(echo repo/.git/objects/pack/*.pack)" &&
test_must_fail git -C repo fsck &&
git -C repo config core.repositoryformatversion 1 &&
git -C repo config extensions.lazyobject "arbitrary string" &&
test_must_fail git -C repo fsck
'

Re: [RFC PATCH 3/4] fsck: support referenced lazy objects

[Jonathan Tan]

On Thu, 27 Jul 2017 12:17:37 -0700
Junio C Hamano  wrote:

> The same comment as 2/4 applies here.

Noted - whatever the resolution is, I'll apply it to all the patches.
> 
> > @@ -212,6 +221,8 @@ static void check_reachable_object(struct object *obj)
> >  * do a full fsck
> >  */
> > if (!(obj->flags & HAS_OBJ)) {
> > +   if (repository_format_lazy_object)
> > +   return;
> > if (has_sha1_pack(obj->oid.hash))
> > return; /* it is in pack - forget about it */
> > printf("missing %s %s\n", printable_type(obj),
> 
> Also this reminds as a related issue.  Imagine:
> 
>  - An object X was once retrieved, perhaps but not necessarily
>lazily, together with another object Y that is referred to by X
>(e.g. X is a tree, Y is a blob in the directory at path D, which
>is represented by X).
> 
>  - The same blob Y is added to the index in a different directory at
>path E.
> 
>  - The user decides to make this a slimmed-down "narrow clone" style
>repository and tells Git that path D is not interesting.  We lose
>X, but not Y because Y is still referenced from the index.
> 
>  - "git reset --hard" happens, and there no longer is any reference
>to Y.
> 
> Now, when we run fsck, should we diagnose Y as "unreachable and/or
> dangling"?

I would say yes (or whatever happens in the case where we re-fetch into
a shallow clone).

Come to think of it..."git reset --hard" always has the potential to
create unreachable objects, right (regardless of whether it's a "shallow
clone" or "narrow clone" or ordinary clone)?

[PATCH] doc: remove unsupported parameter from patch-id

[Andreas Heiduk]

The patch is read from standard input and not from a parameter.

Signed-off-by: Andreas Heiduk 
---
 Documentation/git-patch-id.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt
index cf71fba1c..442caff8a 100644
--- a/Documentation/git-patch-id.txt
+++ b/Documentation/git-patch-id.txt
@@ -56,9 +56,6 @@ OPTIONS
 
This is the default.
 
-::
-   The diff to create the ID of.
-
 GIT
 ---
 Part of the linkgit:git[1] suite
-- 
2.13.3

What's cooking in git.git (Jul 2017, #08; Thu, 27)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* ah/doc-wserrorhighlight (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at cd1bb28d95)
 + doc: add missing values "none" and "default" for diff.wsErrorHighlight

 Doc update.

 Will cook in 'next'.


* dc/fmt-merge-msg-microcleanup (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at 6df06eb788)
 + fmt-merge-msg: fix coding style

 Code cleanup.

 Will cook in 'next'.


* js/git-gui-msgfmt-on-windows (2017-07-25) 7 commits
 - Merge branch 'js/msgfmt-on-windows' of ../git-gui into 
js/git-gui-msgfmt-on-windows
 - git-gui (MinGW): make use of MSys2's msgfmt
 - Merge remote-tracking branch 'philoakley/dup-gui'
 - git gui: allow for a long recentrepo list
 - git gui: de-dup selected repo from recentrepo history
 - git gui: cope with duplicates in _get_recentrepo
 - git-gui: remove duplicate entries from .gitconfig's gui.recentrepo

 Because recent Git for Windows do come with a real msgfmt, the
 build procedure for git-gui has been updated to use it instead of a
 hand-rolled substitute.


* jt/subprocess-handshake (2017-07-26) 3 commits
 - sub-process: refactor handshake to common function
 - Documentation: migrate sub-process docs to header
 - Merge branch 'ls/filter-process-delayed' into jt/subprocess-handshake
 (this branch uses ls/filter-process-delayed.)

 Code cleanup.

 Will merge to and cook in 'next'.


* lg/merge-signoff (2017-07-25) 1 commit
 - merge: add a --signoff flag

 "git merge" learned a "--signoff" option to add the Signed-off-by:
 trailer with the committer's name.


* pb/trailers-from-command-line (2017-07-25) 4 commits
 - SQUASH???
 - interpret-trailers: add options for actions
 - trailers: introduce struct new_trailer_item
 - trailers: export action enums and corresponding lookup functions

 "git interpret-trailers" learned to take the trailer specifications
 from the command line that overrides the configured values.

 Expecting a reroll for compilation fix.


* sb/submodule-recursive-checkout-detach-head (2017-07-25) 1 commit
 - recursive submodules: detach HEAD from new state

 "git checkout --recursive" may overwrite and rewind the history of
 the branch that happens to be checked out in submodule
 repositories, which might not be desirable.  Detach the HEAD but
 still allow the recursive checkout to succeed in such a case.

 Undecided.
 This needs justification in a larger picture; it is unclear why
 this is better than rejecting recursive checkout, for example.


* ti/external-sha1dc (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at d1ce394fe2)
 + hash: allow building with the external sha1dc library

 Platforms that ship with a separate sha1 with collision detection
 library can link to it instead of using the copy we ship as part of
 our source tree.

 Will cook in 'next'.


* bw/submodule-config-cleanup (2017-07-26) 17 commits
 - submodule: remove gitmodules_config
 - unpack-trees: improve loading of .gitmodules
 - submodule-config: lazy-load a repository's .gitmodules file
 - submodule-config: move submodule-config functions to submodule-config.c
 - submodule-config: remove support for overlaying repository config
 - diff: stop allowing diff to have submodules configured in .git/config
 - submodule: remove submodule_config callback routine
 - unpack-trees: don't rely on overlayed config
 - submodule: don't rely on overlayed config when setting diffopts
 - fetch: don't overlay config with submodule-config
 - submodule--helper: don't overlay config in update-clone
 - submodule--helper: don't overlay config in remote_submodule_branch
 - add, reset: ensure submodules can be added or reset
 - submodule: don't use submodule_from_name
 - t7411: check configuration parsing errors
 - Merge branch 'bc/object-id' into bw/submodule-config-cleanup
 - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup
 (this branch uses bc/object-id, bw/grep-recurse-submodules and sb/object-id.)

 Code clean-up to avoid mixing values read from the .gitmodules file
 and values read from the .git/config file.


* jb/t8008-cleanup (2017-07-26) 1 commit
 - t8008: rely on rev-parse'd HEAD instead of sha1 value

 Code clean-up.

 Will merge to and cook in 'next'.


* rg/rerere-train-overwrite (2017-07-26) 1 commit
 - contrib/rerere-train: optionally overwrite existing resolutions

 The "rerere-train" script (in contrib/) learned the "--overwrite"
 option to allow overwriting existing recorded resolutions.

 Will merge to and cook in 'next'.


* 

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

[Junio C Hamano]

Junio C Hamano  writes:

> Jeff King  writes:
>
>> From the user's perspective, calling X "rerere" would probably be OK[1].
>> But from an implementation perspective (and to keep the existing
>> plumbing available and unchanged), it probably makes sense to call it
>> something else, and have it run both rerere and a new plumbing command
>> to do the merge-fix work (or call it nothing, and assume that users will
>> either touch the plumbing directly or will use "git merge" to trigger
>> both).
>> ...
>> I think it should be its own plumbing tool that merge calls alongside
>> rerere. ;)
>
> As long as we use the database keyed with  and take the merge
> base into account, "git am" and "git cherry-pick" would not be able
> to use the merge-fix machinery, so in that sense, calling X "rerere"
> would not be OK, but I agree with your general sentiment about the
> UI visible to the end users.

Actually, I guess "cherry-pick" could use it if we think hard and
long enough and come up with an ideal scheme to compute the index
into the merge-fix database.

Imagine this topology:

   A---o---o---...topic #1
  /
 o---o---o---...  mainline
  \
   o---B---o---C---...topic #2

where topic #1 renames 'xyzzy' to 'frotz' at commit A, and topic #2
adds a new mention of 'xyzzy' in file F at commit B and another in
file E at commit C.

In the ideal world, we would have two merge-fix database entries,
one that turns 'xyzzy' in file F to 'frotz' that is keyed by the
pair of commits , and the other that does the same in file E
that is keyed by .  When merging the topic #1 and the topic #2
together, or when merging the topic #2 to a mainline that already
has merged the topic #1, the merge-fix machinery notices that one
side has A but not B nor C, and the other side has B and C but not
A, and finds these two merge-fixes and applies on top of the textual
merge.

If we are cherry-picking C to something that already has A, then, we
should be able to notice that the history that receives the cherry-pick
has A but not C, and C, which is being picked, does not have A, and
decide that merge-fix  is relevant.

If we do this purely with commit object name, it will still not work
if we cherry-pick A to mainline and then we cherry-pick C.  The
mainline may hae change from A but does not have the exact commit A.

Which brings us back to your earlier idea to use something like
patch-id to identify these individual changes.  I am not sure how we
can structure the merge-fix database so that we can efficiently find
which "changes" are already on a branch.

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

[Junio C Hamano]

Jeff King  writes:

> On Thu, Jul 27, 2017 at 10:19:48AM -0700, Junio C Hamano wrote:
>
>> Makes sense.  Makes me wonder why we need a separate .new file
>> (instead of writing into the .lock instead), but that is a different
>> issue.
>
> It comes from 42dfa7ece (commit_packed_refs(): use a staging file
> separate from the lockfile, 2017-06-23). That commit explains that we
> want to be able to put the new contents into service before we release
> the lock. But it doesn't say why that's useful.

By being able to hold the lock on packed-refs longer, I guess
something like this becomes possible:

 * hold the lock on packed-refs
 * hold the lock on loose ref A, B, C, ...
 * update packed-refs to include the freshest values of these refs
 * start serving packed-refs without releasing the lock
 * for X in A, B, C...: delete the loose ref X and unlock X
 * unlock the packed-refs

Other people racing with the sequence to recreate a loose ref that
is even fresher than the resulting packed-refs file, while we still
hold the lock on packed-refs, is perfectly OK.

But we must make sure our packed-refs is visible to others before
starting to delete and unlock the loose refs.

Hmph, but that is not a sufficient explanation.  I am not seeing
anything bad to happen if we unlock the packed-refs before deleting
loose refs that we have locks on, so there must be something else
that needs "new packed-refs is made visible way before we unlock it".

> I recall from past discussions that this will help close some races,
> and e5cc7d7d2 (repack_without_refs(): don't lock or unlock the packed
> refs, 2017-07-01) alludes to this. I think the races in question have to
> do with holding the packed-refs lock while pruning the just-packed
> files, but I'm having trouble digging up specifics in the archive.
>
> -Peff

Re: [RFC PATCH 3/4] fsck: support referenced lazy objects

[Junio C Hamano]

Jonathan Tan  writes:

> Teach fsck to not treat missing objects indirectly pointed to by refs as
> an error when extensions.lazyobject is set.
>
> Signed-off-by: Jonathan Tan 
> ---
>  builtin/fsck.c | 11 +++
>  t/t0410-lazy-object.sh | 27 +++
>  2 files changed, 38 insertions(+)
>
> diff --git a/builtin/fsck.c b/builtin/fsck.c
> index e29ff760b..238532cc2 100644
> --- a/builtin/fsck.c
> +++ b/builtin/fsck.c
> @@ -149,6 +149,15 @@ static int mark_object(struct object *obj, int type, 
> void *data, struct fsck_opt
>   return 0;
>   obj->flags |= REACHABLE;
>   if (!(obj->flags & HAS_OBJ)) {
> + if (repository_format_lazy_object)
> + /*
> +  * Return immediately; this is not an error, and further
> +  * recursion does not need to be performed on this
> +  * object since it is missing (so it does not need to be
> +  * added to "pending").
> +  */
> + return 0;
> +

The same comment as 2/4 applies here.

> @@ -212,6 +221,8 @@ static void check_reachable_object(struct object *obj)
>* do a full fsck
>*/
>   if (!(obj->flags & HAS_OBJ)) {
> + if (repository_format_lazy_object)
> + return;
>   if (has_sha1_pack(obj->oid.hash))
>   return; /* it is in pack - forget about it */
>   printf("missing %s %s\n", printable_type(obj),

Also this reminds as a related issue.  Imagine:

 - An object X was once retrieved, perhaps but not necessarily
   lazily, together with another object Y that is referred to by X
   (e.g. X is a tree, Y is a blob in the directory at path D, which
   is represented by X).

 - The same blob Y is added to the index in a different directory at
   path E.

 - The user decides to make this a slimmed-down "narrow clone" style
   repository and tells Git that path D is not interesting.  We lose
   X, but not Y because Y is still referenced from the index.

 - "git reset --hard" happens, and there no longer is any reference
   to Y.

Now, when we run fsck, should we diagnose Y as "unreachable and/or
dangling"?

Re: [PATCH v2] l10n: de.po: various fixes in German translation

[Matthias Rüster]

Acked-by: Matthias Rüster 

Thanks!


Am 27.07.2017 um 20:23 schrieb Ralf Thielow:
> From: Hartmut Henkel 
> 
> Signed-off-by: Hartmut Henkel 
> Helped-by: Stefan Beller 
> Signed-off-by: Ralf Thielow 
> ---
>  po/de.po | 52 +---
>  1 file changed, 25 insertions(+), 27 deletions(-)
> 
> diff --git a/po/de.po b/po/de.po
> index c5b7ed501..362ebb6bb 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -1287,7 +1287,7 @@ msgid ""
>  "variable i18n.commitencoding to the encoding your project uses.\n"
>  msgstr ""
>  "Warnung: Die Commit-Beschreibung ist nicht UTF-8 konform.\n"
> -"Sie können das Nachbessern, nachdem Sie die Beschreibung korrigiert 
> haben,\n"
> +"Sie können das nachbessern, nachdem Sie die Beschreibung korrigiert 
> haben,\n"
>  "oder Sie setzen die Konfigurationsvariable i18n.commitencoding auf das "
>  "Encoding,\n"
>  "welches von ihrem Projekt verwendet wird.\n"
> @@ -1465,7 +1465,7 @@ msgstr "Konnte '%s' nicht aufheben."
>  
>  #: connect.c:50
>  msgid "The remote end hung up upon initial contact"
> -msgstr "Die Gegenseite hat sich nach dem erstmaligen Kontakt aufgehangen."
> +msgstr "Die Gegenseite hat nach dem ersten Kontakt abgebrochen."
>  
>  #: connect.c:52
>  msgid ""
> @@ -3018,7 +3018,7 @@ msgid ""
>  "after resolving the conflicts, mark the corrected paths\n"
>  "with 'git add ' or 'git rm '"
>  msgstr ""
> -"nach Auflösung der Konflikte, markieren Sie die korrigierten Pfade\n"
> +"nach Auflösung der Konflikte markieren Sie die korrigierten Pfade\n"
>  "mit 'git add ' oder 'git rm '"
>  
>  #: sequencer.c:282
> @@ -3027,8 +3027,8 @@ msgid ""
>  "with 'git add ' or 'git rm '\n"
>  "and commit the result with 'git commit'"
>  msgstr ""
> -"nach Auflösung der Konflikte, markieren Sie die korrigierten Pfade\n"
> -"mit 'git add ' oder 'git rm 'und tragen Sie das Ergebnis 
> mit\n"
> +"nach Auflösung der Konflikte markieren Sie die korrigierten Pfade\n"
> +"mit 'git add ' oder 'git rm ' und tragen Sie das Ergebnis 
> mit\n"
>  "'git commit' ein"
>  
>  #: sequencer.c:295 sequencer.c:1685
> @@ -3336,7 +3336,7 @@ msgstr "kann HEAD nicht auflösen"
>  
>  #: sequencer.c:1618 sequencer.c:1652
>  msgid "cannot abort from a branch yet to be born"
> -msgstr "kann nicht abbrechen: bin auf einem Branch, der noch geboren wird"
> +msgstr "kann nicht abbrechen: bin auf einem Branch, der noch nicht geboren 
> ist"
>  
>  #: sequencer.c:1638 builtin/grep.c:929
>  #, c-format
> @@ -3359,8 +3359,7 @@ msgstr "gespeicherte \"pre-cherry-pick\" HEAD Datei 
> '%s' ist beschädigt"
>  
>  #: sequencer.c:1658
>  msgid "You seem to have moved HEAD. Not rewinding, check your HEAD!"
> -msgstr ""
> -"Sie scheinen HEAD verschoben zu haben. Keine Zurücksetzung, prüfen Sie 
> HEAD."
> +msgstr "Sie scheinen HEAD verändert zu haben. Keine Rückspulung, prüfen Sie 
> HEAD."
>  
>  #: sequencer.c:1795 sequencer.c:2086
>  msgid "cannot read HEAD"
> @@ -3564,7 +3563,7 @@ msgstr "Kein Git-Repository (oder irgendein 
> Elternverzeichnis): %s"
>  
>  #: setup.c:812 builtin/index-pack.c:1652
>  msgid "Cannot come back to cwd"
> -msgstr "Kann nicht zurück zu Arbeitsverzeichnis wechseln"
> +msgstr "Kann nicht zurück zum Arbeitsverzeichnis wechseln"
>  
>  #: setup.c:1050
>  msgid "Unable to read current working directory"
> @@ -3938,7 +3937,7 @@ msgid ""
>  msgstr ""
>  "Ihre lokalen Änderungen in den folgenden Dateien würden durch den Merge\n"
>  "überschrieben werden:\n"
> -"%%sBitte committen oder stashen Sie Ihre Änderungen, bevor sie mergen."
> +"%%sBitte committen oder stashen Sie Ihre Änderungen, bevor Sie mergen."
>  
>  #: unpack-trees.c:112
>  #, c-format
> @@ -5412,7 +5411,7 @@ msgstr "leere SHA-1 für Grenz-Commits anzeigen 
> (Standard: aus)"
>  
>  #: builtin/blame.c:670
>  msgid "Do not treat root commits as boundaries (Default: off)"
> -msgstr "Ursprungs-Commit nicht als Grenzen behandeln (Standard: aus)"
> +msgstr "Ursprungs-Commits nicht als Grenzen behandeln (Standard: aus)"
>  
>  #: builtin/blame.c:671
>  msgid "Show work cost statistics"
> @@ -5523,7 +5522,7 @@ msgstr ""
>  #.
>  #: builtin/blame.c:795
>  msgid "4 years, 11 months ago"
> -msgstr "vor 4 Jahren, und 11 Monaten"
> +msgstr "vor 4 Jahren und 11 Monaten"
>  
>  #: builtin/blame.c:882
>  #, c-format
> @@ -6297,13 +6296,13 @@ msgid_plural ""
>  "\n"
>  msgstr[0] ""
>  "Wenn Sie diese durch einen neuen Branch behalten möchten, dann könnte 
> jetzt\n"
> -"ein guter Zeitpunkt sein dies zu tun mit:\n"
> +"ein guter Zeitpunkt sein, dies zu tun mit:\n"
>  "\n"
>  " git branch  %s\n"
>  "\n"
>  msgstr[1] ""
>  "Wenn Sie diese durch einen neuen Branch behalten möchten, dann könnte 
> jetzt\n"
> -"ein guter Zeitpunkt sein dies zu tun mit:\n"
> +"ein guter Zeitpunkt sein, dies zu tun mit:\n"
>  "\n"
>  " git branch  %s\n"
>  "\n"
> @@ -6318,7 +6317,7 @@ msgstr "Vorherige Position von HEAD war"
>  
>  #: 

Re: [RFC PATCH 2/4] fsck: support refs pointing to lazy objects

[Junio C Hamano]

Jonathan Tan  writes:

> Teach fsck to not treat refs with missing targets as an error when
> extensions.lazyobject is set.
>
> For the purposes of warning about no default refs, such refs are still
> treated as legitimate refs.
>
> Signed-off-by: Jonathan Tan 
> ---
>  builtin/fsck.c |  8 
>  t/t0410-lazy-object.sh | 20 
>  2 files changed, 28 insertions(+)
>
> diff --git a/builtin/fsck.c b/builtin/fsck.c
> index 1cfb8d98c..e29ff760b 100644
> --- a/builtin/fsck.c
> +++ b/builtin/fsck.c
> @@ -438,6 +438,14 @@ static int fsck_handle_ref(const char *refname, const 
> struct object_id *oid,
>  
>   obj = parse_object(oid);
>   if (!obj) {
> + if (repository_format_lazy_object) {
> + /*
> +  * Increment default_refs anyway, because this is a
> +  * valid ref.
> +  */
> + default_refs++;
> + return 0;
> + }
>   error("%s: invalid sha1 pointer %s", refname, oid_to_hex(oid));
>   errors_found |= ERROR_REACHABLE;

At this point, do we know (or can we tell) if this is a missing
object or a file exists as a loose object but is corrupt?  If we
could, it would be nice to do this only for the former to avoid
sweeping a real corruption that is unrelated to the lazy fetch under
the rug.

> +test_expect_success 'fsck fails on lazy object pointed to by ref' '
> + rm -rf repo &&
> + test_create_repo repo &&
> + test_commit -C repo 1 &&
> +
> + A=$(git -C repo commit-tree -m a HEAD^{tree}) &&
> +
> + # Reference $A only from ref, and delete it
> + git -C repo branch mybranch "$A" &&
> + delete_object repo "$A" &&
> +
> + test_must_fail git -C repo fsck
> +'

And a new test that uses a helper different from delete_object
(perhaps call it corrupt_object?) can be used to make sure that we
complain in that case here.

> +test_expect_success '...but succeeds if lazyobject is set' '
> + git -C repo config core.repositoryformatversion 1 &&
> + git -C repo config extensions.lazyobject "arbitrary string" &&
> + git -C repo fsck
> +'
> +
>  test_done

Re: [PATCHv2] builtin/blame: highlight interesting things

[Stefan Beller]

On Thu, Jul 27, 2017 at 11:27 AM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>> Well, we could also try a "zebra"  as in sb/diff-color-move to show blocks
>> with the same fancy border detection.
>
> Luckily, blame output has places for metainfo on each line, unlike
> diff output, so there won't be a need for painting border
> differently.

Right.

> For example, if we decide that metainfo is shown only
> for the first line for each block, then by definition, the border
> between blocks is just before a line with metainfo and nowhere else.
> So in that sense, the problem should be a lot easier to solve ;-)

Yes, also the code already provides structured blocks,
so internally it is also easier.

The question is whether we decide that showing the first line
is a good choice. We could also put it at the approximated
middle and draw lines up and down.

In an advanced world, we would not use a dumb pager, but
e.g. ncurses, such that the line displaying meta information
may come along when you scroll down a page.

Maybe the discussion here can also feed back into the
"machine readable move coloring" that Aevar seemed to be
interested in.

>
> Unluckily, a block may span several pages, so "only at the first
> line" might not be very useful.  I wonder if we can print in black
> ink on black background and let selection by mouse or in screen
> still reveal useful information?

This is what the dark color approximates, except you don't
need a mouse selection to read?

Re: [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

[Junio C Hamano]

Jonathan Tan  writes:

> Currently, Git does not support repos with very large numbers of objects
> or repos that wish to minimize manipulation of certain blobs (for
> example, because they are very large) very well, even if the user
> operates mostly on part of the repo, because Git is designed on the
> assumption that every referenced object is available somewhere in the
> repo storage.
>
> Introduce a new repository extension option "extensions.lazyobject", of
> data type string. If this is set in a repository, Git will tolerate
> objects being missing in that repository.  When Git needs those objects,
> it will invoke the command in that option.

My reading hiccupped after the first sentence, as the problem
description made it sound like this was a boolean ("are we using
lazy object feature?"), after reading "data type string".  And then
"the command in that option" made me hiccup one more time, as it did
not "click" that "in that option" was trying to say that the string
is used as the command name (or is it a whole command line?  The
leading part of the command line to which some arguments are
appended before it gets invoked as a command? or what?).

Logically, I think it is more like

 - extensions.lazyobject can be set to tell Git to consider missing
   objects in certain cases are not errors;

 - the value of extensions.lazyobject variable must be a string,
   which is used to name the command to lazily make the object
   "appear" in the repository on demand.

> Teach fsck about the new state of affairs. In this commit, teach fsck
> that missing objects referenced from the reflog are not an error case;
> in future commits, fsck will be taught about other cases.

In any case, sounds like a small and good first step.

> +
> +`lazyObject`
> +~
> +
> +When the config key `extensions.lazyObject` is set to a string, Git
> +tolerates objects being missing in the repository. This string contains
> +the command to be run whenever a missing object is needed.

This has the same issue but to a lessor degree as there is "string
contains".  What the command will do (e.g. "makes the object
magically appear in the object store" or "emits the contents of the
object to its standard output, so that Git can hash it to make it
appear in the object store"), and how it is used (e.g. "this is a
single command name and nothing else", "this is a leading part of
command line and arguments are appended at the end, before the whole
thing is passed to the shell to be executed", etc.) will need to be
clarified in the final version of the series (not necessarily at
this step---the series can elaborate in the later patches).

> diff --git a/builtin/fsck.c b/builtin/fsck.c
> index fb0947009..1cfb8d98c 100644
> --- a/builtin/fsck.c
> +++ b/builtin/fsck.c
> @@ -402,7 +402,7 @@ static void fsck_handle_reflog_oid(const char *refname, 
> struct object_id *oid,
>   xstrfmt("%s@{%"PRItime"}", refname, 
> timestamp));
>   obj->flags |= USED;
>   mark_object_reachable(obj);
> - } else {
> + } else if (!repository_format_lazy_object) {
>   error("%s: invalid reflog entry %s", refname, 
> oid_to_hex(oid));
>   errors_found |= ERROR_REACHABLE;
>   }
> diff --git a/cache.h b/cache.h
> index 6c8242340..9e6bc0a21 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -853,10 +853,12 @@ extern int grafts_replace_parents;
>  #define GIT_REPO_VERSION 0
>  #define GIT_REPO_VERSION_READ 1
>  extern int repository_format_precious_objects;
> +extern char *repository_format_lazy_object;

This is not a new problem, but I think these two should be
called repository_extension_$NAME not repository_format_$NAME.

> diff --git a/t/t0410-lazy-object.sh b/t/t0410-lazy-object.sh
> new file mode 100755
> index 0..36442531f
> --- /dev/null
> +++ b/t/t0410-lazy-object.sh
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +
> +test_description='lazy object'
> +
> +. ./test-lib.sh
> +
> +delete_object () {
> + rm $1/.git/objects/$(echo $2 | cut -c1-2)/$(echo $2 | cut -c3-40)
> +}
> +
> +test_expect_success 'fsck fails on lazy object in reflog' '
> + test_create_repo repo &&
> + test_commit -C repo 1 &&
> +
> + A=$(git -C repo commit-tree -m a HEAD^{tree}) &&
> + B=$(git -C repo commit-tree -m b HEAD^{tree}) &&
> +
> + # Reference $A only from reflog, and delete it
> + git -C repo branch mybranch "$A" &&
> + git -C repo branch -f mybranch "$B" &&
> + delete_object repo "$A" &&
> +
> + test_must_fail git -C repo fsck
> +'
> +test_expect_success '...but succeeds if lazyobject is set' '
> + git -C repo config core.repositoryformatversion 1 &&
> + git -C repo config extensions.lazyobject "arbitrary string" &&
> + git -C repo fsck
> +'
> +
> +test_done

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

[Jeff King]

On Thu, Jul 27, 2017 at 10:19:48AM -0700, Junio C Hamano wrote:

> Michael Haggerty  writes:
> 
> > Change `commit_packed_refs()` to use `get_locked_file_path()` to find
> > the path of the file that it should overwrite. Since that path was
> > properly resolved when the lockfile was created, this restores the
> > pre-42dfa7ecef behavior.
> 
> Because when we take a lock hold_lock_file() eventually calls into
> lock_file() which by default takes the lock on the target of the
> symbolic link (which is the sensible default, which is triggered in
> this codepath), so this change to use the name of that file is all
> that is needed.
> 
> Makes sense.  Makes me wonder why we need a separate .new file
> (instead of writing into the .lock instead), but that is a different
> issue.

It comes from 42dfa7ece (commit_packed_refs(): use a staging file
separate from the lockfile, 2017-06-23). That commit explains that we
want to be able to put the new contents into service before we release
the lock. But it doesn't say why that's useful.

I recall from past discussions that this will help close some races,
and e5cc7d7d2 (repack_without_refs(): don't lock or unlock the packed
refs, 2017-07-01) alludes to this. I think the races in question have to
do with holding the packed-refs lock while pruning the just-packed
files, but I'm having trouble digging up specifics in the archive.

-Peff

Re: [PATCHv2] builtin/blame: highlight interesting things

[Junio C Hamano]

Stefan Beller  writes:

> Well, we could also try a "zebra"  as in sb/diff-color-move to show blocks
> with the same fancy border detection.

Luckily, blame output has places for metainfo on each line, unlike
diff output, so there won't be a need for painting border
differently.  For example, if we decide that metainfo is shown only
for the first line for each block, then by definition, the border
between blocks is just before a line with metainfo and nowhere else.
So in that sense, the problem should be a lot easier to solve ;-)

Unluckily, a block may span several pages, so "only at the first
line" might not be very useful.  I wonder if we can print in black
ink on black background and let selection by mouse or in screen
still reveal useful information?

[PATCH v2] l10n: de.po: various fixes in German translation

[Ralf Thielow]

From: Hartmut Henkel 

Signed-off-by: Hartmut Henkel 
Helped-by: Stefan Beller 
Signed-off-by: Ralf Thielow 
---
 po/de.po | 52 +---
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/po/de.po b/po/de.po
index c5b7ed501..362ebb6bb 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1287,7 +1287,7 @@ msgid ""
 "variable i18n.commitencoding to the encoding your project uses.\n"
 msgstr ""
 "Warnung: Die Commit-Beschreibung ist nicht UTF-8 konform.\n"
-"Sie können das Nachbessern, nachdem Sie die Beschreibung korrigiert haben,\n"
+"Sie können das nachbessern, nachdem Sie die Beschreibung korrigiert haben,\n"
 "oder Sie setzen die Konfigurationsvariable i18n.commitencoding auf das "
 "Encoding,\n"
 "welches von ihrem Projekt verwendet wird.\n"
@@ -1465,7 +1465,7 @@ msgstr "Konnte '%s' nicht aufheben."
 
 #: connect.c:50
 msgid "The remote end hung up upon initial contact"
-msgstr "Die Gegenseite hat sich nach dem erstmaligen Kontakt aufgehangen."
+msgstr "Die Gegenseite hat nach dem ersten Kontakt abgebrochen."
 
 #: connect.c:52
 msgid ""
@@ -3018,7 +3018,7 @@ msgid ""
 "after resolving the conflicts, mark the corrected paths\n"
 "with 'git add ' or 'git rm '"
 msgstr ""
-"nach Auflösung der Konflikte, markieren Sie die korrigierten Pfade\n"
+"nach Auflösung der Konflikte markieren Sie die korrigierten Pfade\n"
 "mit 'git add ' oder 'git rm '"
 
 #: sequencer.c:282
@@ -3027,8 +3027,8 @@ msgid ""
 "with 'git add ' or 'git rm '\n"
 "and commit the result with 'git commit'"
 msgstr ""
-"nach Auflösung der Konflikte, markieren Sie die korrigierten Pfade\n"
-"mit 'git add ' oder 'git rm 'und tragen Sie das Ergebnis mit\n"
+"nach Auflösung der Konflikte markieren Sie die korrigierten Pfade\n"
+"mit 'git add ' oder 'git rm ' und tragen Sie das Ergebnis mit\n"
 "'git commit' ein"
 
 #: sequencer.c:295 sequencer.c:1685
@@ -3336,7 +3336,7 @@ msgstr "kann HEAD nicht auflösen"
 
 #: sequencer.c:1618 sequencer.c:1652
 msgid "cannot abort from a branch yet to be born"
-msgstr "kann nicht abbrechen: bin auf einem Branch, der noch geboren wird"
+msgstr "kann nicht abbrechen: bin auf einem Branch, der noch nicht geboren ist"
 
 #: sequencer.c:1638 builtin/grep.c:929
 #, c-format
@@ -3359,8 +3359,7 @@ msgstr "gespeicherte \"pre-cherry-pick\" HEAD Datei '%s' 
ist beschädigt"
 
 #: sequencer.c:1658
 msgid "You seem to have moved HEAD. Not rewinding, check your HEAD!"
-msgstr ""
-"Sie scheinen HEAD verschoben zu haben. Keine Zurücksetzung, prüfen Sie HEAD."
+msgstr "Sie scheinen HEAD verändert zu haben. Keine Rückspulung, prüfen Sie 
HEAD."
 
 #: sequencer.c:1795 sequencer.c:2086
 msgid "cannot read HEAD"
@@ -3564,7 +3563,7 @@ msgstr "Kein Git-Repository (oder irgendein 
Elternverzeichnis): %s"
 
 #: setup.c:812 builtin/index-pack.c:1652
 msgid "Cannot come back to cwd"
-msgstr "Kann nicht zurück zu Arbeitsverzeichnis wechseln"
+msgstr "Kann nicht zurück zum Arbeitsverzeichnis wechseln"
 
 #: setup.c:1050
 msgid "Unable to read current working directory"
@@ -3938,7 +3937,7 @@ msgid ""
 msgstr ""
 "Ihre lokalen Änderungen in den folgenden Dateien würden durch den Merge\n"
 "überschrieben werden:\n"
-"%%sBitte committen oder stashen Sie Ihre Änderungen, bevor sie mergen."
+"%%sBitte committen oder stashen Sie Ihre Änderungen, bevor Sie mergen."
 
 #: unpack-trees.c:112
 #, c-format
@@ -5412,7 +5411,7 @@ msgstr "leere SHA-1 für Grenz-Commits anzeigen (Standard: 
aus)"
 
 #: builtin/blame.c:670
 msgid "Do not treat root commits as boundaries (Default: off)"
-msgstr "Ursprungs-Commit nicht als Grenzen behandeln (Standard: aus)"
+msgstr "Ursprungs-Commits nicht als Grenzen behandeln (Standard: aus)"
 
 #: builtin/blame.c:671
 msgid "Show work cost statistics"
@@ -5523,7 +5522,7 @@ msgstr ""
 #.
 #: builtin/blame.c:795
 msgid "4 years, 11 months ago"
-msgstr "vor 4 Jahren, und 11 Monaten"
+msgstr "vor 4 Jahren und 11 Monaten"
 
 #: builtin/blame.c:882
 #, c-format
@@ -6297,13 +6296,13 @@ msgid_plural ""
 "\n"
 msgstr[0] ""
 "Wenn Sie diese durch einen neuen Branch behalten möchten, dann könnte jetzt\n"
-"ein guter Zeitpunkt sein dies zu tun mit:\n"
+"ein guter Zeitpunkt sein, dies zu tun mit:\n"
 "\n"
 " git branch  %s\n"
 "\n"
 msgstr[1] ""
 "Wenn Sie diese durch einen neuen Branch behalten möchten, dann könnte jetzt\n"
-"ein guter Zeitpunkt sein dies zu tun mit:\n"
+"ein guter Zeitpunkt sein, dies zu tun mit:\n"
 "\n"
 " git branch  %s\n"
 "\n"
@@ -6318,7 +6317,7 @@ msgstr "Vorherige Position von HEAD war"
 
 #: builtin/checkout.c:832 builtin/checkout.c:1070
 msgid "You are on a branch yet to be born"
-msgstr "Sie sind auf einem Branch, der noch geboren wird"
+msgstr "Sie sind auf einem Branch, der noch nicht geboren ist"
 
 #: builtin/checkout.c:976
 #, c-format
@@ -6975,7 +6974,7 @@ msgstr ""
 msgid "source repository is shallow, ignoring --local"
 msgstr ""
 "Quelle ist ein Repository mit unvollständiger 

Re: [PATCH] l10n: de.po: various fixes in German translation

[Ralf Thielow]

2017-07-27 20:00 GMT+02:00 Stefan Beller :
> This patch looks good to me, but some unrelated comments
> that I feel would improve the translation even more.
>
> Thanks,
> Stefan
>
>> @@ -1465,7 +1465,7 @@ msgstr "Konnte '%s' nicht aufheben."
>>
>>  #: connect.c:50
>>  msgid "The remote end hung up upon initial contact"
>> -msgstr "Die Gegenseite hat sich nach dem erstmaligen Kontakt aufgehangen."
>> +msgstr "Die Gegenseite hat nach dem erstmaligen Kontakt abgebrochen."
>
> erstmalig reads funny here. Maybe "ersten" instead?
>
>
>> @@ -3360,7 +3360,7 @@ msgstr "gespeicherte \"pre-cherry-pick\" HEAD Datei 
>> '%s' ist beschädigt"
>>  #: sequencer.c:1658
>>  msgid "You seem to have moved HEAD. Not rewinding, check your HEAD!"
>>  msgstr ""
>> -"Sie scheinen HEAD verschoben zu haben. Keine Zurücksetzung, prüfen Sie 
>> HEAD."
>> +"Sie scheinen HEAD verschoben zu haben. Keine Rückspulung, prüfen Sie HEAD."
>
> Maybe "Sie scheinen HEAD veraendert zu haben" here?
> This could also be reflected in the code and we put "changed HEAD" ,
> but in English it seems to fit "moving " HEAD.
>
>> @@ -11258,7 +11258,7 @@ msgstr "Fortschrittsanzeige anzeigen"
>>  #: builtin/pack-objects.c:2881
>>  msgid "show progress meter during object writing phase"
>>  msgstr ""
>> -"Forschrittsanzeige während der Phase des Schreibens der Objekte anzeigen"
>> +"Forschrittsanzeige während der Phase des Schreibens von Objekten anzeigen"
>
> Maybe elide "der Phase" here?

I agree with all of that.

Thanks

Re: [PATCH] l10n: de.po: various fixes in German translation

[Stefan Beller]

This patch looks good to me, but some unrelated comments
that I feel would improve the translation even more.

Thanks,
Stefan

> @@ -1465,7 +1465,7 @@ msgstr "Konnte '%s' nicht aufheben."
>
>  #: connect.c:50
>  msgid "The remote end hung up upon initial contact"
> -msgstr "Die Gegenseite hat sich nach dem erstmaligen Kontakt aufgehangen."
> +msgstr "Die Gegenseite hat nach dem erstmaligen Kontakt abgebrochen."

erstmalig reads funny here. Maybe "ersten" instead?


> @@ -3360,7 +3360,7 @@ msgstr "gespeicherte \"pre-cherry-pick\" HEAD Datei 
> '%s' ist beschädigt"
>  #: sequencer.c:1658
>  msgid "You seem to have moved HEAD. Not rewinding, check your HEAD!"
>  msgstr ""
> -"Sie scheinen HEAD verschoben zu haben. Keine Zurücksetzung, prüfen Sie 
> HEAD."
> +"Sie scheinen HEAD verschoben zu haben. Keine Rückspulung, prüfen Sie HEAD."

Maybe "Sie scheinen HEAD veraendert zu haben" here?
This could also be reflected in the code and we put "changed HEAD" ,
but in English it seems to fit "moving " HEAD.

> @@ -11258,7 +11258,7 @@ msgstr "Fortschrittsanzeige anzeigen"
>  #: builtin/pack-objects.c:2881
>  msgid "show progress meter during object writing phase"
>  msgstr ""
> -"Forschrittsanzeige während der Phase des Schreibens der Objekte anzeigen"
> +"Forschrittsanzeige während der Phase des Schreibens von Objekten anzeigen"

Maybe elide "der Phase" here?

[PATCH] l10n: de.po: various fixes in German translation

[Ralf Thielow]

From: Hartmut Henkel 

Signed-off-by: Hartmut Henkel 
Signed-off-by: Ralf Thielow 
---
 po/de.po | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/po/de.po b/po/de.po
index c5b7ed501..dc381cb2d 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1287,7 +1287,7 @@ msgid ""
 "variable i18n.commitencoding to the encoding your project uses.\n"
 msgstr ""
 "Warnung: Die Commit-Beschreibung ist nicht UTF-8 konform.\n"
-"Sie können das Nachbessern, nachdem Sie die Beschreibung korrigiert haben,\n"
+"Sie können das nachbessern, nachdem Sie die Beschreibung korrigiert haben,\n"
 "oder Sie setzen die Konfigurationsvariable i18n.commitencoding auf das "
 "Encoding,\n"
 "welches von ihrem Projekt verwendet wird.\n"
@@ -1465,7 +1465,7 @@ msgstr "Konnte '%s' nicht aufheben."
 
 #: connect.c:50
 msgid "The remote end hung up upon initial contact"
-msgstr "Die Gegenseite hat sich nach dem erstmaligen Kontakt aufgehangen."
+msgstr "Die Gegenseite hat nach dem erstmaligen Kontakt abgebrochen."
 
 #: connect.c:52
 msgid ""
@@ -3018,7 +3018,7 @@ msgid ""
 "after resolving the conflicts, mark the corrected paths\n"
 "with 'git add ' or 'git rm '"
 msgstr ""
-"nach Auflösung der Konflikte, markieren Sie die korrigierten Pfade\n"
+"nach Auflösung der Konflikte markieren Sie die korrigierten Pfade\n"
 "mit 'git add ' oder 'git rm '"
 
 #: sequencer.c:282
@@ -3027,8 +3027,8 @@ msgid ""
 "with 'git add ' or 'git rm '\n"
 "and commit the result with 'git commit'"
 msgstr ""
-"nach Auflösung der Konflikte, markieren Sie die korrigierten Pfade\n"
-"mit 'git add ' oder 'git rm 'und tragen Sie das Ergebnis mit\n"
+"nach Auflösung der Konflikte markieren Sie die korrigierten Pfade\n"
+"mit 'git add ' oder 'git rm ' und tragen Sie das Ergebnis mit\n"
 "'git commit' ein"
 
 #: sequencer.c:295 sequencer.c:1685
@@ -3336,7 +3336,7 @@ msgstr "kann HEAD nicht auflösen"
 
 #: sequencer.c:1618 sequencer.c:1652
 msgid "cannot abort from a branch yet to be born"
-msgstr "kann nicht abbrechen: bin auf einem Branch, der noch geboren wird"
+msgstr "kann nicht abbrechen: bin auf einem Branch, der noch nicht geboren ist"
 
 #: sequencer.c:1638 builtin/grep.c:929
 #, c-format
@@ -3360,7 +3360,7 @@ msgstr "gespeicherte \"pre-cherry-pick\" HEAD Datei '%s' 
ist beschädigt"
 #: sequencer.c:1658
 msgid "You seem to have moved HEAD. Not rewinding, check your HEAD!"
 msgstr ""
-"Sie scheinen HEAD verschoben zu haben. Keine Zurücksetzung, prüfen Sie HEAD."
+"Sie scheinen HEAD verschoben zu haben. Keine Rückspulung, prüfen Sie HEAD."
 
 #: sequencer.c:1795 sequencer.c:2086
 msgid "cannot read HEAD"
@@ -3564,7 +3564,7 @@ msgstr "Kein Git-Repository (oder irgendein 
Elternverzeichnis): %s"
 
 #: setup.c:812 builtin/index-pack.c:1652
 msgid "Cannot come back to cwd"
-msgstr "Kann nicht zurück zu Arbeitsverzeichnis wechseln"
+msgstr "Kann nicht zurück zum Arbeitsverzeichnis wechseln"
 
 #: setup.c:1050
 msgid "Unable to read current working directory"
@@ -3938,7 +3938,7 @@ msgid ""
 msgstr ""
 "Ihre lokalen Änderungen in den folgenden Dateien würden durch den Merge\n"
 "überschrieben werden:\n"
-"%%sBitte committen oder stashen Sie Ihre Änderungen, bevor sie mergen."
+"%%sBitte committen oder stashen Sie Ihre Änderungen, bevor Sie mergen."
 
 #: unpack-trees.c:112
 #, c-format
@@ -5412,7 +5412,7 @@ msgstr "leere SHA-1 für Grenz-Commits anzeigen (Standard: 
aus)"
 
 #: builtin/blame.c:670
 msgid "Do not treat root commits as boundaries (Default: off)"
-msgstr "Ursprungs-Commit nicht als Grenzen behandeln (Standard: aus)"
+msgstr "Ursprungs-Commits nicht als Grenzen behandeln (Standard: aus)"
 
 #: builtin/blame.c:671
 msgid "Show work cost statistics"
@@ -5523,7 +5523,7 @@ msgstr ""
 #.
 #: builtin/blame.c:795
 msgid "4 years, 11 months ago"
-msgstr "vor 4 Jahren, und 11 Monaten"
+msgstr "vor 4 Jahren und 11 Monaten"
 
 #: builtin/blame.c:882
 #, c-format
@@ -6297,13 +6297,13 @@ msgid_plural ""
 "\n"
 msgstr[0] ""
 "Wenn Sie diese durch einen neuen Branch behalten möchten, dann könnte jetzt\n"
-"ein guter Zeitpunkt sein dies zu tun mit:\n"
+"ein guter Zeitpunkt sein, dies zu tun mit:\n"
 "\n"
 " git branch  %s\n"
 "\n"
 msgstr[1] ""
 "Wenn Sie diese durch einen neuen Branch behalten möchten, dann könnte jetzt\n"
-"ein guter Zeitpunkt sein dies zu tun mit:\n"
+"ein guter Zeitpunkt sein, dies zu tun mit:\n"
 "\n"
 " git branch  %s\n"
 "\n"
@@ -6318,7 +6318,7 @@ msgstr "Vorherige Position von HEAD war"
 
 #: builtin/checkout.c:832 builtin/checkout.c:1070
 msgid "You are on a branch yet to be born"
-msgstr "Sie sind auf einem Branch, der noch geboren wird"
+msgstr "Sie sind auf einem Branch, der noch nicht geboren ist"
 
 #: builtin/checkout.c:976
 #, c-format
@@ -6975,7 +6975,7 @@ msgstr ""
 msgid "source repository is shallow, ignoring --local"
 msgstr ""
 "Quelle ist ein Repository mit unvollständiger Historie (shallow),\n"
-"--local wird ignoriert"

Re: [RFC PATCH 0/4] Some patches for fsck for missing objects

[Jonathan Tan]

On Wed, 26 Jul 2017 23:42:38 +
"brian m. carlson"  wrote:

> I looked at this and I like the direction it's going.  It's pretty
> simple and straightforward, which I also like.

Thanks.

> What I'd recommend is that instead of making lazyObject a string, we
> make it an integer representing a protocol version.  We then add a
> different config setting that is the actual program to invoke, using the
> given protocol version.  This lets us change the way we speak to the
> tool without breaking backwards compatibility, and it also allows us to
> simply check the lazyObject script for supported protocols up front.

That's possible too. As for version negotiation, I think we'll end up
using a protocol similar to the clean/smudge long-running process
protocol (as documented as gitattributes), so that does not need to be
taken care of here, but making lazyObject be the version integer is fine
too.

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

[Junio C Hamano]

Michael Haggerty  writes:

> Change `commit_packed_refs()` to use `get_locked_file_path()` to find
> the path of the file that it should overwrite. Since that path was
> properly resolved when the lockfile was created, this restores the
> pre-42dfa7ecef behavior.

Because when we take a lock hold_lock_file() eventually calls into
lock_file() which by default takes the lock on the target of the
symbolic link (which is the sensible default, which is triggered in
this codepath), so this change to use the name of that file is all
that is needed.

Makes sense.  Makes me wonder why we need a separate .new file
(instead of writing into the .lock instead), but that is a different
issue.

Thanks.  I'll do the SYMLINKS thing while queuing.

> diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
> index 2bb4b25ed9..0d8a03e2a9 100755
> --- a/t/t3210-pack-refs.sh
> +++ b/t/t3210-pack-refs.sh
> @@ -238,4 +238,19 @@ test_expect_success 'retry acquiring packed-refs.lock' '
>   git -c core.packedrefstimeout=3000 pack-refs --all --prune
>  '
>  
> +test_expect_success 'pack symlinked packed-refs' '
> + # First make sure that symlinking works when reading:
> + git update-ref refs/heads/loosy refs/heads/master &&
> + git for-each-ref >all-refs-before &&
> + mv .git/packed-refs .git/my-deviant-packed-refs &&
> + ln -s my-deviant-packed-refs .git/packed-refs &&
> + git for-each-ref >all-refs-linked &&
> + test_cmp all-refs-before all-refs-linked &&
> + git pack-refs --all --prune &&
> + git for-each-ref >all-refs-packed &&
> + test_cmp all-refs-before all-refs-packed &&
> + test -h .git/packed-refs &&
> + test "$(readlink .git/packed-refs)" = "my-deviant-packed-refs"
> +'
> +
>  test_done

Re: Expected behavior of "git check-ignore"...

[Junio C Hamano]

John Szakmeister  writes:

> On Mon, Jul 24, 2017 at 3:23 PM, Junio C Hamano  wrote:
> [snip]
>> I am reasonably sure that the command started its life as a pure
>> debugging aid.
>>
>> The treatment of the negation _might_ impose conflicting goals to
>> its purpose as a debugging aid---a user who debugs his .gitignore
>> file would want to know what causes a thing that wants to be ignored
>> is not or vice versa, and use of the exit status to indicate if it
>> is ignored may not mesh well with its goal as a debugging aid, but I
>> didn't think about the potential issues deeply myself while writing
>> this response.  As you mentioned, use of (or not using) "-v" could
>> be used as a sign to see which behaviour the end-user expects, I
>> guess.
>
> Is there another way of checking to see if a file is ignored?  If so,...

Maybe I sounded like waffling, but I do think "check-ignore" when
used as an end-user tool should be that command, to get a preview of
what would happen if you gave the path to "git add".  

I was merely giving a possible explanation why it may not behave
like so in the current code, i.e. those who used it for debugging
their .gitignore files may have felt that the current way to handle
negation were more convenient during their debugging session.

But I think there is a way out to satisfy both groups of people.

What if we (re)define that "-v" is a way to ask "which entry, if
any, decides the final fate of this path?" question, and that is a
sign that the user is using it to debug their .gitignore?  And we
use the exit status to mean "Yeah, there is an explicit entry that
decides the fate of the path" in that case, which is what the
current behaviour seems to be---the command exits with non-zero
status only when there is nothing that matches in the exclude
mechanism (which makes the final fate of the path to be 'not
ignored').

And we interpret the lack of "-v" as a signal that the user wants to
learn the fate of a given path via the exit status of the command,
which will "fix" the exit code to match the expectation in your
initial message in this thread.

Would that work well?

Re: [PATCH] git-contacts: Add recognition of Reported-by

[Junio C Hamano]

Jeff King  writes:

> Yeah, I don't think interpret-trailers is currently a useful tool for
> looking at an extra config key like that. I'd expect it would need to be
> extended, or a new tool added, or perhaps existing tools would need to
> learn more about how trailers work (e.g., it would be nice if git-log
> could do matching or even print them via %(trailer:reported-by)
> placeholders or something). I think there's a lot of potential work in
> that area.
>
> Of course git-contacts (or send-email) _can_ just look look at all of
> the trailer.*.autocc config and try to match those manually. But the
> point of having trailer config, I think, is that we should stop doing
> ad-hoc parsing and have a tool for manipulating and querying trailers.
> If interpret-trailers isn't up to the task yet, I'd rather see work go
> there.
>
> But that (manual parsing) is basically how the current cc and s-o-b
> trailers implemented inside of git-send-email, so I don't think it would
> be the end of the world as a quick hack that could later be expanded to
> use the trailer infrastructure.

OK.

In any case, I think not CC'ing the reporter would be a bug, and an
update to the "contacts" script (in contrib/) to use an improved
convention and interpret-trailers tool can be built on top of the
version Eric posted, so let's take the patch anyway for now.

Thanks.

Re: [PATCH] credential-cache: interpret an ECONNRESET as on EOF

[Ramsay Jones]

Hi Junio,

I just noticed a typo in the subject line for this patch. It should
read '... ECONNRESET as _an_ EOF' not '... ECONNRESET as _on_ EOF'.

[complete patch snipped!]

Thanks!

ATB,
Ramsay Jones

Re: Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

[Junio C Hamano]

Jeff King  writes:

> On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:
>
>> What I saw was that a test have ended up with .git/%46%4F%4F when it
>> was told to create a ref "FOO" (which indicates that "FOO" was
>> passed to the files backend), which later failed to read it back
>> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
>> the reading side.
>> 
>> Perhaps it is only a bug in t/t1405-main-ref-store.sh?
>
> An interesting related issue for pseudo-refs: if you encode HEAD as
> .git/%48%45%41%44, how will we recognize that directory as a git
> repository?

Yes, that is a valid point.  I may have forgot to explain why the
sample change in my message upthread special cases "HEAD" and leaves
it untouched, but it is done for this exact reason.

>   1. It should say "this is a git repo, but not a vintage I understand".
>  Not "this isn't a git repo, I'll keep looking".
>
>   2. How does a git version of the correct vintage decide "this is a git
>  repo, so I'll check its config for extensions.refBackend, and a-ha,
>  they _do_ have a HEAD". There's a chicken-and-egg problem.

Yes, exactly.

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

[Junio C Hamano]

Phillip Wood  writes:

>> On 26/07/17 23:12, Junio C Hamano wrote:
>>> I think
>>> you are already 80% there without adding a yet another option,...
>> ...
>> I'm interested in the 20% as it's about 100% of my rebase conflicts.

OK, then at least a fixed --rerere-autoupdate would hopefully limit
the scope of the additional 20%; I'd suspect that a new option would
also internally turn on --rerere-autoupdate, so that the remaining
changes you would see upon --continue would be limited to what the
user had to manually resolve (and edit without having textual conflict,
aka evil merge to resolve semantic conflicts).

I am *not* opposed to an option to tell the command to blindly take
such remaining changes, as long as it stays optional---the use of
the option can then be taken as a strong signal that the user is OK
with the local changes in the working tree, even if the user may not
have marked them as resolved with "git add".

>>> And from the
>>> workflow point of view, encouraging them to "git add" their manual
>>> resolution after they are satisified with their changes by not doing
>>> "git add" blindly for all changes, like your --autostage" does, is
>>> probably a good thing.
>
> Git allows 'git commit -a' to complete a conflicted merge which I
> think is much the same thing as I'm proposing

"-a" is a strong enough sign that the user is OK with all the paths;
"git commit" without an option does not.  So it is OK for a new
option (perhaps "--all-autoupdate", which does more than the
existing "--rerere-autoupdate") to become the signal that the user
is OK with all the local changes.

This is a tangent, but concluding a merge with "commit -a" (or "add
-u && commit -a") has always been discouraged among Git expert
users, and it will stay to be so.  If you search the list archive,
you would find a good explanation by Linus on this, but a short
version is that this is because it is normal to start a merge in a
dirty working tree where the user has local changes that the user
knows will not interfere with the merge.  

Because "rebase" refuses to work in a dirty working tree, the
analogy with "merge" does not quite hold.  Doing "add -u" before
telling it to "--continue" would be much safer.

Thanks.

Re: [PATCH] credential-cache: interpret an ECONNRESET as on EOF

[Jeff King]

On Thu, Jul 27, 2017 at 03:42:36PM +0100, Ramsay Jones wrote:

> yep, I did think about adding a FLAG_EXIT (or somesuch) and passing
> it down through the call stack to send_request() so that I could do
> the check only for the 'exit' command. I decided against it in the
> end, obviously! ;-)

I had the same thought. I don't think it's worth the trouble, either.

> > So I don't think this really changes the robustness much. If we did want
> > to address those cases, we'd require actual end-of-record framing in the
> > protocol. But I don't think it's worth caring too much about (this is,
> > after all, a local and internal socket between two relatively simple
> > programs).
> 
> Adding the framing to the protocol was actually my first (very fleeting)
> idea. However, I didn't want to get into the 'supporting old/new client
> and server combos' problem.

One nice thing about this protocol is that it's just between the caching
client and server, which ship together and which run for a default of 5
minutes. I think it would probably be OK to just assume you have a
matched pair, and change the protocol as you like.

So I'd be fine if somebody wanted to tackle this, but I don't think it
matters that much. After all, it's proxying requests that came over the
credential helper protocol, which also isn't framed. And changing that
one _would_ be a compatibility problem.

-Peff

Re: [PATCH] credential-cache: interpret an ECONNRESET as on EOF

[Ramsay Jones]

On 27/07/17 15:17, Jeff King wrote:
> On Thu, Jul 27, 2017 at 02:08:40AM +0100, Ramsay Jones wrote:
> 
>> In order to suppress the fatal exit in this case, check the read error
>> for an ECONNRESET and return as if no data was read from the daemon.
>> This effectively converts an ECONNRESET into an EOF.
> 
> Yeah, I think this is a perfectly reasonable thing to do.
> 
> I'm not sure if we'd _ever_ see ECONNRESET on Linux. The only time I've
> seen it on Linux (and I coincidentally fixed a bug just like this a week
> or two ago, so it's fresh in my mind): if read() would return EOF but
> there's outstanding data from a previous write, you get ECONNRESET.
> Which is obviously going to be totally racy, since "outstanding" across
> a TCP connection involves more than just the local kernel.
> 
> That shouldn't happen in this 'exit' case. But even if it does, there's
> really nothing the client should do differently anyway. We're waiting
> for the other side to exit, and they did. Hooray.
> 
> Though your change:
> 
>> diff --git a/credential-cache.c b/credential-cache.c
>> index 91550bfb0..13a0b 100644
>> --- a/credential-cache.c
>> +++ b/credential-cache.c
>> @@ -25,7 +25,7 @@ static int send_request(const char *socket, const struct 
>> strbuf *out)
>>  int r;
>>  
>>  r = read_in_full(fd, in, sizeof(in));
>> -if (r == 0)
>> +if (r == 0 || (r < 0 && errno == ECONNRESET))
>>  break;
>>  if (r < 0)
>>  die_errno("read error from cache daemon");
> 
> ...is in the generic send_request(). Which means that it hits all of the
> commands. So if we were to send a credential and the server
> crashed midway through reading it, we'd get ECONNRESET. And instead of
> reporting an error, we'd quietly assume the server had no response. But
> again, I don't think that's really different than the EOF behavior. The
> server could read our whole request and then crash, and we'd mistakenly
> think it had nothing to say.

yep, I did think about adding a FLAG_EXIT (or somesuch) and passing
it down through the call stack to send_request() so that I could do
the check only for the 'exit' command. I decided against it in the
end, obviously! ;-)

> So I don't think this really changes the robustness much. If we did want
> to address those cases, we'd require actual end-of-record framing in the
> protocol. But I don't think it's worth caring too much about (this is,
> after all, a local and internal socket between two relatively simple
> programs).

Adding the framing to the protocol was actually my first (very fleeting)
idea. However, I didn't want to get into the 'supporting old/new client
and server combos' problem.

> Which is all a verbose way of saying that your patch looks good to me.
> Thanks for digging up the root cause of the test failures.

Thanks!

ATB,
Ramsay Jones

Re: Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

[Jeff King]

On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:

> Michael Haggerty  writes:
> 
> > I think the most natural thing would be to use different encoding
> > rules for pseudo-refs (references like "HEAD" and "FETCH_HEAD") and
> > for other references (those starting with "refs/").
> >
> > Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
> > beasts
> 
> I agree with the reasoning, but what I am worried about is that
> their handling in the existing refs.c code may be leaky and/or
> inconsistent.
> 
> What I saw was that a test have ended up with .git/%46%4F%4F when it
> was told to create a ref "FOO" (which indicates that "FOO" was
> passed to the files backend), which later failed to read it back
> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
> the reading side.
> 
> Perhaps it is only a bug in t/t1405-main-ref-store.sh?

An interesting related issue for pseudo-refs: if you encode HEAD as
.git/%48%45%41%44, how will we recognize that directory as a git
repository? Detecting (and doing a sanity check on) "HEAD" is one of the
key mechanisms for deciding whether we are in a git repository.

Obviously an older version of git that doesn't know about the new
encoding scheme wouldn't work on this repository anyway. But:

  1. It should say "this is a git repo, but not a vintage I understand".
 Not "this isn't a git repo, I'll keep looking".

  2. How does a git version of the correct vintage decide "this is a git
 repo, so I'll check its config for extensions.refBackend, and a-ha,
 they _do_ have a HEAD". There's a chicken-and-egg problem.

Obviously for (2) we could teach that mechanism to look for the encoded
HEAD file, too. But this is just one backend. What about a reftable or
other non-filesystem store that keeps "HEAD" inside a file?

I kind of wonder if more exotic ref storage backends should always just
place a dummy "HEAD" file that is enough to bootstrap the "this is a git
repo" process (for both new and old versions).

This is orthogonal to the rest of the pseudo-refs discussion, but just
something I thought of while reading the thread.

-Peff

Re: reftable [v3]: new ref storage format

[Michael Haggerty]

Thanks for your continued work on this.

I have some comments about v3 (inline below).

On Sat, Jul 22, 2017 at 11:29 AM, Shawn Pearce  wrote:
> 3rd iteration of the reftable storage format.
>
> [...]
> ### Objectives
>
> - Near constant time lookup for any single reference, even when the
>   repository is cold and not in process or kernel cache.
> - Near constant time verification a SHA-1 is referred to by at least
>   one reference (for allow-tip-sha1-in-want).
> - Efficient lookup of an entire namespace, such as `refs/tags/`.
> - Support atomic push `O(size_of_update)` operations.
> - Combine reflog storage with ref storage.

I think that the optimization enabled by obj_records is only
interesting for server-side repositories that will frequently be
fetched from, and which additionally have allow-tip-sha1-in-want
turned on, right? So could we make it explicitly optional?

> [...]
>  obj record
>
> An `obj_record` describes a single object abbreviation, and the blocks
> containing references using that unique abbreviation:
>
> varint( prefix_length )
> varint( (suffix_length << 3) | cnt_3 )
> suffix
> varint( cnt_rest )?
> varint( block_delta )+
>
> Like in reference blocks, abbreviations are prefix compressed within
> an obj block.  On large reftable files with many unique objects,
> higher block sizes (64k), and higher restart interval (128), a
> `prefix_length` of 2 or 3 and `suffix_length` of 3 may be common in
> obj records (unique abbreviation of 5-6 raw bytes, 10-12 hex digits).
>
> Each record contains `block_count` number of block identifiers for ref
> blocks.  The `block_count` is determined by:
>
> block_count = cnt_3
> if (cnt_3 == 0x7) {
>   block_count += cnt_rest
> }
>
> The `cnt_rest` field is only present when `block_count >= 0x7` and
> could overflow the `cnt_3` field available in the record start.  This
> encoding scheme is used as the vast majority of abbreviations are
> only one reference (or at most a few), and unlikely to exceed 6 blocks.

I agree that this `cnt_3` handling is overly cute. There will never be
records with `block_count == 0`, will there? Then I propose that
`cnt_3` be set to zero if `block_count` is greater than 7, in which
case the full block count is stored as a varint. It's simpler, and I
think the only `block_count`s for which this scheme costs a byte more
than your scheme are implausible: 128-134, 16383-16390, etc.

> [...]
> ### Log block format

I'm still not happy about how you store reflogs. Here are my objections:

* You store reflogs by appending a high-resolution time to the
refname. This is awkward:
  * There is always some uncertainty about uniqueness, even with a
high-resolution clock. If you want to eliminate that uncertainty, you
have to read the last entry in the reflog for the reference *for every
update* to be sure that your timestamp is not already "in use".
  * There is a need to invent microsecond values on systems with
low-resolution clocks, again to ensure uniqueness.
  * If there is clock skew, then either you lose information about the
*order* of reference updates (which I would consider unacceptable), or
you might have to invent fictional times for new updates to retain the
order relative to previous updates. But inventing fictional times is
very problematic: suppose somebody's clock is incorrectly set to the
year 2020 when they make a commit. As far as Git is concerned, that is
plausible, so the reflog entry gets that timestamp. Then the user
corrects the clock and makes another commit. We would either be forced
to rewrite the old reflog entry(ies) or to give a timestamp in 2020 to
the new update.
* With reftable storage, multiple-reference updates can be done
atomically. But the reflogs don't retain the information about which
references were updated together.
* Even if all reflogs are retained, it is not possible to deduce the
global state of all references at a moment in the past.

I propose to solve all of the above problems, plus some others, as follows:

Let's keep an integer `update_index`, which starts at zero and
increases by one each atomic reference update (i.e., it increases by
one even if the update touches multiple references).

Let's store reflog entries under keys `(refname, update_index)`, and
store the timestamp of the entry *within* the record rather than as
part of the key. The tuple `(refname, update_index)` has to be encoded
somehow that ensures the desired order; see below. This encoding
ensures that the order of reference updates is well-defined regardless
of clock skew, and that one can use the reflog to determine which
references were updated together and what the complete state of
references was after any update (assuming that the user retains all
reflogs).

Let's store in the header of each reftable file the `min_update_index`
and `max_update_index` that are covered by the file. Do this such that
the indexes chain together properly for the reftables 

Re: [PATCH] credential-cache: interpret an ECONNRESET as on EOF

[Jeff King]

On Thu, Jul 27, 2017 at 02:08:40AM +0100, Ramsay Jones wrote:

> In order to suppress the fatal exit in this case, check the read error
> for an ECONNRESET and return as if no data was read from the daemon.
> This effectively converts an ECONNRESET into an EOF.

Yeah, I think this is a perfectly reasonable thing to do.

I'm not sure if we'd _ever_ see ECONNRESET on Linux. The only time I've
seen it on Linux (and I coincidentally fixed a bug just like this a week
or two ago, so it's fresh in my mind): if read() would return EOF but
there's outstanding data from a previous write, you get ECONNRESET.
Which is obviously going to be totally racy, since "outstanding" across
a TCP connection involves more than just the local kernel.

That shouldn't happen in this 'exit' case. But even if it does, there's
really nothing the client should do differently anyway. We're waiting
for the other side to exit, and they did. Hooray.

Though your change:

> diff --git a/credential-cache.c b/credential-cache.c
> index 91550bfb0..13a0b 100644
> --- a/credential-cache.c
> +++ b/credential-cache.c
> @@ -25,7 +25,7 @@ static int send_request(const char *socket, const struct 
> strbuf *out)
>   int r;
>  
>   r = read_in_full(fd, in, sizeof(in));
> - if (r == 0)
> + if (r == 0 || (r < 0 && errno == ECONNRESET))
>   break;
>   if (r < 0)
>   die_errno("read error from cache daemon");

...is in the generic send_request(). Which means that it hits all of the
commands. So if we were to send a credential and the server
crashed midway through reading it, we'd get ECONNRESET. And instead of
reporting an error, we'd quietly assume the server had no response. But
again, I don't think that's really different than the EOF behavior. The
server could read our whole request and then crash, and we'd mistakenly
think it had nothing to say.

So I don't think this really changes the robustness much. If we did want
to address those cases, we'd require actual end-of-record framing in the
protocol. But I don't think it's worth caring too much about (this is,
after all, a local and internal socket between two relatively simple
programs).

Which is all a verbose way of saying that your patch looks good to me.
Thanks for digging up the root cause of the test failures.

-Peff

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

[Phillip Wood]

On 27/07/17 11:36, Phillip Wood wrote:

On 26/07/17 23:12, Junio C Hamano wrote:

Junio C Hamano  writes:


Hmph, this is interesting.

"git rebase" does take "--rerere-autoupdate" option from the command
line, and propagates it to a later invocation of "rebase --continue"
by storing the value to $state_dir/allow_rerere_autoupdate file and
reading the value from it.  $allow_rerere_autoupdate shell variable
is used to hold the setting.

I'd expect that this variable to be used in invocations of "git am"
in git-rebase--am.sh; but that does not seem to be the case.  I
wonder if this was once working but over time we broke the feature
without anybody noticing it, or if the support was added but not
completed and the feature was a no-op from the beginning?


At least in v1.7.0 when doing "rebase -m", the rerere-autoupdate was
plumbed correctly through to the invocation of "git merge" that is
done inside git-rebase.sh.  I do not see the same option passed down
to the invocation of "git am", so perhaps nobody cared back then
about rerere during "git rebase" that does not use "git am" backend,
even though "git am" itself were capable of talking the option.

In any case, if you corrected the existing "git rebase" and its
backend so that "--rerere-autoupdate" works as advertised


I've had a quick look and I think it's just a case of adding
'$allow_rerere_autoupdate' to the invocation of 'git am'. 'git am' calls
rerere_clear() when skipping so that doesn't need to go into the shell
script. I'll come up with a test to check it works as I think it does.


I think
you are already 80% there without adding a yet another option, as I
suspect that the most of the need for avoiding "git add" during a
"git rebase" session is during a conflict resolution, and allowing
"rerere" to automatically update the index with auto-resolution will
leave _only_ changes to the paths the end user actually needs to
take a look and manually fix still not in the index.


I'm interested in the 20% as it's about 100% of my rebase conflicts.
I've got rerere enabled but I cannot recall it helping me with a rebase
conflict in the five or six years I've been using git [1]. A lot of my
rebase conflicts come from fixup! commits or reordering things with
rebase -i and generally they're only going to happen once as I don't
apply the same fixup! more than once and if I've rearranged commits the
conflicts are likely to be different in the (possibly unlikely) event I
rearrange them again in the future.

Once I've resolved a conflict I will look at the diff and maybe compile
and run some tests. Then, if I'm happy I'll run 'git rebase --continue',
to me the 'git add' stage doesn't really add anything useful, it's just
an inconvenience.

The other use I have for --autostage is when editing commits with rebase
-i, once I'm happy with the edit I just want to continue and have rebase
amend the commit. I don't feel having to run 'git add' is helpful in
this case.


And from the
workflow point of view, encouraging them to "git add" their manual
resolution after they are satisified with their changes by not doing
"git add" blindly for all changes, like your --autostage" does, is
probably a good thing.


Git allows 'git commit -a' to complete a conflicted merge which I think 
is much the same thing as I'm proposing. Also there's nothing to stop a 
user accidentally running 'git add' on a path that isn't resolved or 
just blindly running 'add -u' before continuing the rebase because they 
think they've resolved everything. I guess it is a kind of 
convenience/safety trade-off.



In my mind running 'git rebase --continue' is the signal to git that the
conflicts are resolved.
Best Wishes

Phillip

[1] Maybe I've not noticed it helping when rebasing onto an updated
upstream, although if I'm actively changing the rebased commits between
upstream updates the conflicts may well change between updates. Also I
don't tend to get many upstream conflicts with the projects I'm working on.


Thinking about it some more, once a conflict is resolved, the next time 
that rewritten commit is rebased onto an updated upstream the same 
conflict will not occur as the rewritten commit that's being replayed 
does not conflict with the previous upstream - the resolution is baked 
into the commit that's being replayed.

HELLO DEAR HOW ARE YOU DOING TODAY.

[Lincoln Bah Bah]

Dear Friend,

With due respect to your person and much sincerity of purpose. I have a 
business proposal which I will like to handle with you. $35 million USD is 
involves. But be rest assured that everything is legal and risk free as I have 
concluded all the arrangements and the legal papers that will back the 
transaction up. Kindly indicate your interest as to enable me tell you more 
detail of the proposal.

Waiting for your urgent response.
Yours Faithfully,
Dr.Lincoln Bah Bah

Re: Expected behavior of "git check-ignore"...

[John Szakmeister]

On Mon, Jul 24, 2017 at 3:23 PM, Junio C Hamano  wrote:
[snip]
> I am reasonably sure that the command started its life as a pure
> debugging aid.
>
> The treatment of the negation _might_ impose conflicting goals to
> its purpose as a debugging aid---a user who debugs his .gitignore
> file would want to know what causes a thing that wants to be ignored
> is not or vice versa, and use of the exit status to indicate if it
> is ignored may not mesh well with its goal as a debugging aid, but I
> didn't think about the potential issues deeply myself while writing
> this response.  As you mentioned, use of (or not using) "-v" could
> be used as a sign to see which behaviour the end-user expects, I
> guess.

Is there another way of checking to see if a file is ignored?  If so,
maybe we could suggest that instead.  Perhaps using `git status
--porcelain --ignored` and examining the output?  I'm not sure how
well that would work with directories.

Thanks for the insight Junio.  I'm going to let the exit status thing
drop for now.  You don't seem like it's a good thing to do, and I'm
not particularly fond of having it behave two different ways based on
`-v` being present.

-John

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

[Michael Haggerty]

Stefan, Jonathan: you're both right, the new test needs the SYMLINKS
prerequisite. Junio, would you mind adding that flag?

Thanks,
Michael

Nice To know you,

[Jack]

Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

[Phillip Wood]

On 26/07/17 23:12, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
>> Hmph, this is interesting.
>>
>> "git rebase" does take "--rerere-autoupdate" option from the command
>> line, and propagates it to a later invocation of "rebase --continue"
>> by storing the value to $state_dir/allow_rerere_autoupdate file and
>> reading the value from it.  $allow_rerere_autoupdate shell variable
>> is used to hold the setting.  
>>
>> I'd expect that this variable to be used in invocations of "git am"
>> in git-rebase--am.sh; but that does not seem to be the case.  I
>> wonder if this was once working but over time we broke the feature
>> without anybody noticing it, or if the support was added but not
>> completed and the feature was a no-op from the beginning?
> 
> At least in v1.7.0 when doing "rebase -m", the rerere-autoupdate was
> plumbed correctly through to the invocation of "git merge" that is
> done inside git-rebase.sh.  I do not see the same option passed down
> to the invocation of "git am", so perhaps nobody cared back then
> about rerere during "git rebase" that does not use "git am" backend,
> even though "git am" itself were capable of talking the option.
> 
> In any case, if you corrected the existing "git rebase" and its
> backend so that "--rerere-autoupdate" works as advertised

I've had a quick look and I think it's just a case of adding
'$allow_rerere_autoupdate' to the invocation of 'git am'. 'git am' calls
rerere_clear() when skipping so that doesn't need to go into the shell
script. I'll come up with a test to check it works as I think it does.

> I think
> you are already 80% there without adding a yet another option, as I
> suspect that the most of the need for avoiding "git add" during a
> "git rebase" session is during a conflict resolution, and allowing
> "rerere" to automatically update the index with auto-resolution will
> leave _only_ changes to the paths the end user actually needs to
> take a look and manually fix still not in the index. 

I'm interested in the 20% as it's about 100% of my rebase conflicts.
I've got rerere enabled but I cannot recall it helping me with a rebase
conflict in the five or six years I've been using git [1]. A lot of my
rebase conflicts come from fixup! commits or reordering things with
rebase -i and generally they're only going to happen once as I don't
apply the same fixup! more than once and if I've rearranged commits the
conflicts are likely to be different in the (possibly unlikely) event I
rearrange them again in the future.

Once I've resolved a conflict I will look at the diff and maybe compile
and run some tests. Then, if I'm happy I'll run 'git rebase --continue',
to me the 'git add' stage doesn't really add anything useful, it's just
an inconvenience.

The other use I have for --autostage is when editing commits with rebase
-i, once I'm happy with the edit I just want to continue and have rebase
amend the commit. I don't feel having to run 'git add' is helpful in
this case.

> And from the
> workflow point of view, encouraging them to "git add" their manual
> resolution after they are satisified with their changes by not doing
> "git add" blindly for all changes, like your --autostage" does, is
> probably a good thing.

In my mind running 'git rebase --continue' is the signal to git that the
conflicts are resolved.

Best Wishes

Phillip

[1] Maybe I've not noticed it helping when rebasing onto an updated
upstream, although if I'm actively changing the rebased commits between
upstream updates the conflicts may well change between updates. Also I
don't tend to get many upstream conflicts with the projects I'm working on.

URGENT REPLY FOR MORE DETAILS.

[casimire kere]

Compliment of the day,

I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You.
I am aware of the unsafe nature of the internet,
and was compelled to use this medium due to the nature of this project.

I have access to very vital information that can be used to transfer
this huge amount of money.

which may culminate into the investment of the said funds into your
company or any lucrative venture in your country.

If you will like to assist me as a partner then indicate your interest,
after which we shall both discuss the modalities and the sharing percentage.

Upon receipt of your reply on your expression of Interest I will give
you full details,
on how the business will be executed I am open for negotiation.

Thanks for your anticipated cooperation.

Note you might receive this message in your inbox or spam or junk folder,
depends on your web host or server network.

Regards,
Mr.Kere Casmire

Re: reftable [v3]: new ref storage format

[Stefan Beller]

On Mon, Jul 24, 2017 at 4:00 PM, Shawn Pearce  wrote:
> On Mon, Jul 24, 2017 at 3:22 PM, Stefan Beller  wrote:

>>>  index record
>>>
>>> An index record describes the last entry in another block.
>>> Index records are written as:
>>>
>>> varint( prefix_length )
>>> varint( (suffix_length << 3) | 0 )
>>> suffix
>>> varint( block_offset )
>>>
>>> Index records use prefix compression exactly like `ref_record`.
>>>
>>> Index records store `block_offset` after the suffix, specifying the
>>> offset in bytes (from the start of the file) of the block that ends
>>> with this reference.
>>
>> Instead of hardcoding the "0" in the last 3 bits, maybe pick one
>> of the reserved bit patterns to be there? I would imagine this
>> makes debugging easier:
>>
>> 0x5? Hah that must be an index block I have been
>> looking at the wrong block!
>
> This is an excellent suggestion. I'll include it in the next iteration.

I was thinking about this a bit more and wondering if this would
allow mixing all sorts of entries in the same block. Think about one
of the most common cases client side:

git commit -m "just a lonely ref update, no fancy stuff"

For that we need (a) a single ref update and (b) now that the
format evolved a single reflog entry, maybe (c) an obj entry, too.

I just realize that in this case we'd crank down the block size
such that there is very little padding required, but I still wonder
if it would be possible to omit the second (and third) block,
but rather go for a "m"ixed block containing just these 3 entries.

Additionally by setting the block_size to a special value "0",
we could indicate the omission of a footer, such that a single
ref update reftable is super small.

URGENT REPLY FOR MORE DETAILS.

[Casmire Kere]

-- 
Compliment of the day,

I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You.
I am aware of the unsafe nature of the internet,
and was compelled to use this medium due to the nature of this project.

I have access to very vital information that can be used to transfer
this huge amount of money.

which may culminate into the investment of the said funds into your
company or any lucrative venture in your country.

If you will like to assist me as a partner then indicate your interest,
after which we shall both discuss the modalities and the sharing percentage.

Upon receipt of your reply on your expression of Interest I will give
you full details,
on how the business will be executed I am open for negotiation.

Thanks for your anticipated cooperation.

Note you might receive this message in your inbox or spam or junk folder,
depends on your web host or server network.

Regards,
Mr.Kere Casmire

Re: requesting permission to use some Git for Windows code

[Philippe Joyez]

Le 25/07/2017 à 15:53, Johannes Schindelin a écrit :
>
> It is great that you can make use of the code!
>
> As to the licensing problem, I agree it is a hassle. The biggest obstacle
> is that you have to have the consent of all the authors.
>
> You hereby have mine.
>

Many thanks Johannes for your positive personal answer but also for the
very detailed tips on how to handle this.

Le 27/07/2017 à 06:30, elizarets...@gmail.com a écrit :
>
>
> An alternative would be for TeXmacs to use the code from GNU Emacs,
> which also supports Unicode file names on MS-Windows.  Emacs is of
> course GPL v3+, so there should be no problem with that.
>
Thanks you too Eli, for bringing up that piece of information; I'll
definitely take a look into it!

Philippe