Re: [ANN] Pro Git Reedited 2nd Edition

[Sitaram Chamarty]

On 08/12/2016 08:07 PM, Jon Forrest wrote:
> 
> 
> On 8/12/16 6:11 AM, Sitaram Chamarty wrote:
> 
>> At present gitolite is -- AFAIK -- the only "pure server side", "no GUI"
>> solution for access control, and has some interesting features that more
>> "GUI" solutions may not.  It is also (again, AFAIK) used by kernel.org,
>> Fedora, Gentoo, and several other open source projects as well as many
>> enterprises.
>>
>> If you're ok with adding that, I'd be happy to supply some text for your
>> consideration.
> 
> I appreciate your offer and I don't disagree with what you're
> suggesting, but my goal, for now at least, is to keep the same coverage as 
> upstream.
> 
> If they add something about Gitolite to their next edition, then
> I will also.

Oh ok; I must have misunderstood what "2nd edition" means, or did not read your
original email carefully enough.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

[Michael Haggerty]

On 08/04/2016 06:55 PM, Stefan Beller wrote:
> [...]
> I have just reread the scoring function and I think you could pull out the
> `score=indent` assignment (it is always assigned except for indent <0)
> 
> if (indent == -1)
>score = 0;
> else
>score = indent;
> ... lots of bonus computation below, which in its current 
> implementation
> have lots of "score = indent;" lines as well.

Yes. An earlier version of the heuristic used different indent values in
different situations, but that's gone away so the code can be made
simpler now. I'll make the change.

Thanks,
Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

[Michael Haggerty]

On 08/04/2016 09:52 PM, Junio C Hamano wrote:
> Michael Haggerty  writes:
>> +#define START_OF_FILE_BONUS 9
>> +#define END_OF_FILE_BONUS 46
>> +#define TOTAL_BLANK_WEIGHT 4
>> +#define PRE_BLANK_WEIGHT 16
>> +#define RELATIVE_INDENT_BONUS -1
>> +#define RELATIVE_INDENT_HAS_BLANK_BONUS 15
>> +#define RELATIVE_OUTDENT_BONUS -19
>> +#define RELATIVE_OUTDENT_HAS_BLANK_BONUS 2
> 
> When I read up to here, I thought "Heh, isn't the opposite of INdent
> DEdent?" and then saw this:
> 
>> +#define RELATIVE_DEDENT_BONUS -63
>> +#define RELATIVE_DEDENT_HAS_BLANK_BONUS 50
> 
> It turns out that you mean by OUTdent a line that indents further
> (if I am reading the code correctly).  Is that obvious to everybody?

I'll comment it better.

>> +/* Bonuses based on the location of blank lines: */
>> +bonus += TOTAL_BLANK_WEIGHT * total_blanks;
>> +bonus += PRE_BLANK_WEIGHT * m->pre_blank;
> 
> This and ...
> 
>> +} else if (indent > m->pre_indent) {
>> +/*
>> + * The line is indented more than its predecessor. Score it 
>> based
>> + * on the larger indent:
>> + */
>> +score = indent;
>> +bonus += RELATIVE_INDENT_BONUS;
>> +bonus += RELATIVE_INDENT_HAS_BLANK_BONUS * any_blanks;
>> +} else if (indent < m->pre_indent) {
> 
> ... this seems to be indented correctly even after getting quoted,
> which in turn means most of the lines in the added code share
> indent-with-non-tab badness.

The code was copy-pasted from a Python prototype then converted to C :-)

I'll fix the whitespace.

Thanks,
Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] help: make option --help open man pages only for Git commands

[Philip Oakley]

From: "Junio C Hamano" 
To: "Ralf Thielow" 
Cc: ; ; 
Sent: Friday, August 12, 2016 11:53 PM
Subject: Re: [PATCH] help: make option --help open man pages only for Git 
commands




Junio C Hamano  writes:


I love it when I say "This shouldn't be too hard; somebody may want
to do a patch", with just a vague implemention idea in my head, and
a patch magically appears with even a better design than I had in
mind when I said it [*1*] ;-)


Having said that, I wonder if we could do a bit better.

   $ git -c help.autocorrect=1 whatchange --help
   WARNING: You called a Git command named 'whatchange', which does not 
exist.

   Continuing under the assumption that you meant 'whatchanged'
   in 0.1 seconds automatically...
   No manual entry for gitwhatchange

We are guessing that the user meant "whatchanged"; shouldn't we be
able to feed the corrected name of the command to the machinery to
drive the manpage viewer?


But does it cope with the Guides? Should it cope if spelt that way?

git help revisions
git revisions --help

?

I suspect that the former should work, but not the latter, as a reasonable 
approach. I just haven't checked.


The other moderately low hanging fruit is to do the (full) list of guides as 
part of 'help'.


Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 00/12] Update git revisions

[Philip Oakley]

These are the quick fixes to Marc's comments to patches 5,6,11,
and a consequential change to 12.

Only the changed patches are included.

Philip Oakley (12):
  doc: use 'symmetric difference' consistently
  doc: revisions - name the left and right sides
  doc: show the actual left, right, and boundary marks
  doc: revisions: give headings for the two and three dot notations
  doc: revisions: extra clarification of ^! notation effects
  doc: revisions: single vs multi-parent notation comparison
  doc: gitrevisions - use 'reachable' in page description
  doc: gitrevisions - clarify 'latter case' is revision walk
  doc: revisions  - define `reachable`
  doc: revisions - clarify reachability examples
  doc: revisions: show revision expansion in examples
  doc: revisions: sort examples and fix alignment of the unchanged

 Documentation/gitk.txt |   2 +-
 Documentation/gitrevisions.txt |   6 +-
 Documentation/pretty-formats.txt   |   2 +-
 Documentation/rev-list-options.txt |   4 +-
 Documentation/revisions.txt| 125 -
 5 files changed, 88 insertions(+), 51 deletions(-)

-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 05/12] doc: revisions: extra clarification of ^! notation effects

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
v6 updated
Cc: Jakub Narębski 
Cc: Marc Branchaud 
https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/
---
 Documentation/revisions.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 3da0083..17fc45c 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -281,7 +281,8 @@ for naming a set that is formed by a commit and its parent 
commits.
 
 The 'r1{caret}@' notation means all parents of 'r1'.
 
-'r1{caret}!' includes commit 'r1' but excludes all of its parents.
+The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
+By itself, this notation denotes the single commit 'r1'.
 
 Revision Range Summary
 --
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 11/12] doc: revisions: show revision expansion in examples

[Philip Oakley]

The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.

Sort the examples and fix the alignment for those unaffected
in the next commit.

Signed-off-by: Philip Oakley 
---
v6 updated
Cc: Jakub Narębski 
Cc: Marc Branchaud 
---
 Documentation/revisions.txt | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index e9a74fc..f15d5ed 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -326,16 +326,27 @@ Revision Range Summary
   as giving commit '' and then all its parents prefixed with
   '{caret}' to exclude them (and their ancestors).
 
-Here are a handful of examples:
+Here are a handful of examples using the Loeliger illustration above,
+with each step in the notation's expansion and selection carefully
+spelt out:
 
+   Args   Expanded argumentsSelected commits
DG H D
D F  G H I J D F
^G D H D
^D B E I J F B
-   B..C C
-   B...CG H D E B C
+   B..C   = ^B CC
+   B...C  = B ^F C  G H D E B C
^D B C   E I J F B C
CI J F C
-   C^@  I J F
-   C^!  C
-   F^! DG H D F
+   C^@= C^1
+  = F   I J F
+   B^@= B^1 B^2 B^3
+  = D E F   D G H E F I J
+   C^!= C ^C^@
+  = C ^C^1
+  = C ^FC
+   B^!= B ^B^@
+  = B ^B^1 ^B^2 ^B^3
+  = B ^D ^E ^F  B
+   F^! D  = F ^I ^J D   G H D F
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 12/12] doc: revisions: sort examples and fix alignment of the unchanged

[Philip Oakley]

The previous commit adjusted the column alignment for revision
examples which show expansion. Fix the unchanged examples and sort
those that show expansions to the end of the list.

Signed-off-by: Philip Oakley 
---
v6 updated
Cc: Marc Branchaud 
---
 Documentation/revisions.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index f15d5ed..b9b45c0 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -331,14 +331,14 @@ with each step in the notation's expansion and selection 
carefully
 spelt out:
 
Args   Expanded argumentsSelected commits
-   DG H D
-   D F  G H I J D F
-   ^G D H D
-   ^D B E I J F B
+   DG H D
+   D F  G H I J D F
+   ^G D H D
+   ^D B E I J F B
+   ^D B C   E I J F B C
+   CI J F C
B..C   = ^B CC
B...C  = B ^F C  G H D E B C
-   ^D B C   E I J F B C
-   CI J F C
C^@= C^1
   = F   I J F
B^@= B^1 B^2 B^3
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 06/12] doc: revisions: single vs multi-parent notation comparison

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
v6 updated
Junio's final comment 
https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/
Cc: Marc Branchaud 
---
 Documentation/revisions.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 17fc45c..242123b 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -284,6 +284,10 @@ The 'r1{caret}@' notation means all parents of 'r1'.
 The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
 By itself, this notation denotes the single commit 'r1'.
 
+While '{caret}' was about specifying a single commit parent, these
+two notations consider all its parents. For example you can say
+'HEAD{caret}2{caret}@', however you cannot say 'HEAD{caret}@{caret}2'.
+
 Revision Range Summary
 --
 
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

[Michael Haggerty]

On 08/04/2016 09:56 AM, Jeff King wrote:
> On Thu, Aug 04, 2016 at 12:00:36AM +0200, Michael Haggerty wrote:
> 
>> This table shows the number of diff slider groups that were positioned
>> differently than the human-generated values, for various repositories.
>> "default" is the default "git diff" algorithm. "compaction" is Git 2.9.0
>> with the `--compaction-heuristic` option "indent" is an earlier,
> 
> s/option/&./

Thanks, will change.

>>  static int diff_detect_rename_default;
>> +static int diff_indent_heuristic; /* experimental */
>>  static int diff_compaction_heuristic; /* experimental */
> 
> These two flags are mutually exclusive in the xdiff code, so we should
> probably handle that here.
> 
> TBH, I do not care that much what:
> 
>   [diff]
>   compactionHeuristic = true
>   indentHeuristic = true
> 
> does. But right now:
> 
>   git config diff.compactionHeuristic true
>   git show --indent-heuristic
> 
> still prefers the compaction heuristic, which I think is objectively
> wrong.

I wasn't worrying about that yet, given that these two features are both
still experimental. I also have a strong inkling that at most one of
them needs to be made permanent. I propose that I repair the semantics
in the simplest way possible for now while we decide on the long-term
plan, which might conceivably be:

* keep both options permanently
* keep only one option permanently
* choose one heuristic and use it always (i.e., make it part of the new
standard one-and-only diff algorithm)
* discard both heuristics (I hope not!)

After we've decided on that, *then* let's decide on a suitable UI and
implement it before we declare either feature non-experimental.

> [...]
> Speaking of absurd amounts of work, I was curious if there was a
> noticeable performance penalty for using this heuristic [...]

I included some performance numbers in my response to Junio [1].

>> +#define START_OF_FILE_BONUS 9
>> +#define END_OF_FILE_BONUS 46
>> +#define TOTAL_BLANK_WEIGHT 4
>> +#define PRE_BLANK_WEIGHT 16
>> +#define RELATIVE_INDENT_BONUS -1
>> +#define RELATIVE_INDENT_HAS_BLANK_BONUS 15
>> +#define RELATIVE_OUTDENT_BONUS -19
>> +#define RELATIVE_OUTDENT_HAS_BLANK_BONUS 2
>> +#define RELATIVE_DEDENT_BONUS -63
>> +#define RELATIVE_DEDENT_HAS_BLANK_BONUS 50
> 
> I see there is a comment below here mentioning that these are empirical
> voodoo, but it might be worth one at the top (or just moving these below
> the comment) because the comment looks like it's just associated with
> the function (and these are sufficiently bizarre that anybody reading is
> going to double-take on them).

Good idea.

>> +return 10 * score - bonus;
> 
> I don't mind this not "10" not being a #define constant, but after
> reading the exchange between you and Stefan, I think it would be nice to
> describe what it is in a comment. The rest of the function is commented
> so nicely that this one left me thinking "huh?" upon seeing the "10".

Done. Thanks for your review.

Michael

[1]
http://public-inbox.org/git/5fe0edbc-3659-058f-3328-639d1343f...@alum.mit.edu/

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] help: make option --help open man pages only for Git commands

[Junio C Hamano]

Junio C Hamano  writes:

> I love it when I say "This shouldn't be too hard; somebody may want
> to do a patch", with just a vague implemention idea in my head, and
> a patch magically appears with even a better design than I had in
> mind when I said it [*1*] ;-)

Having said that, I wonder if we could do a bit better.

$ git -c help.autocorrect=1 whatchange --help
WARNING: You called a Git command named 'whatchange', which does not exist.
Continuing under the assumption that you meant 'whatchanged'
in 0.1 seconds automatically...
No manual entry for gitwhatchange

We are guessing that the user meant "whatchanged"; shouldn't we be
able to feed the corrected name of the command to the machinery to
drive the manpage viewer?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 11/12] doc: revisions: show revision expansion in examples

[Philip Oakley]

From: "Marc Branchaud" 

On 2016-08-12 03:07 AM, Philip Oakley wrote:

The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.

Sort the examples and fix the alignment for those unaffected
in the next commit.

Signed-off-by: Philip Oakley 
---
new
Cc: Jakub Narębski 
---
 Documentation/revisions.txt | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 70864d5..ac7dd8e 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -326,16 +326,23 @@ Revision Range Summary
   as giving commit '' and then all its parents prefixed with
   '{caret}' to exclude them (and their ancestors).

-Here are a handful of examples:
+Here are a handful of examples using the Loeliger illustration above:

+   Args   Expansion   Selection


I think "Result" would be better than "Selection" here.


I wanted to avoid that. I feel that "Result" is too general. I had thought 
about using the 'ed' rather than 'ion' word endings, but that would require 
(to my mind) the noun e.g. "Expanded arguments" and " Selected commits" 
(still could be - see below), while the 'ion' endings felt complete. The 
Result is what is shown in thable below these headings ;-)





Also, shouldn't all the ^ in these examples be {caret}?  (I likely just 
don't understand the rationale for using {caret} in some places and ^ in 
others...)


All the conversions appear to work. I think that asciidoc is viewing these a 
blocked text without any expansion. Plus, it would be horrendous trying to 
check the formatting (endless reruns of make.. ... .. )





DG H D
D F  G H I J D F
^G D H D
^D B E I J F B
-   B..C C
-   B...CG H D E B C
+   B..C   = ^B C  C
+   B...C  = B ^F CG H D E B C
^D B C   E I J F B C
CI J F C
-   C^@  I J F
-   C^!  C
-   F^! DG H D F
+   C^@= C^1


I have a mixed reaction to showing this "C^1" expansion, and the "B^1 B^2 
B^3" one as well.  I see the appeal of showing the parent notation, but 
really that was already explained to death in the first section.


This was the whole point. For some (e.g. me) the explanations had fallen 
flat on their face, and it was difficult to see what it was on about. Now I 
know, it's all obvious, but what was needed was a carefully stepped through 
example or two. If the dear reader can't see the big steps, let's give them 
small steps.


Jacob had given an 'example' in response to my early query, but it just felt 
like repetion of what had already been said, but it didn't take the next 
[small] step, which this example does (partly because it can as it can use 
the Loeliger diagram, which wasn't available in Jacob's example).


I also deliberately added the B^@ and B^! (standalone) example as the C^@ 
and C^!  didn't have an 'all parents' (plurals!), but it did have the 
indentation issue - see above about stretching out the headers, which would 
give more space for the indentations.


Here it's distracting.  I think it's clearer for the reader to remove 
these expansions and just use the node names from the illustration.



+  = F I J F
+   B^@= B^1 B^2 B^3
+  = D E F D G H E F I J
+   C^!= C ^C^1


I think this expansion might be better expressed as "C ^C^@".


I hadn't viewed it that way. It would be an extra step.

   It'll be the same for "B^! = B ^B^@" as well, which demonstrates a 
nice consistency and also helps to emphasize the meaning of the ^@ 
notation.



+  = C ^F  C
+   B^! = B ^B^1 ^B^2 ^B^3
+   = B ^D ^E ^F   B


The layout of these last two lines doesn't match the others.  They should 
be:


   B^!= B ^B^1 ^B^2   ^B^3
  = B ^D ^E ^FB

I see that the next patch fixes the layout of the unchanged examples, but 
it leaves these two unaligned.


As noted it was about squeezing that one in. I'll look at alternate heading 
titles and spacing options.



--
Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A note from the maintainer

[Eric Wong]

Junio C Hamano  wrote:
> For those who prefer to read it over NNTP:
> 
>   nntp://news.gmane.org/gmane.comp.version-control.git
> 
> is still available.  An alternative
> 
> nntp://news.public-inbox.org/inbox.comp.version-control.git
> 
> will become usable once it catches up with old messages.

Mostly caught up, I injected 33 more today which were
cross-posted (which tripped up some of my anti-spam rules) or
simply missed by gmane.

There may be more in some personal archives gmane doesn't
have...

I've also added NNTP links (including gmane) to the footer in
public-inbox.org/git

> message ID is often the most robust (if not very friendly) way to do
> so, like this:
> 
>   
> http://public-inbox.org/git/pine.lnx.4.58.0504150753440.7...@ppc970.osdl.org

Some of the generated links have %40 in them which is the URI
escape for '@'.  I'll make a change to keep the '@' unescaped to
lessen confusion.

Due to the use of SQLite as a stable store for NNTP article
numbers; public-inbox can also do partial matching (up to 100
results, currently) to help correct legitimate mistakes; but I
wouldn't rely on it too much:

public-inbox.org/git/Pine.LNX.4.58.0504150753440
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv4 8/8] clone: recursive and reference option triggers submodule alternates

[Junio C Hamano]

Stefan Beller  writes:

> +int add_possible_reference_from_superproject(
> + struct alternate_object_database *alt, void *sas_cb)
> +{
> + struct submodule_alternate_setup *sas = sas_cb;
> +
> + ...
> + size_t namelen = alt->name - alt->base - 1;
> + struct strbuf name = STRBUF_INIT;
> + strbuf_add(, alt->base, namelen);
> +
> + /*
> +  * If the alternate object store is another repository, try the
> +  * standard layout with .git/modules//objects
> +  */
> + if (ends_with(name.buf, ".git/objects")) {
> + char *sm_alternate;
> + struct strbuf sb = STRBUF_INIT;
> + struct strbuf err = STRBUF_INIT;
> + strbuf_add(, name.buf, name.len - strlen("objects"));
> + /*
> +  * We need to end the new path with '/' to mark it as a dir,
> +  * otherwise a submodule name containing '/' will be broken
> +  * as the last part of a missing submodule reference would
> +  * be taken as a file name.
> +  */
> + strbuf_addf(, "modules/%s/", sas->submodule_name);
> +
> + sm_alternate = compute_alternate_path(sb.buf, );

OK.  Thanks to the refactoring in the earlier step, this has become
quite straight-forward and robust; this code will always decide if
the other directory can be used as an alternate the same way the
"git clone" we will call would decide.

Good.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv4 5/8] clone: factor out checking for an alternate path

[Junio C Hamano]

Stefan Beller  writes:

> + struct strbuf sb = STRBUF_INIT;
> + char *ref_git = compute_alternate_path(item->string, );

Who owns the memory for ref_git?

> - if (!access(mkpath("%s/shallow", ref_git), F_OK))
> - die(_("reference repository '%s' is shallow"), item->string);
> + if (!ref_git)
> + die("%s", sb.buf);

Presumably the second argument to compute_alternate_path() is a
strbuf to receive the error message?  It is unfortunate that the
variable used for this purpose is a bland "sb", but perhaps that
cannot be helped as you would reuse that strbuf for a different
purpose (i.e. not to store the error message, but to formulate a
pathname).

> - if (!access(mkpath("%s/info/grafts", ref_git), F_OK))
> - die(_("reference repository '%s' is grafted"), item->string);
> + strbuf_addf(, "%s/objects", ref_git);
> + add_to_alternates_file(sb.buf);
>  
> - strbuf_addf(, "%s/objects", ref_git);
> - add_to_alternates_file(alternate.buf);
> - strbuf_release();
> - free(ref_git);
> + strbuf_release();

I am wondering about the loss of free() here in the first comment.

> +/*
> + * Compute the exact path an alternate is at and returns it. In case of
> + * error NULL is returned and the human readable error is added to `err`
> + * `path` may be relative and should point to $GITDIR.
> + * `err` must not be null.
> + */
> +char *compute_alternate_path(const char *path, struct strbuf *err)
> +{
> + char *ref_git = NULL;
> + const char *repo, *ref_git_s;
> + struct strbuf err_buf = STRBUF_INIT;

Why do you need "err_buf", instead of directly writing the error to
"err", especially if "err" is not optional?

> + ...
> +out:
> + if (err_buf.len) {
> + strbuf_addbuf(err, _buf);
> + free(ref_git);
> + ref_git = NULL;
> + }
> +
> + strbuf_release(_buf);
> + return ref_git;
> +}

So ref_git is a piece of memory on heap, and the caller is
responsible for not leaking it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 06/12] doc: revisions: single vs multi-parent notation comparison

[Philip Oakley]

From: "Marc Branchaud" 

On 2016-08-12 03:07 AM, Philip Oakley wrote:

Signed-off-by: Philip Oakley 
---
new
Junio's final comment 
https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/

---
 Documentation/revisions.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0b5044d..934d071 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -284,6 +284,10 @@ The 'r1{caret}@' notation means all parents of 'r1'.
 'r1{caret}!' notation includes commit 'r1' but excludes all of its 
parents.

 This is the single commit 'r1', if standalone.

+While '{caret}' was about specifying a single commit parent, 
these

+two notations consider all its parents. For example you can say
+'HEAD{caret}2^@', however you cannot say 'HEAD{caret}@{caret}2'.


That ^ should be {caret}, right?


Yes (I think so - will change).

I had planned to change it but it looks like I missed it.

In an earlier version I hadn't changed any of them (or maybe just one) and 
the asciidoc barfed. I suspect that the ^ ^ symbols have to be paired 
properly, and a bad pairing around / across the quotes makes the parsing 
fail. it looks like singletons (which clearly never pair) are accespted 'as 
is'


I think the later examples are inside some form of a block quote with no 
expansions at all.


--
Philip



M.




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 05/12] doc: revisions: extra clarification of ^! notation effects

[Philip Oakley]

From: "Marc Branchaud" 

On 2016-08-12 03:07 AM, Philip Oakley wrote:

Signed-off-by: Philip Oakley 
---
new
Cc: Jakub Narębski 
https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/
---
 Documentation/revisions.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 3da0083..0b5044d 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -281,7 +281,8 @@ for naming a set that is formed by a commit and its 
parent commits.


 The 'r1{caret}@' notation means all parents of 'r1'.

-'r1{caret}!' includes commit 'r1' but excludes all of its parents.
+'r1{caret}!' notation includes commit 'r1' but excludes all of its 
parents.


This sentence should start with "The".


Accepted. I'd simply split the the previous text, so the nice run-on effect 
it initially had has been lost.





+This is the single commit 'r1', if standalone.


That reads awkwardly to me.  Perhaps

   By itself, this notation denotes the single commit 'r1'.


Like it. I'd toyed wth quite a few variants. It's jsut a case of finding the 
nicest one;-)




?

M.

--


Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/9] status: V2 porcelain status

[Junio C Hamano]

Jeff Hostetler  writes:

> This v8 patch series addresses the remaining feedback
> about the unit tests from the v6 and v7 series.

Thanks, will re-queue.

I didn't spot anything glaringly wrong in the last patch, and all
the ealier steps looked good in the previous round, so I think we
are getting there.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/3] diff: add --diff-line-prefix option for passing in a prefix

[Jacob Keller]

On Fri, Aug 12, 2016 at 2:21 PM, Jacob Keller  wrote:
> On Fri, Aug 12, 2016 at 2:15 PM, Junio C Hamano  wrote:
>> Otherwise, a "git log --graph -p --submodule=log-with-diff", when
>> showing a commit in the superproject that changes submodule from
>> commit A to commit B, wouldn't be able to run "git log --graph -p A..B",
>> i.e. as if the command recursed beyond the module boundary, would
>> it?
>>
>
> H, yes. I'll dig through and see if I can get the prefix to be
> honored by the git log as well.
>
> Thanks,
> Jake

Ok so the big problem here is that unlike with diff which has support
for line-prefixes already due to needing it for graph mode, I can't
figure out where to get the prefix added for log output. Especially if
we want it to be honored prior to the graph output. This seems like a
much bigger task, which is better saved for future maybe?

Thanks,
Jake
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] help: make option --help open man pages only for Git commands

[Junio C Hamano]

Ralf Thielow  writes:

> If option --help is passed to a Git command, we try to open
> the man page of that command. However, we do it even for commands
> we don't know.  Make sure the command is known to Git before try
> to open the man page.  If we don't know the command, give the
> usual advice.
>
> Signed-off-by: Ralf Thielow 
> ---

I love it when I say "This shouldn't be too hard; somebody may want
to do a patch", with just a vague implemention idea in my head, and
a patch magically appears with even a better design than I had in
mind when I said it [*1*] ;-)

>  builtin/help.c  | 21 ++---
>  t/t0012-help.sh | 15 +++
>  2 files changed, 29 insertions(+), 7 deletions(-)
>  create mode 100755 t/t0012-help.sh
>
> diff --git a/builtin/help.c b/builtin/help.c
> index 8848013..55d45de 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -433,10 +433,22 @@ static void list_common_guides_help(void)
>   putchar('\n');
>  }
>  
> +static void check_git_cmd(const char* cmd) {
> + char *alias = alias_lookup(cmd);
> +
> + if (!is_git_command(cmd)) {
> + if (alias) {
> + printf_ln(_("`git %s' is aliased to `%s'"), cmd, alias);
> + free(alias);
> + exit(0);
> + } else
> + help_unknown_cmd(cmd);
> + }
> +}

Looks quite reasonable to reuse help_unknown_cmd() there.

Thanks, will queue.


[Footnote]

*1* The vague thing I had in my mind was to use is_git_command() and
alias_lookup() to prevent the "git foo --help" -> "git help foo" 
magic from triggering for 'foo' that is not known.  Your solution
is MUCH cleaner and more straight-forward.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 00/12] Update git revisions

[Junio C Hamano]

"Philip Oakley"  writes:

> I'll work on the tweaks, though it'll probably be tomorrow as we have
> visitors.

Thank you for working on this; Marc, thank you for many good review
comments.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/3] diff: add --diff-line-prefix option for passing in a prefix

[Jacob Keller]

On Fri, Aug 12, 2016 at 2:15 PM, Junio C Hamano  wrote:
> Jacob Keller  writes:
>
>> The prefix shall come first prior to any other prefix associated with
>> the --graph option or other source.
>>
>> Add tests for the same.
>>
>> Signed-off-by: Jacob Keller 
>> ---
>> - v5
>> * Changed name to --diff-line-prefix since --line-prefix might indicate
>>   for other commands such as log, when it only modifies diff output
>
> As you are adding this to "diff.c", I think the option would be
> visible to "git log" anyway, and more importantly
>
> git log --line-prefix='I I ' --graph --boundary -p HEAD^..HEAD
>
> should honor the line-prefix for the log message part.  I'd expect
> that its output would be like:
>
> I I * commit 3c90ffd2f01e2d0d080c8e42df2ee89709b324de
> I I | Author: Jacob Keller 
> I I | Date:   Thu Aug 11 15:59:45 2016 -0700
> I I |
> I I | diff: add --diff-line-prefix option for passing in a prefix
> I I |
> I I | Add an option to pass additional prefix to be displayed before diff
> I I | output. This feature will be used in a following patch to output 
> correct
> I I | ...
> I I | Signed-off-by: Jacob Keller 
> I I | Signed-off-by: Junio C Hamano 
> I I |
> I I | diff --git a/Documentation/diff-options.txt 
> b/Documentation/diff-options.txt
> I I | index 705a873..f924f57 100644
> I I | --- a/Documentation/diff-options.txt
> I I | +++ b/Documentation/diff-options.txt
> I I | ...
>
> Otherwise, a "git log --graph -p --submodule=log-with-diff", when
> showing a commit in the superproject that changes submodule from
> commit A to commit B, wouldn't be able to run "git log --graph -p A..B",
> i.e. as if the command recursed beyond the module boundary, would
> it?
>

H, yes. I'll dig through and see if I can get the prefix to be
honored by the git log as well.

Thanks,
Jake

>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/3] diff: add --diff-line-prefix option for passing in a prefix

[Junio C Hamano]

Jacob Keller  writes:

> The prefix shall come first prior to any other prefix associated with
> the --graph option or other source.
>
> Add tests for the same.
>
> Signed-off-by: Jacob Keller 
> ---
> - v5
> * Changed name to --diff-line-prefix since --line-prefix might indicate
>   for other commands such as log, when it only modifies diff output

As you are adding this to "diff.c", I think the option would be
visible to "git log" anyway, and more importantly

git log --line-prefix='I I ' --graph --boundary -p HEAD^..HEAD

should honor the line-prefix for the log message part.  I'd expect
that its output would be like:

I I * commit 3c90ffd2f01e2d0d080c8e42df2ee89709b324de
I I | Author: Jacob Keller 
I I | Date:   Thu Aug 11 15:59:45 2016 -0700
I I | 
I I | diff: add --diff-line-prefix option for passing in a prefix
I I | 
I I | Add an option to pass additional prefix to be displayed before diff
I I | output. This feature will be used in a following patch to output 
correct
I I | ...
I I | Signed-off-by: Jacob Keller 
I I | Signed-off-by: Junio C Hamano 
I I | 
I I | diff --git a/Documentation/diff-options.txt 
b/Documentation/diff-options.txt
I I | index 705a873..f924f57 100644
I I | --- a/Documentation/diff-options.txt
I I | +++ b/Documentation/diff-options.txt
I I | ...

Otherwise, a "git log --graph -p --submodule=log-with-diff", when
showing a commit in the superproject that changes submodule from
commit A to commit B, wouldn't be able to run "git log --graph -p A..B",
i.e. as if the command recursed beyond the module boundary, would
it?



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] help: make option --help open man pages only for Git commands

[Ralf Thielow]

If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it even for commands
we don't know.  Make sure the command is known to Git before try
to open the man page.  If we don't know the command, give the
usual advice.

Signed-off-by: Ralf Thielow 
---
 builtin/help.c  | 21 ++---
 t/t0012-help.sh | 15 +++
 2 files changed, 29 insertions(+), 7 deletions(-)
 create mode 100755 t/t0012-help.sh

diff --git a/builtin/help.c b/builtin/help.c
index 8848013..55d45de 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -433,10 +433,22 @@ static void list_common_guides_help(void)
putchar('\n');
 }
 
+static void check_git_cmd(const char* cmd) {
+   char *alias = alias_lookup(cmd);
+
+   if (!is_git_command(cmd)) {
+   if (alias) {
+   printf_ln(_("`git %s' is aliased to `%s'"), cmd, alias);
+   free(alias);
+   exit(0);
+   } else
+   help_unknown_cmd(cmd);
+   }
+}
+
 int cmd_help(int argc, const char **argv, const char *prefix)
 {
int nongit;
-   char *alias;
enum help_format parsed_help_format;
 
argc = parse_options(argc, argv, prefix, builtin_help_options,
@@ -476,12 +488,7 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
if (help_format == HELP_FORMAT_NONE)
help_format = parse_help_format(DEFAULT_HELP_FORMAT);
 
-   alias = alias_lookup(argv[0]);
-   if (alias && !is_git_command(argv[0])) {
-   printf_ln(_("`git %s' is aliased to `%s'"), argv[0], alias);
-   free(alias);
-   return 0;
-   }
+   check_git_cmd(argv[0]);
 
switch (help_format) {
case HELP_FORMAT_NONE:
diff --git a/t/t0012-help.sh b/t/t0012-help.sh
new file mode 100755
index 000..0dab88d
--- /dev/null
+++ b/t/t0012-help.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+test_description='help'
+
+. ./test-lib.sh
+
+test_expect_success "pass --help to unknown command" "
+   cat <<-EOF >expected &&
+   git: '123' is not a git command. See 'git --help'.
+   EOF
+   (git 123 --help 2>actual || true) &&
+   test_i18ncmp expected actual
+"
+
+test_done
-- 
2.9.2.911.g31804cd.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

What's cooking in git.git (Aug 2016, #05; Fri, 12)

[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.

v2.9.3 has been tagged as the third maintenance release for 2.9
series.  I am planning to tag v2.10-rc0 preview this weekend.  As
the topics that are still in-flight (either in 'pu' or still
outside) are mostly multi-patch series that can have large impact,
I think it is safe to say that they are not likely to be in the
upcoming 2.10 but some of them may hit 'next' during the pre-release
feature freeze.  We'll see.

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

--
[Graduated to "master"]

* ew/http-backend-batch-headers (2016-08-10) 1 commit
  (merged to 'next' on 2016-08-11 at 93476b4)
 + http-backend: buffer headers before sending

 The http-backend (the server-side component of smart-http
 transport) used to trickle the HTTP header one at a time.  Now
 these write(2)s are batched.


* jk/big-and-future-archive-tar (2016-08-06) 1 commit
  (merged to 'next' on 2016-08-11 at 0abbd07)
 + archive-tar: make write_extended_header() void

 A small code clean-up.


* jk/trace-fixup (2016-08-05) 8 commits
  (merged to 'next' on 2016-08-11 at 56f7621)
 + trace: do not fall back to stderr
 + write_or_die: drop write_or_whine_pipe()
 + trace: disable key after write error
 + trace: correct variable name in write() error message
 + trace: cosmetic fixes for error messages
 + trace: use warning() for printing trace errors
 + trace: stop using write_or_whine_pipe()
 + trace: handle NULL argument in trace_disable()

 Various small fixups to the "GIT_TRACE" facility.


* js/import-tars-hardlinks (2016-08-03) 1 commit
  (merged to 'next' on 2016-08-11 at 034230e)
 + import-tars: support hard links

 "import-tars" fast-import script (in contrib/) used to ignore a
 hardlink target and replaced it with an empty file, which has been
 corrected to record the same blob as the other file the hardlink is
 shared with.


* js/mv-dir-to-new-directory (2016-08-08) 1 commit
  (merged to 'next' on 2016-08-11 at c806ba2)
 + git mv: do not keep slash in `git mv dir non-existing-dir/`

 "git mv dir non-existing-dir/" did not work in some environments
 the same way as existing mainstream platforms.  The code now moves
 "dir" to "non-existing-dir", without relying on rename("A", "B/")
 that strips the trailing slash of '/'.


* kw/patch-ids-optim (2016-08-11) 4 commits
  (merged to 'next' on 2016-08-11 at f3ba3d0)
 + rebase: avoid computing unnecessary patch IDs
 + patch-ids: add flag to create the diff patch id using header only data
 + patch-ids: replace the seen indicator with a commit pointer
 + patch-ids: stop using a hand-rolled hashmap implementation

 When "git rebase" tries to compare set of changes on the updated
 upstream and our own branch, it computes patch-id for all of these
 changes and attempts to find matches. This has been optimized by
 lazily computing the full patch-id (which is expensive) to be
 compared only for changes that touch the same set of paths.


* ms/document-pack-window-memory-is-per-thread (2016-08-10) 1 commit
  (merged to 'next' on 2016-08-11 at 228e96d)
 + document git-repack interaction of pack.threads and pack.windowMemory


* rs/child-process-init (2016-08-05) 1 commit
  (merged to 'next' on 2016-08-11 at 860857b)
 + use CHILD_PROCESS_INIT to initialize automatic variables

 A small code clean-up.


* rs/merge-add-strategies-simplification (2016-08-05) 1 commit
  (merged to 'next' on 2016-08-11 at 6b8dfc1)
 + merge: use string_list_split() in add_strategies()

 A small code clean-up.


* rs/merge-recursive-string-list-init (2016-08-05) 1 commit
  (merged to 'next' on 2016-08-11 at 37e62ba)
 + merge-recursive: use STRING_LIST_INIT_NODUP

 A small code clean-up.


* rs/use-strbuf-add-unique-abbrev (2016-08-06) 1 commit
  (merged to 'next' on 2016-08-11 at 81ac5ff)
 + use strbuf_add_unique_abbrev() for adding short hashes

 A small code clean-up.


* sb/submodule-clone-retry (2016-08-09) 1 commit
  (merged to 'next' on 2016-08-11 at 4600b20)
 + submodule--helper: use parallel processor correctly

 Fix-up to an error codepath in a topic already in 'master'.


* va/i18n (2016-08-10) 3 commits
  (merged to 'next' on 2016-08-11 at d6e1422)
 + i18n: git-stash: mark messages for translation
 + i18n: archive: mark errors for translation
 + i18n: setup: mark error messages for translation


* vs/completion-branch-fully-spelled-d-m-r (2016-08-09) 1 commit
  (merged to 'next' on 2016-08-11 at a6f189c)
 + completion: complete --delete, --move, and --remotes for git branch


* vs/typofix (2016-08-11) 1 commit
  (merged to 'next' on 2016-08-11 at 435c418)
 + Spelling fixes

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address .  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

http://public-inbox.org/git/
http://marc.info/?l=git
http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

nntp://news.gmane.org/gmane.comp.version-control.git

is still available.  An alternative

nntp://news.public-inbox.org/inbox.comp.version-control.git

will become usable once it catches up with old messages.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:


http://public-inbox.org/git/pine.lnx.4.58.0504150753440.7...@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at .


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list .  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  

[ANNOUNCE] Git v2.9.3

[Junio C Hamano]

The latest maintenance release Git v2.9.3 is now available at
the usual places.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.9.3'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git



Git v2.9.3 Release Notes


Fixes since v2.9.2
--

 * A helper function that takes the contents of a commit object and
   finds its subject line did not ignore leading blank lines, as is
   commonly done by other codepaths.  Make it ignore leading blank
   lines to match.

 * Git does not know what the contents in the index should be for a
   path added with "git add -N" yet, so "git grep --cached" should not
   show hits (or show lack of hits, with -L) in such a path, but that
   logic does not apply to "git grep", i.e. searching in the working
   tree files.  But we did so by mistake, which has been corrected.

 * "git rebase -i --autostash" did not restore the auto-stashed change
   when the operation was aborted.

 * "git commit --amend --allow-empty-message -S" for a commit without
   any message body could have misidentified where the header of the
   commit object ends.

 * More mark-up updates to typeset strings that are expected to
   literally typed by the end user in fixed-width font.

 * For a long time, we carried an in-code comment that said our
   colored output would work only when we use fprintf/fputs on
   Windows, which no longer is the case for the past few years.

 * "gc.autoPackLimit" when set to 1 should not trigger a repacking
   when there is only one pack, but the code counted poorly and did
   so.

 * One part of "git am" had an oddball helper function that called
   stuff from outside "his" as opposed to calling what we have "ours",
   which was not gender-neutral and also inconsistent with the rest of
   the system where outside stuff is usuall called "theirs" in
   contrast to "ours".

 * The test framework learned a new helper test_match_signal to
   check an exit code from getting killed by an expected signal.

 * "git blame -M" missed a single line that was moved within the file.

 * Fix recently introduced codepaths that are involved in parallel
   submodule operations, which gave up on reading too early, and
   could have wasted CPU while attempting to write under a corner
   case condition.

 * "git grep -i" has been taught to fold case in non-ascii locales
   correctly.

 * A test that unconditionally used "mktemp" learned that the command
   is not necessarily available everywhere.

 * "git blame file" allowed the lineage of lines in the uncommitted,
   unadded contents of "file" to be inspected, but it refused when
   "file" did not appear in the current commit.  When "file" was
   created by renaming an existing file (but the change has not been
   committed), this restriction was unnecessarily tight.

 * "git add -N dir/file && git write-tree" produced an incorrect tree
   when there are other paths in the same directory that sorts after
   "file".

 * "git fetch http://user:pass@host/repo...; scrubbed the userinfo
   part, but "git push" didn't.

 * An age old bug that caused "git diff --ignore-space-at-eol"
   misbehave has been fixed.

 * "git notes merge" had a code to see if a path exists (and fails if
   it does) and then open the path for writing (when it doesn't).
   Replace it with open with O_EXCL.

 * "git pack-objects" and "git index-pack" mostly operate with off_t
   when talking about the offset of objects in a packfile, but there
   were a handful of places that used "unsigned long" to hold that
   value, leading to an unintended truncation.

 * Recent update to "git daemon" tries to enable the socket-level
   KEEPALIVE, but when it is spawned via inetd, the standard input
   file descriptor may not necessarily be connected to a socket.
   Suppress an ENOTSOCK error from setsockopt().

 * Recent FreeBSD stopped making perl available at /usr/bin/perl;
   switch the default the built-in path to /usr/local/bin/perl on not
   too ancient FreeBSD releases.

 * "git status" learned to suggest "merge --abort" during a conflicted
   merge, just like it already suggests "rebase --abort" during a
   conflicted rebase.

 * The .c/.h sources are marked as such in our .gitattributes file so
   that "git diff -W" and friends would work better.

 * Existing autoconf generated test for the need to link with pthread
   library did not check all the functions from pthread libraries;
   recent FreeBSD has some functions in libc but not others, and we
   mistakenly thought linking with libc is enough when it is not.

 * Allow http daemon 

Re: [PATCH v12 13/13] bisect--helper: `bisect_start` shell function partially in C

[Junio C Hamano]

Pranit Bauva  writes:

> + ...
> + /*
> +  * Write new start state
> +  */
> + if (write_file(git_path_bisect_start(), "%s\n", start_head.buf)) {

I think this function has changed its signature recently.  I am
planning to tag 2.10-rc0 this weekend, and it may be a good time to
rebase the series on to an updated codebase.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 04/13] bisect--helper: `bisect_clean_state` shell function in C

[Junio C Hamano]

Pranit Bauva  writes:

> +static int bisect_clean_state(void)
> +{
> + int result = 0;
> +
> + /* There may be some refs packed during bisection */
> + struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
> + for_each_ref_in("refs/bisect/", mark_for_removal, (void *) 
> _for_removal);
> + string_list_append(_for_removal, xstrdup("BISECT_HEAD"));
> + result = delete_refs(_for_removal);

I think this function has changed its signature recently.  I am
planning to tag 2.10-rc0 this weekend, and it may be a good time to
rebase the series on to an updated codebase.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 00/12] Update git revisions

[Philip Oakley]

From: "Marc Branchaud" 

On 2016-08-12 03:07 AM, Philip Oakley wrote:

[2nd attempt : ISP troubles]

This has grown like topsy from a little two patch series that tried to
name the 2-dots notation [1] into this extended set of tweaks.


Honestly, I start just trying point out something concrete, like 
misrendered headers, but then I figure since I'm sending a review comment 
anyway I might as well go in-depth on the rest of the patch.


I think I'm sticking to substantive comments, but if I'm getting too picky 
please just swat me down!


No, that's fine. It's important to at least review these points.

I thought I'd picked up all the issues, but it looks like I missed at least 
one.


The caret thing has a bit of history - see 87c6aeb4efdd43559

It looks like its the two carets on a line mean superscript (Unconstrained 
quotes) and that maybe the issue.


Then it looks like {caret} does a replacement, though I can't find that in 
the asciidoc user guide.



I don't quite understand why the ^ symbols work for the Loliger examples, 
but hey ho, it's good they do...


I'll work on the tweaks, though it'll probably be tomorrow as we have 
visitors.


--
Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 11/13] bisect--helper: `bisect_next_check` & bisect_voc shell function in C

[Junio C Hamano]

Junio C Hamano  writes:

> Pranit Bauva  writes:
>
>> +static int bisect_next_check(const struct bisect_terms *terms,
>> + const char *current_term)
>> +{
>> + 
>> +fprintf(stderr, N_("Warning: bisecting only with a %s 
>> commit\n"),
>> +terms->term_bad.buf);
>
> Hmph, is this N_() and not _()?

I recall you saying that you are not familiar with i18n.  As it is a
good skill to have outside the context of this project, let's do a
quick primer. GSoC is a learning experience ;-).

There is a runtime function "gettext()" that takes a string, which
is typically a printf format string, and gives another string.  You
feed your message in the original language, meant to be used in the
C locale, and the function gives it translated into the end-user's
language, specified by environment variables like $LC_MESSAGES.

Since it is too cumbersome to write gettext() all the time, _()
exists as a short-hand for it.  So running this

printf(_("Hello, world\n"));

would look up "Hello world\n" in database for the end-user's
language, and shows the translated message instead.

By scanning the source text, you can extract these constant strings
passed to gettext() or _().  This is done by the i18n coordinator
with the "msgmerge" program.  By doing so, we learn "Hello, world\n"
must be translated, and then ask i18n team to translate it to their
language.  The result is what we have in the l10n database.  They
are in po/*.po files in our source tree.

Sometimes, the message you want to be translated may be in a
variable, e.g.

void greeting(const char *message)
{
printf(_(message));
}

int main(int ac, char **av)
{
int i;
const char *message[] = {
"Hello, world\n",
"Goodbye, everybody\n",
};
for (i = 0; i < ARRAY_SIZE(message); i++)
greeting(message[i]);
}

And scanning the source would not find "Hello, world\n" or "Goodby,
everybody\n" must be translated.  We do not want to do this:

...
const char *message[] = {
*BAD*   _("Hello, world\n"),
*BAD*   _("Goodbye, everybody\n"),
};
...

because we do *NOT* want to call gettext() there (we call the
function at runtime inside greeting() instead).  We use N_()
to mark such messages, like so:

...
const char *message[] = {
*GOOD*  N_("Hello, world\n"),
*GOOD*  N_("Goodbye, everybody\n"),
};
...

The N_() macro is a no-op at runtime.  It just is there so that
"msgmerge" can notice that the constant string there is something
that needs to be thrown into the l10n database.

As a concrete example:

> @@ -24,6 +25,7 @@ static const char * const git_bisect_helper_usage[] = {
>   N_("git bisect--helper --bisect-reset []"),
>   N_("git bisect--helper --bisect-write
>  []"),
>   N_("git bisect--helper --bisect-check-and-set-terms  
>  "),
> + N_("git bisect--helper --bisect-next-check []  
>    NULL
>  };

this is such a use of N_().  You want to keep untranslated message
in the git_bisect_helper_usage[] array, to be given to gettext(), or
more likely its short-hand _(), when these usage strings are used,
and make sure these strings will be in the l10n database so that
translators will give you translations to them to be used at
runtime.

> + /*
> +  * have bad (or new) but not good (or old). We could bisect
> +  * although this is less optimum.
> +  */
> + fprintf(stderr, N_("Warning: bisecting only with a %s 
> commit\n"),
> + terms->term_bad.buf);

This one wants to call gettext() function to give fprintf() the
translated warning message.  It should be _().

> + /*
> +  * TRANSLATORS: Make sure to include [Y] and [n] in your
> +  * translation. The program will only accept English input
> +  * at this point.
> +  */
> + yesno = git_prompt(_("Are you sure [Y/n]? "), PROMPT_ECHO);

Just like this one.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-subtree: compare file names by absolute paths

[Junio C Hamano]

Ivan Oleynikov  writes:

> Cc: git@vger.kernel.org,  d...@metrotek.spb.ru,  apenw...@gmail.com

I think Avery no longer actively works on this script; Dave Greene
has been helping it move forward by reviewing, so let's ask him to
lend his eyes.

> This commit removes false positive assertion fails of `git subtree split` when
> the --prefix argument is not in a particular form produced by `git ls-tree`.
>
> For example, typical usage of the command could be:
>
>   git subtree split -b split --prefix=some/relative/path
>
> But
>
>   git subtree split -b split --prefix=./some/relative/path
>
> Would fail with multiple assertion errors. This commit makes the latter 
> command
> work without errors.
>
> Signed-off-by: Ivan Oleynikov 
> ---
>
> Notes:
> The bug fixed by this commit can be reproduced like this:
> 
> $ git init
> Initialized empty Git repository in /tmp/test/.git/
> $ mkdir a b
> $ touch a/file b/file
> $ git add a
> $ git commit -m a
> [master (root-commit) b42584a] a
>  1 file changed, 0 insertions($), 0 deletions(-)
>  create mode 100644 a/file
> $ git add b
> $ git commit -m b
> [master 5114301] b
>  1 file changed, 0 insertions($), 0 deletions(-)
>  create mode 100644 b/file
> $ git subtree split -b split_a --prefix=a
> Created branch 'split_a'
> e9f5d81efacb33ab6cf67fe9ff376b33a483a92f
> $ git subtree split -b split_b --prefix=./b
> assertion failed:  [ b = ./b ]
> No new revisions were found
> 
> When the commit is applied `git subtree split` works as expected:
> 
> $ git init
> Initialized empty Git repository in /tmp/test/.git/
> $ mkdir a b
> $ touch a/file b/file
> $ git add a
> $ git commit -m a
> [master (root-commit) bc80f36] a
>  1 file changed, 0 insertions($), 0 deletions(-)
>  create mode 100644 a/file
> $ git add b
> $ git commit -m b
> [master e59c446] b
>  1 file changed, 0 insertions($), 0 deletions(-)
>  create mode 100644 b/file
> $ git subtree split -b split_a --prefix=a
> Created branch 'split_a'
> d542e9cd2de5956dd7ca77b169dba1c8418fa03a
> $ git subtree split -b split_b --prefix=./b
> Created branch 'split_b'
> 3ae7854c0c395413c807b2bc4e75b651adc63f8c
>
>  contrib/subtree/git-subtree.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index b567eae..d9351b9 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -411,7 +411,7 @@ subtree_for_commit()
>   dir="$2"
>   git ls-tree "$commit" -- "$dir" |
>   while read mode type tree name; do
> - assert [ "$name" = "$dir" ]
> + assert [ "$(readlink -f $name)" = "$(readlink -f $dir)" ]
>   assert [ "$type" = "tree" -o "$type" = "commit" ]
>   [ "$type" = "commit" ] && continue  # ignore submodules
>   echo $tree
> -- 
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git stash --help` tries to pull up nonexistent file gitstack.html

[Jacob Keller]

On Fri, Aug 12, 2016 at 9:25 AM, Junio C Hamano  wrote:
> On Fri, Aug 12, 2016 at 9:15 AM, Joseph Musser  wrote:
>> Oh, I'm embarrassed. The typo was mine, I must have typed `git stack
>> --help`. I would have expected a syntax error message or "did you
>> mean" suggestions; it didn't even enter my mind that it would look up
>> whatever I typed before --help and assume it existed on disk.
>
> I actually think you found an interesting (albeit minor) bug.
> I think whenever "git" sees any word followed by "--help" and nothing else,
> it blindly turns it into "git help" followed by that word. I think it
> is reasonable
> to expect that "git foo --help" responds with "foo: no such subcommand",
> instead of "No manual entry for gitfoo".
>
> It may not be too hard to arrange; this might be another low-hanging
> fruit if somebody wants to try a patch ;-)
>

What about extension subcommands that aren't core? Wouldn't we prefer
if it still tried to find help for those also? Just a thought to add
to this.

Thanks,
Jake
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 11/13] bisect--helper: `bisect_next_check` & bisect_voc shell function in C

[Junio C Hamano]

Pranit Bauva  writes:

> +static char *bisect_voc(char *revision_type)
> +{
> + if (!strcmp(revision_type, "bad"))
> + return "bad|new";
> + if (!strcmp(revision_type, "good"))
> + return "good|old";
> +
> + return NULL;
> +}

I think you can return "const char *" from the above function.  Then
you do not have to do xstrdup() on the return values to store in
bad_syn and good_syn, and you do not have to free(3) them.

> +static int bisect_next_check(const struct bisect_terms *terms,
> +  const char *current_term)
> +{
> + 
> + fprintf(stderr, N_("Warning: bisecting only with a %s 
> commit\n"),
> + terms->term_bad.buf);

Hmph, is this N_() and not _()?

> + 
> + }
> + bad_syn = xstrdup(bisect_voc("bad"));
> + good_syn = xstrdup(bisect_voc("good"));
> + 
> + free(bad_syn);
> + free(good_syn);

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Junio C Hamano]

Lars Schneider  writes:

>> Unless the reasoning is "an error in between is so rare that we are
>> OK if the protocol misbehaves and the receiving end omits error
>> handing", I am not so sure how "therefore additional work is OK" is
>> a reasonable conclusion.
>
> Maybe I need to reword. An error is detected in either way if something
> goes wrong. The advantage of the two step status is that if we fail early
> then Git does not even need to create structures to read the response.

OK, that's much better.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] t0027: Correct raciness in NNO test

[Junio C Hamano]

tbo...@web.de writes:

> From: Torsten Bögershausen 
>
> When a non-reversible CRLF conversion is done in "git add",
> a warning is printed on stderr (or Git dies, depending on checksafe)
>
> The function commit_chk_wrnNNO() in t0027 was written to test this,
> but did the wrong thing: Instead of looking at the warning
> from "git add", it looked at the warning from "git commit".
>
> This is racy because "git commit" may not have to do CRLF conversion
> at all if it can use the sha1 value from the index (which depends on
> whether "add" and "commit" run in a single second).
>
> Correct this and replace the commit for each and every file with a commit
> of all files in one go.
>
> The function commit_chk_wrnNNO() will to be renamed in a separate commit.
> Thanks to Jeff King  for analyzing t0027.
>
> Reported-By: Johannes Schindelin 
> ---

Missing sign-off.  The reasoning above looks very clearly explained.

Thanks.


>  t/t0027-auto-crlf.sh | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
> index 2860d2d..ab6e962 100755
> --- a/t/t0027-auto-crlf.sh
> +++ b/t/t0027-auto-crlf.sh
> @@ -119,8 +119,7 @@ commit_chk_wrnNNO () {
>   fname=${pfx}_$f.txt &&
>   cp $f $fname &&
>   printf Z >>"$fname" &&
> - git -c core.autocrlf=$crlf add $fname 2>/dev/null &&
> - git -c core.autocrlf=$crlf commit -m "commit_$fname" $fname 
> >"${pfx}_$f.err" 2>&1
> + git -c core.autocrlf=$crlf add $fname 2>"${pfx}_$f.err"
>   done
>  
>   test_expect_success "commit NNO files crlf=$crlf attr=$attr LF" '
> @@ -394,11 +393,11 @@ test_expect_success 'commit files attr=crlf' '
>  
>  # attrLFCRLF  CRLFmixLF   
> LF_mix_CR   CRLFNUL
>  commit_chk_wrnNNO ""  ""  false   """"""  "" 
>  ""
> -commit_chk_wrnNNO ""  ""  trueLF_CRLF   """"  "" 
>  ""
> +commit_chk_wrnNNO ""  ""  true""""""  "" 
>  ""
>  commit_chk_wrnNNO ""  ""  input   """"""  "" 
>  ""
>  
> -commit_chk_wrnNNO "auto"  ""  false   "$WILC"   """"  "" 
>  ""
> -commit_chk_wrnNNO "auto"  ""  trueLF_CRLF   """"  "" 
>  ""
> +commit_chk_wrnNNO "auto"  ""  false   """"""  "" 
>  ""
> +commit_chk_wrnNNO "auto"  ""  true""""""  "" 
>  ""
>  commit_chk_wrnNNO "auto"  ""  input   """"""  "" 
>  ""
>  for crlf in true false input
>  do
> @@ -408,7 +407,7 @@ do
>   commit_chk_wrnNNO ""lf  $crlf   ""   CRLF_LFCRLF_LF 
>  "" CRLF_LF
>   commit_chk_wrnNNO ""crlf$crlf   LF_CRLF   ""LF_CRLF 
> LF_CRLF ""
>   commit_chk_wrnNNO auto  lf  $crlf   """"""  
> ""  ""
> - commit_chk_wrnNNO auto  crlf$crlf   LF_CRLF   """"  
> ""  ""
> + commit_chk_wrnNNO auto  crlf$crlf   """"""  
> ""  ""
>   commit_chk_wrnNNO text  lf  $crlf   ""   CRLF_LFCRLF_LF 
> ""  CRLF_LF
>   commit_chk_wrnNNO text  crlf$crlf   LF_CRLF   ""LF_CRLF 
> LF_CRLF ""
>  done
> @@ -417,7 +416,8 @@ commit_chk_wrnNNO "text"  ""  false   "$WILC"   
> "$WICL"   "$WAMIX""$WILC
>  commit_chk_wrnNNO "text"  ""  trueLF_CRLF   ""LF_CRLF 
> LF_CRLF ""
>  commit_chk_wrnNNO "text"  ""  input   ""CRLF_LF   CRLF_LF "" 
>  CRLF_LF
>  
> -test_expect_success 'create files cleanup' '
> +test_expect_success 'commit NNO and cleanup' '
> + git commit -m "commit files on top of NNO" &&
>   rm -f *.txt &&
>   git -c core.autocrlf=false reset --hard
>  '
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 2/2] convert: missing `LF will be replaced by CRLF

[Junio C Hamano]

tbo...@web.de writes:

> From: Torsten Bögershausen 
>
> When the "new safer autocrlf-handling" was introduced in c4805393, the logic
> around check_safe_crlf() should have been changed:

Should have been changed from what to what?  And instead it was
changed to which other logic?  What is the difference between the
ideal this change tries to bring in and what c4805393 did?

> Once a file has been commited with CRLF (and core.autocrlf is true),
> line endings are no longer converted by "git add" or "git checkout".
> The line endings will not normalized by Git.

s/will not/& be/;

> The user may run e.g. dos2unix and commit the file.

It is unclear what this sentence wants to say.  The user may overwrite
the file with random contents and commit it, too.  So what?

What is missing from this statement is what problem is being worked
around.  Do you mean: "Because Git does not normalize once CRLF is
in the index, if the user wants to have a normalized content in the
repository to correct that mistake, the user needs to do dos2unix to
fix it and commit the fixed result"?

> Factor out will_convert_lf_to_crlf() which returns when LF are converted
> into CRLF at checkout.
>
> Update the logic around check_safe_crlf() and do the possible CRLF-LF
> conversion in "git add".
> Simulate the checkout (and a possible LF-CRLF conversion) with help of
> will_convert_lf_to_crlf().

These two paragraphs are all "what I did to solve X", but what X is
is not very clear.

> ---

Missing sign-off.

>  convert.c| 97 
> ++--
>  t/t0027-auto-crlf.sh |  6 ++--
>  2 files changed, 60 insertions(+), 43 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 67d69b5..077f5e6 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -189,33 +189,25 @@ static enum eol output_eol(enum crlf_action crlf_action)
>  }
>  
>  static void check_safe_crlf(const char *path, enum crlf_action crlf_action,
> -struct text_stat *stats, enum safe_crlf 
> checksafe)
> + struct text_stat *old_stats, struct text_stat 
> *new_stats,
> + enum safe_crlf checksafe)
>  {
> - if (!checksafe)
> - return;
> -
> - if (output_eol(crlf_action) == EOL_LF) {
> + if (old_stats->crlf && !new_stats->crlf ) {

Space before ")"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-subtree: compare file names by absolute paths

[Ivan Oleynikov]

quote on Fri, Aug 12, 2016 at 06:49:42PM +0300 (Ivan Oleynikov):

BTW, this patch should be applied to `maint` branch. The similar change also
works if applied to master (patch for master must be a bit different).

-- 
Ivan Oleynikov
STC Metrotek
St.Petersburg
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Lars Schneider]

> On 12 Aug 2016, at 19:13, Junio C Hamano  wrote:
> 
> Lars Schneider  writes:
> 
>>> If we do the success first and then error out halfway, we
>>> still have to clean up, so I do not see how this impacts
>>> implementation?
>> 
>> That is true. The reasoning is that an error in between is somewhat
>> less expected. Therefore additional work is OK.
>> 
>> An error upfront is much more likely because it is also a mechanism
>> for the filter to reject certain files. If the filter is configured
>> as "required=false" then this reject would actually be OK.
> 
> Unless the reasoning is "an error in between is so rare that we are
> OK if the protocol misbehaves and the receiving end omits error
> handing", I am not so sure how "therefore additional work is OK" is
> a reasonable conclusion.

Maybe I need to reword. An error is detected in either way if something
goes wrong. The advantage of the two step status is that if we fail early
then Git does not even need to create structures to read the response.

See Peff's answer here:
http://public-inbox.org/git/20160806121421.bs7n4lhed7phdshb%40sigill.intra.peff.net/
http://public-inbox.org/git/20160805222710.chefh5kiktyzketh%40sigill.intra.peff.net/

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Lars Schneider]

> On 12 Aug 2016, at 19:07, Stefan Beller  wrote:
> 
> On Fri, Aug 12, 2016 at 9:59 AM, Lars Schneider
>  wrote:
>> 
>> The welcome message is necessary to distinguish the long running
>> filter protocol (v2) from the current one-shot filter protocol (v1).
>> This is becomes important if a users tries to use a v1 clean/smudge
>> filter with the v2 git config settings.
> 
> Oh I see, that's why we're at v2 now.
> How do you distinguish between v1 and v2? Does the welcome message
> need to follow a certain pattern to be recognized to make it v2+ ?

v1 has no format at all. It works like this:

1. Git starts the filter process
2. Git writes the entire file via stdin to the filter process
3. Git reads the result via stdout from the filter process
3. Git stops the filter process


Any v2+ would need to deal with the following:

packet:  git> git-filter-client
packet:  git> version=2
packet:  git> version=2+
packet:  git> 
packet:  git< git-filter-server

Everything after could be different in v2+ compared to v2.

Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Junio C Hamano]

Lars Schneider  writes:

>> If we do the success first and then error out halfway, we
>> still have to clean up, so I do not see how this impacts
>> implementation?
>
> That is true. The reasoning is that an error in between is somewhat
> less expected. Therefore additional work is OK.
>
> An error upfront is much more likely because it is also a mechanism
> for the filter to reject certain files. If the filter is configured
> as "required=false" then this reject would actually be OK.

Unless the reasoning is "an error in between is so rare that we are
OK if the protocol misbehaves and the receiving end omits error
handing", I am not so sure how "therefore additional work is OK" is
a reasonable conclusion.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Lars Schneider]

> On 12 Aug 2016, at 18:48, Stefan Beller  wrote:
> 
> On Fri, Aug 12, 2016 at 9:38 AM, Jeff King  wrote:
>> On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:
>> 
 If the result content is empty then the filter is expected to respond
 with a success status and an empty list.
 
 packet:  git< status=success\n
 packet:  git< 
 packet:  git<   # empty content!
 packet:  git<   # empty list!
 
>>> 
>>> Why do we need the last flush packet? We'd expect as many successes
>>> as we send out contents? Do we plan on interleaving operation, i.e.
>>> Git sends out 10 files but the filter process is not as fast as Git sending
>>> out and the answers trickle in slowly?
>> 
>> There was prior discussion in the thread, but basically, it is there to
>> be able to signal an error that is encountered midway through sending
>> the file (i.e., to say "status=error"). If you do not have a final
>> flush, then you would send nothing, and the receiver would be left
>> wondering if you were successful, or if it simply did not get your error
>> report yet.
> 
>I did not follow the prior discussion, so I approached this review with
>no prior knowledge from prior reviews, but instead read through and
>was asking a lot of questions that came up immediately. In case my
>questions are too dumb just omit them, but I thought they were good
>material to answer in a commit message ("Why did we do it this way
>and not differently").

Thanks! That's very helpful and I will address your questions in the commit
message as anyone looking at this commit in the future will have no prior 
knowledge, too.


> Thanks for the explanation. So this is similar as the situation below
> that we wait for the flush and then an error/success report?

Correct. If we would just process the status packet then we wouldn't
even need to wait for the flush. I added flush because that allows us
to send an arbitrary list of key=value pairs in the future.


 If the filter experiences an error during processing, then it can
 send the status "error". Depending on the `filter..required`
 flag Git will interpret that as error but it will not stop or restart
 the filter process.
 
 packet:  git< status=success\n
>>> 
>>> So the first success is meaningless essentially?
>>> Would it make sense to move the sucess behind the content sending
>>> in all cases?
>> 
>> No, the first success says "good so far, here's the file content". The
>> second says "I succeeded in sending you the file content".
>> 
>> You _can_ drop the first one, but it may be more convenient for the
>> receiver to know up-front that there was a failure.
> 
> 
> If there was a failure upfront, it would become
> 
> packet:  git< 
> # no content is encapsulated here
> packet:  git< 
> packet:  git< status=error\n
> packet:  git< 

No, a failure upfront would look like this (see documentation):


packet:  git< status=error\n
packet:  git< 


No content and no 2nd key=value pair list is exchanged after an error.



> so from a protocol side I'd claim it doesn't look bad.
> I assume with convenient you mean the implementation
> side of things?
> 
> If we do the success first and then error out halfway, we
> still have to clean up, so I do not see how this impacts
> implementation?

That is true. The reasoning is that an error in between is somewhat
less expected. Therefore additional work is OK.

An error upfront is much more likely because it is also a mechanism
for the filter to reject certain files. If the filter is configured
as "required=false" then this reject would actually be OK.

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Stefan Beller]

On Fri, Aug 12, 2016 at 9:59 AM, Lars Schneider
 wrote:
>
> The welcome message is necessary to distinguish the long running
> filter protocol (v2) from the current one-shot filter protocol (v1).
> This is becomes important if a users tries to use a v1 clean/smudge
> filter with the v2 git config settings.

Oh I see, that's why we're at v2 now.
How do you distinguish between v1 and v2? Does the welcome message
need to follow a certain pattern to be recognized to make it v2+ ?

>
> Thanks a lot for the review,
> Lars

Sorry for repeating the questions (it seems I missed
a lot of the prior discussion), but I think these questions
may help future readers of the commit message,

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Lars Schneider]

> On 12 Aug 2016, at 18:33, Stefan Beller  wrote:
> 
> On Wed, Aug 10, 2016 at 6:04 AM,   wrote:
>> From: Lars Schneider 
>> 
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected by a filter. If Git filters a lot of blobs
>> then the startup time of the external filter processes can become a
>> significant part of the overall Git execution time.
>> 
>> In a preliminary performance test this developer used a clean/smudge filter
>> written in golang to filter 12,000 files. This process took 364s with the
>> existing filter mechanism and 5s with the new mechanism. See details here:
>> https://github.com/github/git-lfs/pull/1382
>> 
>> This patch adds the `filter..process` string option which, if used,
>> keeps the external filter process running and processes all blobs with
>> the packet format (pkt-line) based protocol over standard input and standard
>> output described below.
>> 
>> Git starts the filter when it encounters the first file
>> that needs to be cleaned or smudged. After the filter started
>> Git sends a welcome message, a list of supported protocol
>> version numbers, and a flush packet. Git expects to read the
>> welcome message and one protocol version number from the
>> previously sent list. Afterwards Git sends a list of supported
>> capabilities and a flush packet. Git expects to read a list of
>> desired capabilities, which must be a subset of the supported
>> capabilities list, and a flush packet as response:
>> 
>> packet:  git> git-filter-client
>> packet:  git> version=2
>> packet:  git> version=42
>> packet:  git> 
>> packet:  git< git-filter-server
>> packet:  git< version=2
> 
> what follows is specific to version=2?
> version 42 may deem capabilities a bad idea?

"version=42" is just an example to show how the initialization could look
like in a distant future when we support even another protocol version.

You are correct, what follows is specific to version=2. I will state
that more clearly in the documentation.

Can you try to rephrase "version 42 may deem capabilities a bad idea?"
I am not sure I understand what you mean.


> 
>> packet:  git> clean=true
>> packet:  git> smudge=true
>> packet:  git> not-yet-invented=true
>> packet:  git> 
>> packet:  git< clean=true
>> packet:  git< smudge=true
>> packet:  git< 
>> 
>> Supported filter capabilities in version 2 are "clean" and
>> "smudge".
> 
> I assume version 2 is an example here and we actually start with v1?

No, it is actually called version 2 because I consider the current
clean/smudge protocol version 1.


> Can you clarify why we need welcome messages?
> (Is there a technical reason, or better debuggability for humans?)

The welcome message is necessary to distinguish the long running
filter protocol (v2) from the current one-shot filter protocol (v1).
This is becomes important if a users tries to use a v1 clean/smudge
filter with the v2 git config settings.


>> Afterwards Git sends a list of "key=value" pairs terminated with
>> a flush packet. The list will contain at least the filter command
>> (based on the supported capabilities) and the pathname of the file
>> to filter relative to the repository root. Right after these packets
>> Git sends the content split in zero or more pkt-line packets and a
>> flush packet to terminate content.
>> 
>> packet:  git> command=smudge\n
>> packet:  git> pathname=path/testfile.dat\n
>> packet:  git> 
>> packet:  git> CONTENT
>> packet:  git> 
>> 
>> 
>> The filter is expected to respond with a list of "key=value" pairs
>> terminated with a flush packet. If the filter does not experience
>> problems then the list must contain a "success" status. Right after
>> these packets the filter is expected to send the content in zero
>> or more pkt-line packets and a flush packet at the end. Finally, a
>> second list of "key=value" pairs terminated with a flush packet
>> is expected. The filter can change the status in the second list.
>> 
>> packet:  git< status=success\n
>> packet:  git< 
>> packet:  git< SMUDGED_CONTENT
>> packet:  git< 
>> packet:  git<   # empty list!
>> 
>> 
>> If the result content is empty then the filter is expected to respond
>> with a success status and an empty list.
>> 
>> packet:  git< status=success\n
>> packet:  git< 
>> packet:  git<   # empty content!
>> packet:  git<   # empty list!
>> 
> 
> Why do we need the last flush packet? We'd expect as many successes
> as we send out 

Re: [PATCH v5 14/15] convert: add filter..process option

[Stefan Beller]

On Fri, Aug 12, 2016 at 9:38 AM, Jeff King  wrote:
> On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:
>
>> > If the result content is empty then the filter is expected to respond
>> > with a success status and an empty list.
>> > 
>> > packet:  git< status=success\n
>> > packet:  git< 
>> > packet:  git<   # empty content!
>> > packet:  git<   # empty list!
>> > 
>>
>> Why do we need the last flush packet? We'd expect as many successes
>> as we send out contents? Do we plan on interleaving operation, i.e.
>> Git sends out 10 files but the filter process is not as fast as Git sending
>> out and the answers trickle in slowly?
>
> There was prior discussion in the thread, but basically, it is there to
> be able to signal an error that is encountered midway through sending
> the file (i.e., to say "status=error"). If you do not have a final
> flush, then you would send nothing, and the receiver would be left
> wondering if you were successful, or if it simply did not get your error
> report yet.

I did not follow the prior discussion, so I approached this review with
no prior knowledge from prior reviews, but instead read through and
was asking a lot of questions that came up immediately. In case my
questions are too dumb just omit them, but I thought they were good
material to answer in a commit message ("Why did we do it this way
and not differently").

Thanks for the explanation. So this is similar as the situation below
that we wait for the flush and then an error/success report?

>
>> > If the filter experiences an error during processing, then it can
>> > send the status "error". Depending on the `filter..required`
>> > flag Git will interpret that as error but it will not stop or restart
>> > the filter process.
>> > 
>> > packet:  git< status=success\n
>>
>> So the first success is meaningless essentially?
>> Would it make sense to move the sucess behind the content sending
>> in all cases?
>
> No, the first success says "good so far, here's the file content". The
> second says "I succeeded in sending you the file content".
>
> You _can_ drop the first one, but it may be more convenient for the
> receiver to know up-front that there was a failure.


If there was a failure upfront, it would become

packet:  git< 
# no content is encapsulated here
packet:  git< 
packet:  git< status=error\n
packet:  git< 

so from a protocol side I'd claim it doesn't look bad.
I assume with convenient you mean the implementation
side of things?

If we do the success first and then error out halfway, we
still have to clean up, so I do not see how this impacts
implementation?

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/2] t0027: Correct raciness in NNO test

[tboegi]

From: Torsten Bögershausen 

When a non-reversible CRLF conversion is done in "git add",
a warning is printed on stderr (or Git dies, depending on checksafe)

The function commit_chk_wrnNNO() in t0027 was written to test this,
but did the wrong thing: Instead of looking at the warning
from "git add", it looked at the warning from "git commit".

This is racy because "git commit" may not have to do CRLF conversion
at all if it can use the sha1 value from the index (which depends on
whether "add" and "commit" run in a single second).

Correct this and replace the commit for each and every file with a commit
of all files in one go.

The function commit_chk_wrnNNO() will to be renamed in a separate commit.
Thanks to Jeff King  for analyzing t0027.

Reported-By: Johannes Schindelin 
---
 t/t0027-auto-crlf.sh | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 2860d2d..ab6e962 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -119,8 +119,7 @@ commit_chk_wrnNNO () {
fname=${pfx}_$f.txt &&
cp $f $fname &&
printf Z >>"$fname" &&
-   git -c core.autocrlf=$crlf add $fname 2>/dev/null &&
-   git -c core.autocrlf=$crlf commit -m "commit_$fname" $fname 
>"${pfx}_$f.err" 2>&1
+   git -c core.autocrlf=$crlf add $fname 2>"${pfx}_$f.err"
done
 
test_expect_success "commit NNO files crlf=$crlf attr=$attr LF" '
@@ -394,11 +393,11 @@ test_expect_success 'commit files attr=crlf' '
 
 # attrLFCRLF  CRLFmixLF   
LF_mix_CR   CRLFNUL
 commit_chk_wrnNNO ""  ""  false   """"""  ""   
   ""
-commit_chk_wrnNNO ""  ""  trueLF_CRLF   """"  ""   
   ""
+commit_chk_wrnNNO ""  ""  true""""""  ""   
   ""
 commit_chk_wrnNNO ""  ""  input   """"""  ""   
   ""
 
-commit_chk_wrnNNO "auto"  ""  false   "$WILC"   """"  ""   
   ""
-commit_chk_wrnNNO "auto"  ""  trueLF_CRLF   """"  ""   
   ""
+commit_chk_wrnNNO "auto"  ""  false   """"""  ""   
   ""
+commit_chk_wrnNNO "auto"  ""  true""""""  ""   
   ""
 commit_chk_wrnNNO "auto"  ""  input   """"""  ""   
   ""
 for crlf in true false input
 do
@@ -408,7 +407,7 @@ do
commit_chk_wrnNNO ""lf  $crlf   ""   CRLF_LFCRLF_LF 
 "" CRLF_LF
commit_chk_wrnNNO ""crlf$crlf   LF_CRLF   ""LF_CRLF 
LF_CRLF ""
commit_chk_wrnNNO auto  lf  $crlf   """"""  
""  ""
-   commit_chk_wrnNNO auto  crlf$crlf   LF_CRLF   """"  
""  ""
+   commit_chk_wrnNNO auto  crlf$crlf   """"""  
""  ""
commit_chk_wrnNNO text  lf  $crlf   ""   CRLF_LFCRLF_LF 
""  CRLF_LF
commit_chk_wrnNNO text  crlf$crlf   LF_CRLF   ""LF_CRLF 
LF_CRLF ""
 done
@@ -417,7 +416,8 @@ commit_chk_wrnNNO "text"  ""  false   "$WILC"   "$WICL" 
  "$WAMIX""$WILC
 commit_chk_wrnNNO "text"  ""  trueLF_CRLF   ""LF_CRLF 
LF_CRLF ""
 commit_chk_wrnNNO "text"  ""  input   ""CRLF_LF   CRLF_LF ""   
   CRLF_LF
 
-test_expect_success 'create files cleanup' '
+test_expect_success 'commit NNO and cleanup' '
+   git commit -m "commit files on top of NNO" &&
rm -f *.txt &&
git -c core.autocrlf=false reset --hard
 '
-- 
2.0.0.rc1.6318.g0c2c796

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 2/2] convert: missing `LF will be replaced by CRLF

[tboegi]

From: Torsten Bögershausen 

When the "new safer autocrlf-handling" was introduced in c4805393, the logic
around check_safe_crlf() should have been changed:
Once a file has been commited with CRLF (and core.autocrlf is true),
line endings are no longer converted by "git add" or "git checkout".
The line endings will not normalized by Git.
The user may run e.g. dos2unix and commit the file.

Factor out will_convert_lf_to_crlf() which returns when LF are converted
into CRLF at checkout.

Update the logic around check_safe_crlf() and do the possible CRLF-LF
conversion in "git add".
Simulate the checkout (and a possible LF-CRLF conversion) with help of
will_convert_lf_to_crlf().
---
 convert.c| 97 ++--
 t/t0027-auto-crlf.sh |  6 ++--
 2 files changed, 60 insertions(+), 43 deletions(-)

diff --git a/convert.c b/convert.c
index 67d69b5..077f5e6 100644
--- a/convert.c
+++ b/convert.c
@@ -189,33 +189,25 @@ static enum eol output_eol(enum crlf_action crlf_action)
 }
 
 static void check_safe_crlf(const char *path, enum crlf_action crlf_action,
-struct text_stat *stats, enum safe_crlf checksafe)
+   struct text_stat *old_stats, struct text_stat 
*new_stats,
+   enum safe_crlf checksafe)
 {
-   if (!checksafe)
-   return;
-
-   if (output_eol(crlf_action) == EOL_LF) {
+   if (old_stats->crlf && !new_stats->crlf ) {
/*
-* CRLFs would not be restored by checkout:
-* check if we'd remove CRLFs
+* CRLFs would not be restored by checkout
 */
-   if (stats->crlf) {
-   if (checksafe == SAFE_CRLF_WARN)
-   warning("CRLF will be replaced by LF in 
%s.\nThe file will have its original line endings in your working directory.", 
path);
-   else /* i.e. SAFE_CRLF_FAIL */
-   die("CRLF would be replaced by LF in %s.", 
path);
-   }
-   } else if (output_eol(crlf_action) == EOL_CRLF) {
+   if (checksafe == SAFE_CRLF_WARN)
+   warning("CRLF will be replaced by LF in %s.\nThe file 
will have its original line endings in your working directory.", path);
+   else /* i.e. SAFE_CRLF_FAIL */
+   die("CRLF would be replaced by LF in %s.", path);
+   } else if (old_stats->lonelf && !new_stats->lonelf ) {
/*
-* CRLFs would be added by checkout:
-* check if we have "naked" LFs
+* CRLFs would be added by checkout
 */
-   if (stats->lonelf) {
-   if (checksafe == SAFE_CRLF_WARN)
-   warning("LF will be replaced by CRLF in 
%s.\nThe file will have its original line endings in your working directory.", 
path);
-   else /* i.e. SAFE_CRLF_FAIL */
-   die("LF would be replaced by CRLF in %s", path);
-   }
+   if (checksafe == SAFE_CRLF_WARN)
+   warning("LF will be replaced by CRLF in %s.\nThe file 
will have its original line endings in your working directory.", path);
+   else /* i.e. SAFE_CRLF_FAIL */
+   die("LF would be replaced by CRLF in %s", path);
}
 }
 
@@ -233,12 +225,35 @@ static int has_cr_in_index(const char *path)
return has_cr;
 }
 
+static int will_convert_lf_to_crlf(size_t len, struct text_stat *stats,
+  enum crlf_action crlf_action)
+{
+   if (output_eol(crlf_action) != EOL_CRLF)
+   return 0;
+   /* No "naked" LF? Nothing to convert, regardless. */
+   if (!stats->lonelf)
+   return 0;
+
+   if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_INPUT || 
crlf_action == CRLF_AUTO_CRLF) {
+   /* If we have any CR or CRLF line endings, we do not touch it */
+   /* This is the new safer autocrlf-handling */
+   if (stats->lonecr || stats->crlf)
+   return 0;
+
+   if (convert_is_binary(len, stats))
+   return 0;
+   }
+   return 1;
+
+}
+
 static int crlf_to_git(const char *path, const char *src, size_t len,
   struct strbuf *buf,
   enum crlf_action crlf_action, enum safe_crlf checksafe)
 {
struct text_stat stats;
char *dst;
+   int convert_crlf_into_lf;
 
if (crlf_action == CRLF_BINARY ||
(src && !len))
@@ -252,6 +267,8 @@ static int crlf_to_git(const char *path, const char *src, 
size_t len,
return 1;
 
gather_stats(src, len, );
+   /* Optimization: No CRLF? Nothing to convert, regardless. */
+   convert_crlf_into_lf = !!stats.crlf;
 

[PATCH v1 0/2] Fix conversion warnings

[tboegi]

From: Torsten Bögershausen 

conversion warnings in convert.c and t0027
- Fix a raciness in t0027
- Fix an older problem with the conversion warnings when a file
  has CRLF in the index, and is now commited with LF.
- Do not yet rename NNO to something different.
  NNO means Not NOrmalized in the index.
  The files are changed and content with different line endings
  are added on top of the existing version.
  A replacement for commit_chk_wrnNNO will be send after these bugfixes.
  The term commit_chk_wrnNNO could be changed to
  NNO_in_repo_add_file_check_warning.
  Would  NNO_addX__chk_wrn be more readable ?
  Or CRLFindex_add_wrn ?

Changes against v0:
- Added raciness comment from Peff, and removed the removal of a line.
Torsten Bögershausen (2):
  t0027: Correct raciness in NNO test
  convert: missing `LF will be replaced by CRLF

 convert.c| 97 ++--
 t/t0027-auto-crlf.sh | 10 +++---
 2 files changed, 62 insertions(+), 45 deletions(-)

-- 
2.0.0.rc1.6318.g0c2c796

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Jeff King]

On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:

> > If the result content is empty then the filter is expected to respond
> > with a success status and an empty list.
> > 
> > packet:  git< status=success\n
> > packet:  git< 
> > packet:  git<   # empty content!
> > packet:  git<   # empty list!
> > 
> 
> Why do we need the last flush packet? We'd expect as many successes
> as we send out contents? Do we plan on interleaving operation, i.e.
> Git sends out 10 files but the filter process is not as fast as Git sending
> out and the answers trickle in slowly?

There was prior discussion in the thread, but basically, it is there to
be able to signal an error that is encountered midway through sending
the file (i.e., to say "status=error"). If you do not have a final
flush, then you would send nothing, and the receiver would be left
wondering if you were successful, or if it simply did not get your error
report yet.

> > If the filter experiences an error during processing, then it can
> > send the status "error". Depending on the `filter..required`
> > flag Git will interpret that as error but it will not stop or restart
> > the filter process.
> > 
> > packet:  git< status=success\n
> 
> So the first success is meaningless essentially?
> Would it make sense to move the sucess behind the content sending
> in all cases?

No, the first success says "good so far, here's the file content". The
second says "I succeeded in sending you the file content".

You _can_ drop the first one, but it may be more convenient for the
receiver to know up-front that there was a failure.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 14/15] convert: add filter..process option

[Stefan Beller]

On Wed, Aug 10, 2016 at 6:04 AM,   wrote:
> From: Lars Schneider 
>
> Git's clean/smudge mechanism invokes an external filter process for every
> single blob that is affected by a filter. If Git filters a lot of blobs
> then the startup time of the external filter processes can become a
> significant part of the overall Git execution time.
>
> In a preliminary performance test this developer used a clean/smudge filter
> written in golang to filter 12,000 files. This process took 364s with the
> existing filter mechanism and 5s with the new mechanism. See details here:
> https://github.com/github/git-lfs/pull/1382
>
> This patch adds the `filter..process` string option which, if used,
> keeps the external filter process running and processes all blobs with
> the packet format (pkt-line) based protocol over standard input and standard
> output described below.
>
> Git starts the filter when it encounters the first file
> that needs to be cleaned or smudged. After the filter started
> Git sends a welcome message, a list of supported protocol
> version numbers, and a flush packet. Git expects to read the
> welcome message and one protocol version number from the
> previously sent list. Afterwards Git sends a list of supported
> capabilities and a flush packet. Git expects to read a list of
> desired capabilities, which must be a subset of the supported
> capabilities list, and a flush packet as response:
> 
> packet:  git> git-filter-client
> packet:  git> version=2
> packet:  git> version=42
> packet:  git> 
> packet:  git< git-filter-server
> packet:  git< version=2

what follows is specific to version=2?
version 42 may deem capabilities a bad idea?

> packet:  git> clean=true
> packet:  git> smudge=true
> packet:  git> not-yet-invented=true
> packet:  git> 
> packet:  git< clean=true
> packet:  git< smudge=true
> packet:  git< 
> 
> Supported filter capabilities in version 2 are "clean" and
> "smudge".

I assume version 2 is an example here and we actually start with v1?

Can you clarify why we need welcome messages?
(Is there a technical reason, or better debuggability for humans?)

>
> Afterwards Git sends a list of "key=value" pairs terminated with
> a flush packet. The list will contain at least the filter command
> (based on the supported capabilities) and the pathname of the file
> to filter relative to the repository root. Right after these packets
> Git sends the content split in zero or more pkt-line packets and a
> flush packet to terminate content.
> 
> packet:  git> command=smudge\n
> packet:  git> pathname=path/testfile.dat\n
> packet:  git> 
> packet:  git> CONTENT
> packet:  git> 
> 
>
> The filter is expected to respond with a list of "key=value" pairs
> terminated with a flush packet. If the filter does not experience
> problems then the list must contain a "success" status. Right after
> these packets the filter is expected to send the content in zero
> or more pkt-line packets and a flush packet at the end. Finally, a
> second list of "key=value" pairs terminated with a flush packet
> is expected. The filter can change the status in the second list.
> 
> packet:  git< status=success\n
> packet:  git< 
> packet:  git< SMUDGED_CONTENT
> packet:  git< 
> packet:  git<   # empty list!
> 
>
> If the result content is empty then the filter is expected to respond
> with a success status and an empty list.
> 
> packet:  git< status=success\n
> packet:  git< 
> packet:  git<   # empty content!
> packet:  git<   # empty list!
> 

Why do we need the last flush packet? We'd expect as many successes
as we send out contents? Do we plan on interleaving operation, i.e.
Git sends out 10 files but the filter process is not as fast as Git sending
out and the answers trickle in slowly?

>
> In case the filter cannot or does not want to process the content,
> it is expected to respond with an "error" status. Depending on the
> `filter..required` flag Git will interpret that as error
> but it will not stop or restart the filter process.
> 
> packet:  git< status=error\n
> packet:  git< 
> 
>
> In case the filter cannot or does not want to process the content
> as well as any future content for the lifetime of the Git process,
> it is expected to respond with an "error-all" status. Depending on
> the `filter..required` flag Git will interpret that as error
> but it will not stop or restart the filter process.
> 
> packet: 

Re: [PATCHv3] checkout: do not mention detach advice for explicit --detach option

[Jeff King]

On Fri, Aug 12, 2016 at 08:51:43AM -0700, Stefan Beller wrote:

> > Hmm. Using "!test_cmp" seems weird to me, just because it would falsely
> > claim success if something else unexpected changes. Our usual method for
> > making sure some particular output does not appear is "test_i18ngrep"
> > with a liberal pattern.
> 
> and I advanced the liberal a bit more. ;)
> So maybe we'd be looking that no 'detached HEAD' occurs?
> 
> test_i18ngrep ! "'detached HEAD'" actual

I was thinking maybe "advice:" to look for any advice, but at this point
we are guessing about what might change in the future.

> I think testing that we do not give out advice (i.e. behave the same as if
> not giving out advice) is best tested to just compare the output to
> the output of "git -c advice.detachedHead=false ...", which is what I do here.
> This seems to be future proof to me no matter how we reword the advice or
> the actual message on checkout?

Yeah, I guess that is reasonable. I thought at first you were comparing
more distinct commands, but if only the one thing is changing, that
seems reasonable.

You may also want to grab stderr, too (I'm actually surprised advice
goes to stdout and not stderr, and that is something that seems
plausible to change in the future).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git stash --help` tries to pull up nonexistent file gitstack.html

[Junio C Hamano]

On Fri, Aug 12, 2016 at 9:15 AM, Joseph Musser  wrote:
> Oh, I'm embarrassed. The typo was mine, I must have typed `git stack
> --help`. I would have expected a syntax error message or "did you
> mean" suggestions; it didn't even enter my mind that it would look up
> whatever I typed before --help and assume it existed on disk.

I actually think you found an interesting (albeit minor) bug.
I think whenever "git" sees any word followed by "--help" and nothing else,
it blindly turns it into "git help" followed by that word. I think it
is reasonable
to expect that "git foo --help" responds with "foo: no such subcommand",
instead of "No manual entry for gitfoo".

It may not be too hard to arrange; this might be another low-hanging
fruit if somebody wants to try a patch ;-)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git stash --help` tries to pull up nonexistent file gitstack.html

[Joseph Musser]

Oh, I'm embarrassed. The typo was mine, I must have typed `git stack
--help`. I would have expected a syntax error message or "did you
mean" suggestions; it didn't even enter my mind that it would look up
whatever I typed before --help and assume it existed on disk.

I'm sorry!

On Fri, Aug 12, 2016 at 12:03 PM, Lars Schneider
 wrote:
>
>> On 12 Aug 2016, at 17:48, Junio C Hamano  wrote:
>>
>> Joseph Musser  writes:
>>
>>> Looks like a simple typo.
>>
>> Unfortunately this does not reproduce to me (built from source on
>> Ubuntu Linux).
>
> I tried it with the latest released version on Windows and OSX (2.9.2)
> and was not able to reproduce it, too.
>
> - Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] checkout: do not mention detach advice for explicit --detach option

[Junio C Hamano]

Stefan Beller  writes:

> When a user asked for a detached HEAD specifically with `--detach`,
> we do not need to give advice on what a detached HEAD state entails as
> we can assume they know what they're getting into as they asked for it.
>
> Signed-off-by: Stefan Beller 
> ---
>
> Thanks for the review!
>
>> Is there a reason for not unsetting `advice.detachedHead` at the
>> end of the test?
>
> done
>
> I did not consider to clean up after myself... what a selfish world!

;-)

Using test_config instead of "git config" would help.

> +test_expect_success 'no advice given for explicit detached head state' '
> + git config advice.detachedHead false &&
> + git checkout child &&
> + git checkout --detach HEAD >expect &&
> + git config advice.detachedHead true &&
> + git checkout child &&
> + git checkout --detach HEAD >actual &&
> + test_cmp expect actual &&

The above is meant to see explicit "--detach" gives the same message
whether advice.detachedHead is set to true or false, which is good.
It however does not make sure these messages do not caution about
detaching.

> + git checkout child &&
> + git checkout HEAD >actual &&

This goes to "child" branch and then does a no-op "checkout HEAD"
that does not even detach.

> + ! test_cmp expect actual &&

And then it compares the message from a no-op "checkout" and
the previously obtained message from a detaching "checkout".

Another thing that this is not checking is that a detaching
"checkout" without an explicit "--detach" still gives the advice
when advice.detachedHead is set to true (or left to default, for
that matter).

Perhaps you would want to do it a bit differently.  How does this
look?

# baseline
test_config advice.detachedHead true &&
git checkout child && git checkout HEAD^0 >expect.advice &&
test_config advice.detachedHead false &&
git checkout child && git checkout HEAD^0 >expect.no-advice &&
test_unconfig advice.detachedHead &&
# without configuration, the advice.* variables default to true
git checkout child && git checkout HEAD^0 >actual &&
test_cmp expect.advice actual &&

# with explicit --detach
# no configuration
test_unconfig advice.detachedHead &&
git checkout child && git checkout --detach HEAD >actual &&
test_cmp expect.no-advice actual &&

# explicitly ask advice
test_config advice.detachedHead true &&
git checkout child && git checkout --detach HEAD >actual &&
test_cmp expect.no-advice actual &&

# explicitly decline advice
test_config advice.detachedHead false &&
git checkout child && git checkout --detach HEAD >actual &&
test_cmp expect.no-advice actual

It might be controversial how the second from the last case should
behave, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git stash --help` tries to pull up nonexistent file gitstack.html

[Lars Schneider]

> On 12 Aug 2016, at 17:48, Junio C Hamano  wrote:
> 
> Joseph Musser  writes:
> 
>> Looks like a simple typo.
> 
> Unfortunately this does not reproduce to me (built from source on
> Ubuntu Linux).

I tried it with the latest released version on Windows and OSX (2.9.2)
and was not able to reproduce it, too.

- Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-subtree: compare file names by absolute paths

[Ivan Oleynikov]

This commit removes false positive assertion fails of `git subtree split` when
the --prefix argument is not in a particular form produced by `git ls-tree`.

For example, typical usage of the command could be:

  git subtree split -b split --prefix=some/relative/path

But

  git subtree split -b split --prefix=./some/relative/path

Would fail with multiple assertion errors. This commit makes the latter command
work without errors.

Signed-off-by: Ivan Oleynikov 
---

Notes:
The bug fixed by this commit can be reproduced like this:

$ git init
Initialized empty Git repository in /tmp/test/.git/
$ mkdir a b
$ touch a/file b/file
$ git add a
$ git commit -m a
[master (root-commit) b42584a] a
 1 file changed, 0 insertions($), 0 deletions(-)
 create mode 100644 a/file
$ git add b
$ git commit -m b
[master 5114301] b
 1 file changed, 0 insertions($), 0 deletions(-)
 create mode 100644 b/file
$ git subtree split -b split_a --prefix=a
Created branch 'split_a'
e9f5d81efacb33ab6cf67fe9ff376b33a483a92f
$ git subtree split -b split_b --prefix=./b
assertion failed:  [ b = ./b ]
No new revisions were found

When the commit is applied `git subtree split` works as expected:

$ git init
Initialized empty Git repository in /tmp/test/.git/
$ mkdir a b
$ touch a/file b/file
$ git add a
$ git commit -m a
[master (root-commit) bc80f36] a
 1 file changed, 0 insertions($), 0 deletions(-)
 create mode 100644 a/file
$ git add b
$ git commit -m b
[master e59c446] b
 1 file changed, 0 insertions($), 0 deletions(-)
 create mode 100644 b/file
$ git subtree split -b split_a --prefix=a
Created branch 'split_a'
d542e9cd2de5956dd7ca77b169dba1c8418fa03a
$ git subtree split -b split_b --prefix=./b
Created branch 'split_b'
3ae7854c0c395413c807b2bc4e75b651adc63f8c

 contrib/subtree/git-subtree.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index b567eae..d9351b9 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -411,7 +411,7 @@ subtree_for_commit()
dir="$2"
git ls-tree "$commit" -- "$dir" |
while read mode type tree name; do
-   assert [ "$name" = "$dir" ]
+   assert [ "$(readlink -f $name)" = "$(readlink -f $dir)" ]
assert [ "$type" = "tree" -o "$type" = "commit" ]
[ "$type" = "commit" ] && continue  # ignore submodules
echo $tree
-- 
2.1.4


-- 
Ivan Oleynikov
STC Metrotek
St.Petersburg
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] checkout: do not mention detach advice for explicit --detach option

[Stefan Beller]

On Fri, Aug 12, 2016 at 8:43 AM, Jeff King  wrote:
> On Fri, Aug 12, 2016 at 08:37:44AM -0700, Stefan Beller wrote:
>
>> > Is there a reason for not unsetting `advice.detachedHead` at the
>> > end of the test?
>>
>> done
>>
>> I did not consider to clean up after myself... what a selfish world!
>
> The right way to do it is:
>
>   test_config advice.detachedHead false &&

okay.

>   ...
>
> so that the cleanup runs whether or not you may it to the end of the
> script.
>
>> +test_expect_success 'no advice given for explicit detached head state' '
>> + git config advice.detachedHead false &&
>> + git checkout child &&
>> + git checkout --detach HEAD >expect &&
>> + git config advice.detachedHead true &&
>> + git checkout child &&
>> + git checkout --detach HEAD >actual &&
>> + test_cmp expect actual &&
>> + git checkout child &&
>> + git checkout HEAD >actual &&
>> + ! test_cmp expect actual &&
>> + git config --unset advice.detachedHead
>> +'
>
> Hmm. Using "!test_cmp" seems weird to me, just because it would falsely
> claim success if something else unexpected changes. Our usual method for
> making sure some particular output does not appear is "test_i18ngrep"
> with a liberal pattern.

and I advanced the liberal a bit more. ;)
So maybe we'd be looking that no 'detached HEAD' occurs?

test_i18ngrep ! "'detached HEAD'" actual

I think testing that we do not give out advice (i.e. behave the same as if
not giving out advice) is best tested to just compare the output to
the output of "git -c advice.detachedHead=false ...", which is what I do here.
This seems to be future proof to me no matter how we reword the advice or
the actual message on checkout?

Thanks,
Stefan

>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 0/9] status: V2 porcelain status

[Jeff Hostetler]

From: Jeff Hostetler 

This patch series adds porcelain V2 format to status.
This provides detailed information about file changes
and about the current branch.

The new output is accessed via:
git status --porcelain=v2 [--branch]

This v8 patch series addresses the remaining feedback
about the unit tests from the v6 and v7 series.

This series has been rebased onto 787fadc reference point.

Jeff Hostetler (9):
  status: rename long-format print routines
  status: cleanup API to wt_status_print
  status: support --porcelain[=]
  status: collect per-file data for --porcelain=v2
  status: print per-file porcelain v2 status data
  status: print branch info with --porcelain=v2 --branch
  git-status.txt: describe --porcelain=v2 format
  test-lib-functions.sh: Add lf_to_nul
  status: unit tests for --porcelain=v2

 Documentation/git-status.txt | 133 +-
 builtin/commit.c |  78 +++---
 t/t7060-wtstatus.sh  |  21 ++
 t/t7064-wtstatus-pv2.sh  | 593 +++
 t/test-lib-functions.sh  |   4 +
 wt-status.c  | 570 -
 wt-status.h  |  19 +-
 7 files changed, 1306 insertions(+), 112 deletions(-)
 create mode 100755 t/t7064-wtstatus-pv2.sh

-- 
2.8.0.rc4.17.gac42084.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 7/9] git-status.txt: describe --porcelain=v2 format

[Jeff Hostetler]

From: Jeff Hostetler 

Update status manpage to include information about
porcelain v2 format.

Signed-off-by: Jeff Hostetler 
---
 Documentation/git-status.txt | 126 +--
 1 file changed, 122 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 6b1454b..a58973b 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -183,12 +183,12 @@ in which case `XY` are `!!`.
 
 If -b is used the short-format status is preceded by a line
 
-## branchname tracking info
+## branchname tracking info
 
-Porcelain Format
-
+Porcelain Format Version 1
+~~
 
-The porcelain format is similar to the short format, but is guaranteed
+Version 1 porcelain format is similar to the short format, but is guaranteed
 not to change in a backwards-incompatible way between Git versions or
 based on user configuration. This makes it ideal for parsing by scripts.
 The description of the short format above also describes the porcelain
@@ -210,6 +210,124 @@ field from the first filename).  Third, filenames 
containing special
 characters are not specially formatted; no quoting or
 backslash-escaping is performed.
 
+Porcelain Format Version 2
+~~
+
+Version 2 format adds more detailed information about the state of
+the worktree and changed items.  Version 2 also defines an extensible
+set of easy to parse optional headers.
+
+Header lines start with "#" and are added in response to specific
+command line arguments.  Parsers should ignore headers they
+don't recognize.
+
+### Branch Headers
+
+If `--branch` is given, a series of header lines are printed with
+information about the current branch.
+
+Line Notes
+
+# branch.oid  | (initial)Current commit.
+# branch.head  | (detached)  Current branch.
+# branch.upstream   If upstream is set.
+# branch.ab + -   If upstream is set and
+ the commit is present.
+
+
+### Changed Tracked Entries
+
+Following the headers, a series of lines are printed for tracked
+entries.  One of three different line formats may be used to describe
+an entry depending on the type of change.  Tracked entries are printed
+in an undefined order; parsers should allow for a mixture of the 3
+line types in any order.
+
+Ordinary changed entries have the following format:
+
+1
+
+Renamed or copied entries have the following format:
+
+2 
+
+Field   Meaning
+
+A 2 character field containing the staged and
+unstaged XY values described in the short format,
+with unchanged indicated by a "." rather than
+a space.
+   A 4 character field describing the submodule state.
+"N..." when the entry is not a submodule.
+"S" when the entry is a submodule.
+ is "C" if the commit changed; otherwise ".".
+ is "M" if it has tracked changes; otherwise ".".
+ is "U" if there are untracked changes; otherwise ".".
+The octal file mode in HEAD.
+The octal file mode in the index.
+The octal file mode in the worktree.
+The object name in HEAD.
+The object name in the index.
+  The rename or copy score (denoting the percentage
+of similarity between the source and target of the
+move or copy). For example "R100" or "C75".
+  The pathname.  In a renamed/copied entry, this
+is the path in the index and in the working tree.
+   When the `-z` option is used, the 2 pathnames are separated
+with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
+byte separates them.
+  The pathname in the commit at HEAD.  This is only
+present in a renamed/copied entry, and tells
+where the renamed/copied contents came from.
+
+
+Unmerged entries have the following format; the first character is
+a "u" to distinguish from ordinary changed entries.
+
+u  
+
+Field   Meaning
+
+A 2 character field describing the conflict type
+as described in the short format.
+   A 4 character field describing the submodule state
+as described above.
+The octal file mode in stage 1.
+The octal file mode in stage 2.
+The octal file mode in stage 3.
+  

[PATCH v8 6/9] status: print branch info with --porcelain=v2 --branch

[Jeff Hostetler]

From: Jeff Hostetler 

Expand porcelain v2 output to include branch and tracking
branch information. This includes the commit id, the branch,
the upstream branch, and the ahead and behind counts.

Signed-off-by: Jeff Hostetler 
---
 builtin/commit.c |  5 
 wt-status.c  | 90 
 wt-status.h  |  1 +
 3 files changed, 96 insertions(+)

diff --git a/builtin/commit.c b/builtin/commit.c
index 3d222d3..5504afe 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -510,6 +510,8 @@ static int run_status(FILE *fp, const char *index_file, 
const char *prefix, int
s->fp = fp;
s->nowarn = nowarn;
s->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;
+   if (!s->is_initial)
+   hashcpy(s->sha1_commit, sha1);
s->status_format = status_format;
s->ignore_submodule_arg = ignore_submodule_arg;
 
@@ -1378,6 +1380,9 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
fd = hold_locked_index(_lock, 0);
 
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
+   if (!s.is_initial)
+   hashcpy(s.sha1_commit, sha1);
+
s.ignore_submodule_arg = ignore_submodule_arg;
s.status_format = status_format;
s.verbose = verbose;
diff --git a/wt-status.c b/wt-status.c
index bd9075b..ebe4a1e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1813,6 +1813,92 @@ static void wt_porcelain_print(struct wt_status *s)
 }
 
 /*
+ * Print branch information for porcelain v2 output.  These lines
+ * are printed when the '--branch' parameter is given.
+ *
+ *# branch.oid 
+ *# branch.head 
+ *   [# branch.upstream 
+ *   [# branch.ab + -]]
+ *
+ *   ::= the current commit hash or the the literal
+ *   "(initial)" to indicate an initialized repo
+ *   with no commits.
+ *
+ * ::=  the current branch name or
+ *   "(detached)" literal when detached head or
+ *   "(unknown)" when something is wrong.
+ *
+ * ::= the upstream branch name, when set.
+ *
+ *::= integer ahead value, when upstream set
+ *   and the commit is present (not gone).
+ *
+ *   ::= integer behind value, when upstream set
+ *   and commit is present.
+ *
+ *
+ * The end-of-line is defined by the -z flag.
+ *
+ *  ::= NUL when -z,
+ *   LF when NOT -z.
+ *
+ */
+static void wt_porcelain_v2_print_tracking(struct wt_status *s)
+{
+   struct branch *branch;
+   const char *base;
+   const char *branch_name;
+   struct wt_status_state state;
+   int ab_info, nr_ahead, nr_behind;
+   char eol = s->null_termination ? '\0' : '\n';
+
+   memset(, 0, sizeof(state));
+   wt_status_get_state(, s->branch && !strcmp(s->branch, "HEAD"));
+
+   fprintf(s->fp, "# branch.oid %s%c",
+   (s->is_initial ? "(initial)" : 
sha1_to_hex(s->sha1_commit)),
+   eol);
+
+   if (!s->branch)
+   fprintf(s->fp, "# branch.head %s%c", "(unknown)", eol);
+   else {
+   if (!strcmp(s->branch, "HEAD")) {
+   fprintf(s->fp, "# branch.head %s%c", "(detached)", eol);
+
+   if (state.rebase_in_progress || 
state.rebase_interactive_in_progress)
+   branch_name = state.onto;
+   else if (state.detached_from)
+   branch_name = state.detached_from;
+   else
+   branch_name = "";
+   } else {
+   branch_name = NULL;
+   skip_prefix(s->branch, "refs/heads/", _name);
+
+   fprintf(s->fp, "# branch.head %s%c", branch_name, eol);
+   }
+
+   /* Lookup stats on the upstream tracking branch, if set. */
+   branch = branch_get(branch_name);
+   base = NULL;
+   ab_info = (stat_tracking_info(branch, _ahead, _behind, 
) == 0);
+   if (base) {
+   base = shorten_unambiguous_ref(base, 0);
+   fprintf(s->fp, "# branch.upstream %s%c", base, eol);
+   free((char *)base);
+
+   if (ab_info)
+   fprintf(s->fp, "# branch.ab +%d -%d%c", 
nr_ahead, nr_behind, eol);
+   }
+   }
+
+   free(state.branch);
+   free(state.onto);
+   free(state.detached_from);
+}
+
+/*
  * Convert various submodule status values into a
  * fixed-length string of characters in the buffer provided.
  */
@@ -2058,6 +2144,7 @@ static void wt_porcelain_v2_print_other(
 /*
  * Print porcelain V2 status.
  *
+ * []
  * []*
  * []*
  * []*
@@ -2070,6 +2157,9 @@ static void wt_porcelain_v2_print(struct wt_status *s)
struct 

[PATCH v8 5/9] status: print per-file porcelain v2 status data

[Jeff Hostetler]

From: Jeff Hostetler 

Print per-file information in porcelain v2 format.

Signed-off-by: Jeff Hostetler 
---
 wt-status.c | 285 +++-
 1 file changed, 284 insertions(+), 1 deletion(-)

diff --git a/wt-status.c b/wt-status.c
index dd0a1ab..bd9075b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1812,6 +1812,289 @@ static void wt_porcelain_print(struct wt_status *s)
wt_shortstatus_print(s);
 }
 
+/*
+ * Convert various submodule status values into a
+ * fixed-length string of characters in the buffer provided.
+ */
+static void wt_porcelain_v2_submodule_state(
+   struct wt_status_change_data *d,
+   char sub[5])
+{
+   if (S_ISGITLINK(d->mode_head) ||
+   S_ISGITLINK(d->mode_index) ||
+   S_ISGITLINK(d->mode_worktree)) {
+   sub[0] = 'S';
+   sub[1] = d->new_submodule_commits ? 'C' : '.';
+   sub[2] = (d->dirty_submodule & DIRTY_SUBMODULE_MODIFIED) ? 'M' 
: '.';
+   sub[3] = (d->dirty_submodule & DIRTY_SUBMODULE_UNTRACKED) ? 'U' 
: '.';
+   } else {
+   sub[0] = 'N';
+   sub[1] = '.';
+   sub[2] = '.';
+   sub[3] = '.';
+   }
+   sub[4] = 0;
+}
+
+/*
+ * Fix-up changed entries before we print them.
+ */
+static void wt_porcelain_v2_fix_up_changed(
+   struct string_list_item *it,
+   struct wt_status *s)
+{
+   struct wt_status_change_data *d = it->util;
+
+   if (!d->index_status) {
+   /*
+* This entry is unchanged in the index (relative to the head).
+* Therefore, the collect_updated_cb was never called for this
+* entry (during the head-vs-index scan) and so the head column
+* fields were never set.
+*
+* We must have data for the index column (from the
+* index-vs-worktree scan (otherwise, this entry should not be
+* in the list of changes)).
+*
+* Copy index column fields to the head column, so that our
+* output looks complete.
+*/
+   assert(d->mode_head == 0);
+   d->mode_head = d->mode_index;
+   oidcpy(>oid_head, >oid_index);
+   }
+
+   if (!d->worktree_status) {
+   /*
+* This entry is unchanged in the worktree (relative to the 
index).
+* Therefore, the collect_changed_cb was never called for this 
entry
+* (during the index-vs-worktree scan) and so the worktree 
column
+* fields were never set.
+*
+* We must have data for the index column (from the 
head-vs-index
+* scan).
+*
+* Copy the index column fields to the worktree column so that
+* our output looks complete.
+*
+* Note that we only have a mode field in the worktree column
+* because the scan code tries really hard to not have to 
compute it.
+*/
+   assert(d->mode_worktree == 0);
+   d->mode_worktree = d->mode_index;
+   }
+}
+
+/*
+ * Print porcelain v2 info for tracked entries with changes.
+ */
+static void wt_porcelain_v2_print_changed_entry(
+   struct string_list_item *it,
+   struct wt_status *s)
+{
+   struct wt_status_change_data *d = it->util;
+   struct strbuf buf_index = STRBUF_INIT;
+   struct strbuf buf_head = STRBUF_INIT;
+   const char *path_index = NULL;
+   const char *path_head = NULL;
+   char key[3];
+   char submodule_token[5];
+   char sep_char, eol_char;
+
+   wt_porcelain_v2_fix_up_changed(it, s);
+   wt_porcelain_v2_submodule_state(d, submodule_token);
+
+   key[0] = d->index_status ? d->index_status : '.';
+   key[1] = d->worktree_status ? d->worktree_status : '.';
+   key[2] = 0;
+
+   if (s->null_termination) {
+   /*
+* In -z mode, we DO NOT C-quote pathnames.  Current path is 
ALWAYS first.
+* A single NUL character separates them.
+*/
+   sep_char = '\0';
+   eol_char = '\0';
+   path_index = it->string;
+   path_head = d->head_path;
+   } else {
+   /*
+* Path(s) are C-quoted if necessary. Current path is ALWAYS 
first.
+* The source path is only present when necessary.
+* A single TAB separates them (because paths can contain spaces
+* which are not escaped and C-quoting does escape TAB 
characters).
+*/
+   sep_char = '\t';
+   eol_char = '\n';
+   path_index = quote_path(it->string, s->prefix, _index);
+   if 

[PATCH v8 9/9] status: unit tests for --porcelain=v2

[Jeff Hostetler]

From: Jeff Hostetler 

Test porcelain v2 status format.

Signed-off-by: Jeff Hostetler 
---
 t/t7064-wtstatus-pv2.sh | 593 
 1 file changed, 593 insertions(+)
 create mode 100755 t/t7064-wtstatus-pv2.sh

diff --git a/t/t7064-wtstatus-pv2.sh b/t/t7064-wtstatus-pv2.sh
new file mode 100755
index 000..3012a4d
--- /dev/null
+++ b/t/t7064-wtstatus-pv2.sh
@@ -0,0 +1,593 @@
+#!/bin/sh
+
+test_description='git status --porcelain=v2
+
+This test exercises porcelain V2 output for git status.'
+
+
+. ./test-lib.sh
+
+
+test_expect_success setup '
+   test_tick &&
+   git config core.autocrlf false &&
+   echo x >file_x &&
+   echo y >file_y &&
+   echo z >file_z &&
+   mkdir dir1 &&
+   echo a >dir1/file_a &&
+   echo b >dir1/file_b
+'
+
+test_expect_success 'before initial commit, nothing added, only untracked' '
+   cat >expect <<-EOF &&
+   # branch.oid (initial)
+   # branch.head master
+   ? actual
+   ? dir1/
+   ? expect
+   ? file_x
+   ? file_y
+   ? file_z
+   EOF
+
+   git status --porcelain=v2 --branch --untracked-files=normal >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'before initial commit, things added' '
+   git add file_x file_y file_z dir1 &&
+   OID_A=$(git hash-object -t blob -- dir1/file_a) &&
+   OID_B=$(git hash-object -t blob -- dir1/file_b) &&
+   OID_X=$(git hash-object -t blob -- file_x) &&
+   OID_Y=$(git hash-object -t blob -- file_y) &&
+   OID_Z=$(git hash-object -t blob -- file_z) &&
+
+   cat >expect <<-EOF &&
+   # branch.oid (initial)
+   # branch.head master
+   1 A. N... 00 100644 100644 $_z40 $OID_A dir1/file_a
+   1 A. N... 00 100644 100644 $_z40 $OID_B dir1/file_b
+   1 A. N... 00 100644 100644 $_z40 $OID_X file_x
+   1 A. N... 00 100644 100644 $_z40 $OID_Y file_y
+   1 A. N... 00 100644 100644 $_z40 $OID_Z file_z
+   ? actual
+   ? expect
+   EOF
+
+   git status --porcelain=v2 --branch --untracked-files=all >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'before initial commit, things added (-z)' '
+   lf_to_nul >expect <<-EOF &&
+   # branch.oid (initial)
+   # branch.head master
+   1 A. N... 00 100644 100644 $_z40 $OID_A dir1/file_a
+   1 A. N... 00 100644 100644 $_z40 $OID_B dir1/file_b
+   1 A. N... 00 100644 100644 $_z40 $OID_X file_x
+   1 A. N... 00 100644 100644 $_z40 $OID_Y file_y
+   1 A. N... 00 100644 100644 $_z40 $OID_Z file_z
+   ? actual
+   ? expect
+   EOF
+
+   git status -z --porcelain=v2 --branch --untracked-files=all >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'make first commit, comfirm HEAD oid and branch' '
+   git commit -m initial &&
+   H0=$(git rev-parse HEAD) &&
+   cat >expect <<-EOF &&
+   # branch.oid $H0
+   # branch.head master
+   ? actual
+   ? expect
+   EOF
+
+   git status --porcelain=v2 --branch --untracked-files=all >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'after first commit, create unstaged changes' '
+   echo x >>file_x &&
+   OID_X1=$(git hash-object -t blob -- file_x) &&
+   rm file_z &&
+   H0=$(git rev-parse HEAD) &&
+
+   cat >expect <<-EOF &&
+   # branch.oid $H0
+   # branch.head master
+   1 .M N... 100644 100644 100644 $OID_X $OID_X file_x
+   1 .D N... 100644 100644 00 $OID_Z $OID_Z file_z
+   ? actual
+   ? expect
+   EOF
+
+   git status --porcelain=v2 --branch --untracked-files=all >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'after first commit but omit untracked files and branch' '
+   cat >expect <<-EOF &&
+   1 .M N... 100644 100644 100644 $OID_X $OID_X file_x
+   1 .D N... 100644 100644 00 $OID_Z $OID_Z file_z
+   EOF
+
+   git status --porcelain=v2 --untracked-files=no >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'after first commit, stage existing changes' '
+   git add file_x &&
+   git rm file_z &&
+   H0=$(git rev-parse HEAD) &&
+
+   cat >expect <<-EOF &&
+   # branch.oid $H0
+   # branch.head master
+   1 M. N... 100644 100644 100644 $OID_X $OID_X1 file_x
+   1 D. N... 100644 00 00 $OID_Z $_z40 file_z
+   ? actual
+   ? expect
+   EOF
+
+   git status --porcelain=v2 --branch --untracked-files=all >actual &&
+   test_cmp expect actual
+'
+
+test_expect_success 'rename causes 2 path lines' '
+   git mv file_y renamed_y &&
+   H0=$(git rev-parse HEAD) &&
+
+   q_to_tab >expect <<-EOF &&
+   # branch.oid $H0
+   # branch.head master
+   1 M. N... 100644 100644 100644 $OID_X $OID_X1 file_x
+   1 D. N... 100644 00 00 $OID_Z $_z40 file_z

[PATCH v8 1/9] status: rename long-format print routines

[Jeff Hostetler]

From: Jeff Hostetler 

Rename the various wt_status_print*() routines to be
wt_longstatus_print*() to make it clear that these
routines are only concerned with the normal/long
status output and reduce developer confusion as other
status formats are added in the future.

Signed-off-by: Jeff Hostetler 
---
 builtin/commit.c |   4 +-
 wt-status.c  | 110 +++
 wt-status.h  |   2 +-
 3 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 1f6dbcd..b80273b 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -515,7 +515,7 @@ static int run_status(FILE *fp, const char *index_file, 
const char *prefix, int
break;
case STATUS_FORMAT_NONE:
case STATUS_FORMAT_LONG:
-   wt_status_print(s);
+   wt_longstatus_print(s);
break;
}
 
@@ -1403,7 +1403,7 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
case STATUS_FORMAT_LONG:
s.verbose = verbose;
s.ignore_submodule_arg = ignore_submodule_arg;
-   wt_status_print();
+   wt_longstatus_print();
break;
}
return 0;
diff --git a/wt-status.c b/wt-status.c
index 19cbc39..961bbc7 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -139,7 +139,7 @@ void wt_status_prepare(struct wt_status *s)
s->display_comment_prefix = 0;
 }
 
-static void wt_status_print_unmerged_header(struct wt_status *s)
+static void wt_longstatus_print_unmerged_header(struct wt_status *s)
 {
int i;
int del_mod_conflict = 0;
@@ -191,7 +191,7 @@ static void wt_status_print_unmerged_header(struct 
wt_status *s)
status_printf_ln(s, c, "%s", "");
 }
 
-static void wt_status_print_cached_header(struct wt_status *s)
+static void wt_longstatus_print_cached_header(struct wt_status *s)
 {
const char *c = color(WT_STATUS_HEADER, s);
 
@@ -207,9 +207,9 @@ static void wt_status_print_cached_header(struct wt_status 
*s)
status_printf_ln(s, c, "%s", "");
 }
 
-static void wt_status_print_dirty_header(struct wt_status *s,
-int has_deleted,
-int has_dirty_submodules)
+static void wt_longstatus_print_dirty_header(struct wt_status *s,
+int has_deleted,
+int has_dirty_submodules)
 {
const char *c = color(WT_STATUS_HEADER, s);
 
@@ -226,9 +226,9 @@ static void wt_status_print_dirty_header(struct wt_status 
*s,
status_printf_ln(s, c, "%s", "");
 }
 
-static void wt_status_print_other_header(struct wt_status *s,
-const char *what,
-const char *how)
+static void wt_longstatus_print_other_header(struct wt_status *s,
+const char *what,
+const char *how)
 {
const char *c = color(WT_STATUS_HEADER, s);
status_printf_ln(s, c, "%s:", what);
@@ -238,7 +238,7 @@ static void wt_status_print_other_header(struct wt_status 
*s,
status_printf_ln(s, c, "%s", "");
 }
 
-static void wt_status_print_trailer(struct wt_status *s)
+static void wt_longstatus_print_trailer(struct wt_status *s)
 {
status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
 }
@@ -304,8 +304,8 @@ static int maxwidth(const char *(*label)(int), int minval, 
int maxval)
return result;
 }
 
-static void wt_status_print_unmerged_data(struct wt_status *s,
- struct string_list_item *it)
+static void wt_longstatus_print_unmerged_data(struct wt_status *s,
+ struct string_list_item *it)
 {
const char *c = color(WT_STATUS_UNMERGED, s);
struct wt_status_change_data *d = it->util;
@@ -331,9 +331,9 @@ static void wt_status_print_unmerged_data(struct wt_status 
*s,
strbuf_release();
 }
 
-static void wt_status_print_change_data(struct wt_status *s,
-   int change_type,
-   struct string_list_item *it)
+static void wt_longstatus_print_change_data(struct wt_status *s,
+   int change_type,
+   struct string_list_item *it)
 {
struct wt_status_change_data *d = it->util;
const char *c = color(change_type, s);
@@ -378,7 +378,7 @@ static void wt_status_print_change_data(struct wt_status *s,
status = d->worktree_status;
break;
default:
-   die("BUG: unhandled change_type %d in 
wt_status_print_change_data",
+   die("BUG: unhandled change_type %d in 
wt_longstatus_print_change_data",
   

[PATCH v8 3/9] status: support --porcelain[=]

[Jeff Hostetler]

From: Jeff Hostetler 

Update --porcelain argument to take optional version parameter
to allow multiple porcelain formats to be supported in the future.

The token "v1" is the default value and indicates the traditional
porcelain format.  (The token "1" is an alias for that.)

Signed-off-by: Jeff Hostetler 
---
 Documentation/git-status.txt |  7 +--
 builtin/commit.c | 21 ++---
 t/t7060-wtstatus.sh  | 21 +
 3 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index e1e8f57..6b1454b 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -32,11 +32,14 @@ OPTIONS
 --branch::
Show the branch and tracking info even in short-format.
 
---porcelain::
+--porcelain[=]::
Give the output in an easy-to-parse format for scripts.
This is similar to the short output, but will remain stable
across Git versions and regardless of user configuration. See
below for details.
++
+The version parameter is used to specify the format version.
+This is optional and defaults to the original version 'v1' format.
 
 --long::
Give the output in the long-format. This is the default.
@@ -96,7 +99,7 @@ configuration variable documented in linkgit:git-config[1].
 
 -z::
Terminate entries with NUL, instead of LF.  This implies
-   the `--porcelain` output format if no other format is given.
+   the `--porcelain=v1` output format if no other format is given.
 
 --column[=]::
 --no-column::
diff --git a/builtin/commit.c b/builtin/commit.c
index a792deb..185ac35 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -144,6 +144,21 @@ static struct strbuf message = STRBUF_INIT;
 
 static enum wt_status_format status_format = STATUS_FORMAT_UNSPECIFIED;
 
+static int opt_parse_porcelain(const struct option *opt, const char *arg, int 
unset)
+{
+   enum wt_status_format *value = (enum wt_status_format *)opt->value;
+   if (unset)
+   *value = STATUS_FORMAT_NONE;
+   else if (!arg)
+   *value = STATUS_FORMAT_PORCELAIN;
+   else if (!strcmp(arg, "v1") || !strcmp(arg, "1"))
+   *value = STATUS_FORMAT_PORCELAIN;
+   else
+   die("unsupported porcelain version '%s'", arg);
+
+   return 0;
+}
+
 static int opt_parse_m(const struct option *opt, const char *arg, int unset)
 {
struct strbuf *buf = opt->value;
@@ -1316,9 +1331,9 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
N_("show status concisely"), STATUS_FORMAT_SHORT),
OPT_BOOL('b', "branch", _branch,
 N_("show branch information")),
-   OPT_SET_INT(0, "porcelain", _format,
-   N_("machine-readable output"),
-   STATUS_FORMAT_PORCELAIN),
+   { OPTION_CALLBACK, 0, "porcelain", _format,
+ N_("version"), N_("machine-readable output"),
+ PARSE_OPT_OPTARG, opt_parse_porcelain },
OPT_SET_INT(0, "long", _format,
N_("show status in long format (default)"),
STATUS_FORMAT_LONG),
diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index 44bf1d8..00e0ceb 100755
--- a/t/t7060-wtstatus.sh
+++ b/t/t7060-wtstatus.sh
@@ -228,4 +228,25 @@ test_expect_success 'status --branch with detached HEAD' '
test_i18ncmp expected actual
 '
 
+## Duplicate the above test and verify --porcelain=v1 arg parsing.
+test_expect_success 'status --porcelain=v1 --branch with detached HEAD' '
+   git reset --hard &&
+   git checkout master^0 &&
+   git status --branch --porcelain=v1 >actual &&
+   cat >expected <<-EOF &&
+   ## HEAD (no branch)
+   ?? .gitconfig
+   ?? actual
+   ?? expect
+   ?? expected
+   ?? mdconflict/
+   EOF
+   test_i18ncmp expected actual
+'
+
+## Verify parser error on invalid --porcelain argument.
+test_expect_success 'status --porcelain=bogus' '
+   test_must_fail git status --porcelain=bogus
+'
+
 test_done
-- 
2.8.0.rc4.17.gac42084.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 2/9] status: cleanup API to wt_status_print

[Jeff Hostetler]

From: Jeff Hostetler 

Refactor the API between builtin/commit.c and wt-status.[ch].

Hide the details of the various wt_*status_print() routines inside
wt-status.c behind a single (new) wt_status_print() routine.
Eliminate the switch statements from builtin/commit.c.
Allow details of new status formats to be isolated within wt-status.c

Signed-off-by: Jeff Hostetler 
---
 builtin/commit.c | 51 +--
 wt-status.c  | 25 ++---
 wt-status.h  | 16 
 3 files changed, 43 insertions(+), 49 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index b80273b..a792deb 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -142,14 +142,7 @@ static int show_ignored_in_status, have_option_m;
 static const char *only_include_assumed;
 static struct strbuf message = STRBUF_INIT;
 
-static enum status_format {
-   STATUS_FORMAT_NONE = 0,
-   STATUS_FORMAT_LONG,
-   STATUS_FORMAT_SHORT,
-   STATUS_FORMAT_PORCELAIN,
-
-   STATUS_FORMAT_UNSPECIFIED
-} status_format = STATUS_FORMAT_UNSPECIFIED;
+static enum wt_status_format status_format = STATUS_FORMAT_UNSPECIFIED;
 
 static int opt_parse_m(const struct option *opt, const char *arg, int unset)
 {
@@ -500,24 +493,11 @@ static int run_status(FILE *fp, const char *index_file, 
const char *prefix, int
s->fp = fp;
s->nowarn = nowarn;
s->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;
+   s->status_format = status_format;
+   s->ignore_submodule_arg = ignore_submodule_arg;
 
wt_status_collect(s);
-
-   switch (status_format) {
-   case STATUS_FORMAT_SHORT:
-   wt_shortstatus_print(s);
-   break;
-   case STATUS_FORMAT_PORCELAIN:
-   wt_porcelain_print(s);
-   break;
-   case STATUS_FORMAT_UNSPECIFIED:
-   die("BUG: finalize_deferred_config() should have been called");
-   break;
-   case STATUS_FORMAT_NONE:
-   case STATUS_FORMAT_LONG:
-   wt_longstatus_print(s);
-   break;
-   }
+   wt_status_print(s);
 
return s->commitable;
 }
@@ -1099,7 +1079,7 @@ static const char *read_commit_message(const char *name)
  * is not in effect here.
  */
 static struct status_deferred_config {
-   enum status_format status_format;
+   enum wt_status_format status_format;
int show_branch;
 } status_deferred_config = {
STATUS_FORMAT_UNSPECIFIED,
@@ -1381,6 +1361,9 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
 
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
s.ignore_submodule_arg = ignore_submodule_arg;
+   s.status_format = status_format;
+   s.verbose = verbose;
+
wt_status_collect();
 
if (0 <= fd)
@@ -1389,23 +1372,7 @@ int cmd_status(int argc, const char **argv, const char 
*prefix)
if (s.relative_paths)
s.prefix = prefix;
 
-   switch (status_format) {
-   case STATUS_FORMAT_SHORT:
-   wt_shortstatus_print();
-   break;
-   case STATUS_FORMAT_PORCELAIN:
-   wt_porcelain_print();
-   break;
-   case STATUS_FORMAT_UNSPECIFIED:
-   die("BUG: finalize_deferred_config() should have been called");
-   break;
-   case STATUS_FORMAT_NONE:
-   case STATUS_FORMAT_LONG:
-   s.verbose = verbose;
-   s.ignore_submodule_arg = ignore_submodule_arg;
-   wt_longstatus_print();
-   break;
-   }
+   wt_status_print();
return 0;
 }
 
diff --git a/wt-status.c b/wt-status.c
index 961bbc7..e0dda24 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1447,7 +1447,7 @@ static void wt_longstatus_print_state(struct wt_status *s,
show_bisect_in_progress(s, state, state_color);
 }
 
-void wt_longstatus_print(struct wt_status *s)
+static void wt_longstatus_print(struct wt_status *s)
 {
const char *branch_color = color(WT_STATUS_ONBRANCH, s);
const char *branch_status_color = color(WT_STATUS_HEADER, s);
@@ -1714,7 +1714,7 @@ static void wt_shortstatus_print_tracking(struct 
wt_status *s)
fputc(s->null_termination ? '\0' : '\n', s->fp);
 }
 
-void wt_shortstatus_print(struct wt_status *s)
+static void wt_shortstatus_print(struct wt_status *s)
 {
int i;
 
@@ -1746,7 +1746,7 @@ void wt_shortstatus_print(struct wt_status *s)
}
 }
 
-void wt_porcelain_print(struct wt_status *s)
+static void wt_porcelain_print(struct wt_status *s)
 {
s->use_color = 0;
s->relative_paths = 0;
@@ -1754,3 +1754,22 @@ void wt_porcelain_print(struct wt_status *s)
s->no_gettext = 1;
wt_shortstatus_print(s);
 }
+
+void wt_status_print(struct wt_status *s)
+{
+   switch (s->status_format) {
+   case STATUS_FORMAT_SHORT:
+   

[PATCH v8 4/9] status: collect per-file data for --porcelain=v2

[Jeff Hostetler]

From: Jeff Hostetler 

Collect extra per-file data for porcelain V2 format.

The output of `git status --porcelain` leaves out many
details about the current status that clients might like
to have.  This can force them to be less efficient as they
may need to launch secondary commands (and try to match
the logic within git) to accumulate this extra information.
For example, a GUI IDE might want the file mode to display
the correct icon for a changed item (without having to stat
it afterwards).

Signed-off-by: Jeff Hostetler 
---
 builtin/commit.c |  3 +++
 wt-status.c  | 64 ++--
 wt-status.h  |  4 
 3 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 185ac35..3d222d3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -153,6 +153,8 @@ static int opt_parse_porcelain(const struct option *opt, 
const char *arg, int un
*value = STATUS_FORMAT_PORCELAIN;
else if (!strcmp(arg, "v1") || !strcmp(arg, "1"))
*value = STATUS_FORMAT_PORCELAIN;
+   else if (!strcmp(arg, "v2") || !strcmp(arg, "2"))
+   *value = STATUS_FORMAT_PORCELAIN_V2;
else
die("unsupported porcelain version '%s'", arg);
 
@@ -1104,6 +1106,7 @@ static struct status_deferred_config {
 static void finalize_deferred_config(struct wt_status *s)
 {
int use_deferred_config = (status_format != STATUS_FORMAT_PORCELAIN &&
+  status_format != STATUS_FORMAT_PORCELAIN_V2 
&&
   !s->null_termination);
 
if (s->null_termination) {
diff --git a/wt-status.c b/wt-status.c
index e0dda24..dd0a1ab 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -434,6 +434,31 @@ static void wt_status_collect_changed_cb(struct 
diff_queue_struct *q,
if (S_ISGITLINK(p->two->mode))
d->new_submodule_commits = !!oidcmp(>one->oid,
>two->oid);
+
+   switch (p->status) {
+   case DIFF_STATUS_ADDED:
+   die("BUG: worktree status add???");
+   break;
+
+   case DIFF_STATUS_DELETED:
+   d->mode_index = p->one->mode;
+   oidcpy(>oid_index, >one->oid);
+   /* mode_worktree is zero for a delete. */
+   break;
+
+   case DIFF_STATUS_MODIFIED:
+   case DIFF_STATUS_TYPE_CHANGED:
+   case DIFF_STATUS_UNMERGED:
+   d->mode_index = p->one->mode;
+   d->mode_worktree = p->two->mode;
+   oidcpy(>oid_index, >one->oid);
+   break;
+
+   case DIFF_STATUS_UNKNOWN:
+   die("BUG: worktree status unknown???");
+   break;
+   }
+
}
 }
 
@@ -479,12 +504,36 @@ static void wt_status_collect_updated_cb(struct 
diff_queue_struct *q,
if (!d->index_status)
d->index_status = p->status;
switch (p->status) {
+   case DIFF_STATUS_ADDED:
+   /* Leave {mode,oid}_head zero for an add. */
+   d->mode_index = p->two->mode;
+   oidcpy(>oid_index, >two->oid);
+   break;
+   case DIFF_STATUS_DELETED:
+   d->mode_head = p->one->mode;
+   oidcpy(>oid_head, >one->oid);
+   /* Leave {mode,oid}_index zero for a delete. */
+   break;
+
case DIFF_STATUS_COPIED:
case DIFF_STATUS_RENAMED:
d->head_path = xstrdup(p->one->path);
+   d->score = p->score * 100 / MAX_SCORE;
+   /* fallthru */
+   case DIFF_STATUS_MODIFIED:
+   case DIFF_STATUS_TYPE_CHANGED:
+   d->mode_head = p->one->mode;
+   d->mode_index = p->two->mode;
+   oidcpy(>oid_head, >one->oid);
+   oidcpy(>oid_index, >two->oid);
break;
case DIFF_STATUS_UNMERGED:
d->stagemask = unmerged_mask(p->two->path);
+   /*
+* Don't bother setting {mode,oid}_{head,index} since 
the print
+* code will output the stage values directly and not 
use the
+* values in these fields.
+*/
break;
}
}
@@ -565,9 +614,17 @@ static void wt_status_collect_changes_initial(struct 
wt_status *s)
if (ce_stage(ce)) {
d->index_status = DIFF_STATUS_UNMERGED;

[PATCH v8 8/9] test-lib-functions.sh: Add lf_to_nul

[Jeff Hostetler]

From: Jeff Hostetler 

Add lf_to_nul() function to test-lib-functions.

Signed-off-by: Jeff Hostetler 
---
 t/test-lib-functions.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 4f7eadb..fdaeb3a 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -81,6 +81,10 @@ test_decode_color () {
'
 }
 
+lf_to_nul () {
+   perl -pe 'y/\012/\000/'
+}
+
 nul_to_q () {
perl -pe 'y/\000/Q/'
 }
-- 
2.8.0.rc4.17.gac42084.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: `git stash --help` tries to pull up nonexistent file gitstack.html

[Junio C Hamano]

Joseph Musser  writes:

> Looks like a simple typo.

Unfortunately this does not reproduce to me (built from source on
Ubuntu Linux).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] checkout: do not mention detach advice for explicit --detach option

[Jeff King]

On Fri, Aug 12, 2016 at 08:37:44AM -0700, Stefan Beller wrote:

> > Is there a reason for not unsetting `advice.detachedHead` at the
> > end of the test?
> 
> done
> 
> I did not consider to clean up after myself... what a selfish world!

The right way to do it is:

  test_config advice.detachedHead false &&
  ...

so that the cleanup runs whether or not you may it to the end of the
script.

> +test_expect_success 'no advice given for explicit detached head state' '
> + git config advice.detachedHead false &&
> + git checkout child &&
> + git checkout --detach HEAD >expect &&
> + git config advice.detachedHead true &&
> + git checkout child &&
> + git checkout --detach HEAD >actual &&
> + test_cmp expect actual &&
> + git checkout child &&
> + git checkout HEAD >actual &&
> + ! test_cmp expect actual &&
> + git config --unset advice.detachedHead
> +'

Hmm. Using "!test_cmp" seems weird to me, just because it would falsely
claim success if something else unexpected changes. Our usual method for
making sure some particular output does not appear is "test_i18ngrep"
with a liberal pattern.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 00/12] Update git revisions

[Marc Branchaud]

On 2016-08-12 03:07 AM, Philip Oakley wrote:

[2nd attempt : ISP troubles]

This has grown like topsy from a little two patch series that tried to
name the 2-dots notation [1] into this extended set of tweaks.


Honestly, I start just trying point out something concrete, like 
misrendered headers, but then I figure since I'm sending a review 
comment anyway I might as well go in-depth on the rest of the patch.


I think I'm sticking to substantive comments, but if I'm getting too 
picky please just swat me down!


M.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3] checkout: do not mention detach advice for explicit --detach option

[Stefan Beller]

When a user asked for a detached HEAD specifically with `--detach`,
we do not need to give advice on what a detached HEAD state entails as
we can assume they know what they're getting into as they asked for it.

Signed-off-by: Stefan Beller 
---

Thanks for the review!

> Is there a reason for not unsetting `advice.detachedHead` at the
> end of the test?

done

I did not consider to clean up after myself... what a selfish world!

Stefan

 builtin/checkout.c |  2 +-
 t/t2020-checkout-detach.sh | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8d852d4..85408b1 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -658,7 +658,7 @@ static void update_refs_for_switch(const struct 
checkout_opts *opts,
update_ref(msg.buf, "HEAD", new->commit->object.oid.hash, NULL,
   REF_NODEREF, UPDATE_REFS_DIE_ON_ERR);
if (!opts->quiet) {
-   if (old->path && advice_detached_head)
+   if (old->path && advice_detached_head && 
!opts->force_detach)
detach_advice(new->name);
describe_detached_head(_("HEAD is now at"), 
new->commit);
}
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
index 5d68729..3ee60fb 100755
--- a/t/t2020-checkout-detach.sh
+++ b/t/t2020-checkout-detach.sh
@@ -163,4 +163,18 @@ test_expect_success 'tracking count is accurate after 
orphan check' '
test_i18ncmp expect stdout
 '
 
+test_expect_success 'no advice given for explicit detached head state' '
+   git config advice.detachedHead false &&
+   git checkout child &&
+   git checkout --detach HEAD >expect &&
+   git config advice.detachedHead true &&
+   git checkout child &&
+   git checkout --detach HEAD >actual &&
+   test_cmp expect actual &&
+   git checkout child &&
+   git checkout HEAD >actual &&
+   ! test_cmp expect actual &&
+   git config --unset advice.detachedHead
+'
+
 test_done
-- 
2.9.2.730.g46b112d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 11/12] doc: revisions: show revision expansion in examples

[Marc Branchaud]

On 2016-08-12 03:07 AM, Philip Oakley wrote:

The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.

Sort the examples and fix the alignment for those unaffected
in the next commit.

Signed-off-by: Philip Oakley 
---
new
Cc: Jakub Narębski 
---
 Documentation/revisions.txt | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 70864d5..ac7dd8e 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -326,16 +326,23 @@ Revision Range Summary
   as giving commit '' and then all its parents prefixed with
   '{caret}' to exclude them (and their ancestors).

-Here are a handful of examples:
+Here are a handful of examples using the Loeliger illustration above:

+   Args   Expansion   Selection


I think "Result" would be better than "Selection" here.

Also, shouldn't all the ^ in these examples be {caret}?  (I likely just 
don't understand the rationale for using {caret} in some places and ^ in 
others...)



DG H D
D F  G H I J D F
^G D H D
^D B E I J F B
-   B..C C
-   B...CG H D E B C
+   B..C   = ^B C  C
+   B...C  = B ^F CG H D E B C
^D B C   E I J F B C
CI J F C
-   C^@  I J F
-   C^!  C
-   F^! DG H D F
+   C^@= C^1


I have a mixed reaction to showing this "C^1" expansion, and the "B^1 
B^2 B^3" one as well.  I see the appeal of showing the parent notation, 
but really that was already explained to death in the first section. 
Here it's distracting.  I think it's clearer for the reader to remove 
these expansions and just use the node names from the illustration.



+  = F I J F
+   B^@= B^1 B^2 B^3
+  = D E F D G H E F I J
+   C^!= C ^C^1


I think this expansion might be better expressed as "C ^C^@".  It'll be 
the same for "B^! = B ^B^@" as well, which demonstrates a nice 
consistency and also helps to emphasize the meaning of the ^@ notation.



+  = C ^F  C
+   B^! = B ^B^1 ^B^2 ^B^3
+   = B ^D ^E ^F   B


The layout of these last two lines doesn't match the others.  They 
should be:


   B^!= B ^B^1 ^B^2   ^B^3
  = B ^D ^E ^FB

I see that the next patch fixes the layout of the unchanged examples, 
but it leaves these two unaligned.


M.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 06/12] doc: revisions: single vs multi-parent notation comparison

[Marc Branchaud]

On 2016-08-12 03:07 AM, Philip Oakley wrote:

Signed-off-by: Philip Oakley 
---
new
Junio's final comment 
https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/
---
 Documentation/revisions.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0b5044d..934d071 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -284,6 +284,10 @@ The 'r1{caret}@' notation means all parents of 'r1'.
 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
 This is the single commit 'r1', if standalone.

+While '{caret}' was about specifying a single commit parent, these
+two notations consider all its parents. For example you can say
+'HEAD{caret}2^@', however you cannot say 'HEAD{caret}@{caret}2'.


That ^ should be {caret}, right?

M.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 05/12] doc: revisions: extra clarification of ^! notation effects

[Marc Branchaud]

On 2016-08-12 03:07 AM, Philip Oakley wrote:

Signed-off-by: Philip Oakley 
---
new
Cc: Jakub Narębski 
https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/
---
 Documentation/revisions.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 3da0083..0b5044d 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -281,7 +281,8 @@ for naming a set that is formed by a commit and its parent 
commits.

 The 'r1{caret}@' notation means all parents of 'r1'.

-'r1{caret}!' includes commit 'r1' but excludes all of its parents.
+'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.


This sentence should start with "The".


+This is the single commit 'r1', if standalone.


That reads awkwardly to me.  Perhaps

By itself, this notation denotes the single commit 'r1'.

?

M.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 04/12] doc: revisions: give headings for the two and three dot notations

[Marc Branchaud]

On 2016-08-12 03:07 AM, Philip Oakley wrote:

While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).

We do not quote the notation within the headings as the asciidoc ->
docbook -> groff man viewer toolchain, particularly the docbook-groff
step, does not cope with two font changes, failing to return the heading
font to bold after the quotation of the notation.


Looks good --thanks!

M.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANN] Pro Git Reedited 2nd Edition

[Jon Forrest]

On 8/12/16 6:11 AM, Sitaram Chamarty wrote:


At present gitolite is -- AFAIK -- the only "pure server side", "no GUI"
solution for access control, and has some interesting features that more
"GUI" solutions may not.  It is also (again, AFAIK) used by kernel.org,
Fedora, Gentoo, and several other open source projects as well as many
enterprises.

If you're ok with adding that, I'd be happy to supply some text for your
consideration.


I appreciate your offer and I don't disagree with what you're
suggesting, but my goal, for now at least, is to keep the same coverage 
as upstream.


If they add something about Gitolite to their next edition, then
I will also.

Cordially,
Jon Forrest

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Interested in purchasing another product

[Marco Plujm]

Hello,

Have a nice day!

I am very interested in purchasing another product. Kindly send your latest 
catalog. Also what is your delivery time or FOB, and payment terms warranty?


Thanks and Best Regards,
Mr. Marco Plujm.
___
MARCO MEGA TRADING CO.,LTD
Washington, DC 20052
E-mail; i...@marcomegatrading.com /
marcopl...@gmail.com
Phone: (+1) 703-684-5885
Fax: (+1) 703-684-0644
United State

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANN] Pro Git Reedited 2nd Edition

[Sitaram Chamarty]

On 07/24/2016 09:37 AM, Jon Forrest wrote:
> This an announcement of Pro Git Reedited 2nd Edition, which is
> a substantial edit of Chacon and Straub's Pro Git 2nd Edition.
> I spent a lot of time tightening it up and maybe clearing
> up some explanations.
> 
> The pdf is downloadable at:
> https://drive.google.com/open?id=0B-Llso12P94-Ujg5Z1dhWUhhMm8
> 
> The complete self-contained HTML is at:
> https://drive.google.com/file/d/0B-Llso12P94-U3g1aDBRWjk1Sk0
> 
> The sources for this book are at:
> https://github.com/nobozo/progit2
> 
> I welcome comments.

Hi

While I'm kinda happy to see the chapter on gitolite gone (for reasons
of difficulty in keeping it current at that time), I humbly suggest that
a brief mention of gitolite somewhere in the chapter on "git on the
server" would be useful.

At present gitolite is -- AFAIK -- the only "pure server side", "no GUI"
solution for access control, and has some interesting features that more
"GUI" solutions may not.  It is also (again, AFAIK) used by kernel.org,
Fedora, Gentoo, and several other open source projects as well as many
enterprises.

If you're ok with adding that, I'd be happy to supply some text for your
consideration.

regards
sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] t5520: become resilient to GETTEXT_POISON

[Vasco Almeida]

Use test_i18ngrep function instead of grep for grepping strings.

Signed-off-by: Vasco Almeida 
---
 t/t5520-pull.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 6ad37b5..5518445 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -270,7 +270,7 @@ test_expect_success '--rebase with conflicts shows advice' '
test_tick &&
git commit -m "Create conflict" seq.txt &&
test_must_fail git pull --rebase . seq 2>err >out &&
-   grep "When you have resolved this problem" out
+   test_i18ngrep "When you have resolved this problem" out
 '
 
 test_expect_success 'failed --rebase shows advice' '
@@ -284,7 +284,7 @@ test_expect_success 'failed --rebase shows advice' '
git checkout -f -b fails-to-rebase HEAD^ &&
test_commit v2-without-cr file "2" file2-lf &&
test_must_fail git pull --rebase . diverging 2>err >out &&
-   grep "When you have resolved this problem" out
+   test_i18ngrep "When you have resolved this problem" out
 '
 
 test_expect_success '--rebase fails with multiple branches' '
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] t7411: become resilient to GETTEXT_POISON

[Vasco Almeida]

The concerned test greps the error message in git_parse_source() which
contains "bad config line %d in submodule-blob %s".

Signed-off-by: Vasco Almeida 
---
 t/t7411-submodule-config.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t7411-submodule-config.sh b/t/t7411-submodule-config.sh
index 400e2b1..47562ce 100755
--- a/t/t7411-submodule-config.sh
+++ b/t/t7411-submodule-config.sh
@@ -89,7 +89,7 @@ test_expect_success 'error message contains blob reference' '
HEAD b \
HEAD submodule \
2>actual_err &&
-   grep "submodule-blob $sha1:.gitmodules" actual_err >/dev/null
+   test_i18ngrep "submodule-blob $sha1:.gitmodules" actual_err 
>/dev/null
)
 '
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] t3404: become resilient to GETTEXT_POISON

[Vasco Almeida]

The concerned test greps the output of exit_with_patch() in
git-rebase--interactive.sh script.

Signed-off-by: Vasco Almeida 
---
 t/t3404-rebase-interactive.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 197914b..597e94e 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1286,7 +1286,7 @@ test_expect_success 'rebase -i --gpg-sign=' '
set_fake_editor &&
FAKE_LINES="edit 1" git rebase -i --gpg-sign="\"S I Gner\"" HEAD^ \
>out 2>err &&
-   grep "$SQ-S\"S I Gner\"$SQ" err
+   test_i18ngrep "$SQ-S\"S I Gner\"$SQ" err
 '
 
 test_done
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] checkout: do not mention detach advice for explicit --detach option

[Remi Galan Alfonso]

Stefan Beller  writes:
> +test_expect_success 'no advice given for explicit detached head state' '
> +git config advice.detachedHead false &&
> +git checkout child &&
> +git checkout --detach HEAD >expect &&
> +git config advice.detachedHead true &&

Is there a reason for not unsetting `advice.detachedHead` at the
end of the test?

Thanks,
Rémi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Mapping old gmane numbers to existing amil servers?

[Philip Oakley]

From: "Eric Wong" 
Sent: Thursday, August 11, 2016 11:26 PM

Philip Oakley  wrote:

The raw download works. My home ISP is currently blocking your email for
some reason, though I do see it at my work - my iee.org alias is via my
professional body which duplicates the email when it relays it.


Hmm, do other emails from other users get blocked?
I wonder if it's lack of DKIM (which gets invalidated by the
list sig vger appends) or something else...


Not really sure. My professional body's alias service now uses EveryCloud 
for its antispam. initially it also blocked your mails as 'spam', by the 
daily notification allows me to white list that. However the forwarded 
emails go to both home & work, and only the home ISP (cheap but annoying) 
then has no white list mechanism and no way of seeing what they binned.





On thing I did note on the web display of the threads is that it would be
good to have a leader of " . . . . . `" so that one can count the level 
of

indent, and see the alignments via the columns of dots.

When looking at
https://public-inbox.org/git/0648000B273C412AB7140AE959EBC99A%40PhilipOakley/
I had difficulty working out which email the last 4 were replying to.


https://public-inbox.org/git/0648000B273C412AB7140AE959EBC99A%40PhilipOakley/
So, right now, it's:

2016-07-20 21:10   ` [PATCH v4 8/8] doc: revisions - clarify 
reachability examples Philip Oakley

2016-07-20 22:22   ` Junio C Hamano
2016-08-11 21:50   ` [PATCH v5 00/12] Update git revisions 
Philip Oakley
2016-08-11 21:50 ` [PATCH v5 01/12] doc: use 'symmetric 
difference' consistently Philip Oakley

2016-06-25 19:49   ` Junio C Hamano
2016-06-27 13:37 ` Philip Oakley
2016-06-27 15:08   ` Junio C Hamano
2016-06-27 15:39 ` Philip Oakley

And you would rather see something like:

2016-07-20 21:10   .   ` [PATCH v4 8/8] doc: revisions - clarify 
reachability examples Philip Oakley

2016-07-20 22:22   .   ` Junio C Hamano
2016-08-11 21:50   .   ` [PATCH v5 00/12] Update git revisions 
Philip Oakley
2016-08-11 21:50   . ` [PATCH v5 01/12] doc: use 'symmetric 
difference' consistently Philip Oakley

2016-06-25 19:49   ` Junio C Hamano
2016-06-27 13:37 ` Philip Oakley
2016-06-27 15:08   ` Junio C Hamano
2016-06-27 15:39 ` Philip Oakley



Not quite, something like:
2016-07-20 21:10   . . . . ` [PATCH v4 8/8] doc: revisions - clarify 
reachability examples Philip Oakley

2016-07-20 22:22   . . . . ` Junio C Hamano
2016-08-11 21:50   . . . . ` [PATCH v5 00/12] Update git revisions 
Philip Oakley
2016-08-11 21:50   . . . . . ` [PATCH v5 01/12] doc: use 'symmetric 
difference' consistently Philip Oakley

2016-06-25 19:49   ` Junio C Hamano
2016-06-27 13:37 ` Philip Oakley
2016-06-27 15:08   ` Junio C Hamano
2016-06-27 15:39 ` Philip Oakley


I haven't filled in the last ones because there are no matching follow on 
replies, e.g to Junio' s 2016-06-25 19:49 message.

(I may not have put in enough of the lead either)
However for ease of formatting I guess that simply setting the indent to be 
'. ' rather than '  ' (both 2 chars) would create the impression of the 
messages being on an indent grid


If rather than looking at those below junio's reply, you try and look at 
which message he was replying to, it's very hard (It's more than a full 
screen scroll up), hance the request for the alignment 'column of dots'. I 
think he was replying to my 2016-06-25 13:50, but it's not easy to be sure.



?

Actually, my initial inclination was to use the '|' character
which is what mutt does

2016-07-20 21:10   |   } [PATCH v4 8/8] doc: revisions - clarify 
reachability examples Philip Oakley

2016-07-20 22:22   |   } Junio C Hamano
2016-08-11 21:50   |   ` [PATCH v5 00/12] Update git revisions 
Philip Oakley
2016-08-11 21:50   | ` [PATCH v5 01/12] doc: use 'symmetric 
difference' consistently Philip Oakley

2016-06-25 19:49   ` Junio C Hamano
2016-06-27 13:37 ` Philip Oakley
2016-06-27 15:08   ` Junio C Hamano
2016-06-27 15:39 ` Philip Oakley

It should be doable, and the '`' immediately following the last
'|' probably ought to be a link to the parent, too.



I feel that the '¦' style chars will fill the screen too much (with '.' 
being the minimalist I can think of), but it's a personal choice.



I would also like to use '}' (as above) or '+' where mutt would
use "├─>" or just '├', but I don't think I can introduce multibyte
chars without causing problems for some users.

Anyways, it's definitely on my ever-growing todo list.


(Wow, it is refreshing to be a "web designer" who can live
entirely in a terminal without relying on screenshots :D)




Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a 

Re: t0027 racy?

[Jeff King]

On Thu, Aug 11, 2016 at 06:58:12PM +, Torsten Bögershausen wrote:

> commit 3754404d3d1ea4a0cbbed4986cc4ac1b5fe6b66e
> Author: Torsten Bögershausen 
> Date:   Thu Aug 11 18:47:29 2016 +0200
> 
> t0027: Correct raciness in NNO test
> 
> When a non-reversible CRLF conversion is done in "git add",
> a warning is printed on stderr.
> 
> The commit_chk_wrnNNO() function  in t0027 was written to test this,
> but did the wrong thing: Instead of looking at the warning
> from "git add", it looked at the warning from "git commit".

Maybe add:

  This is racy because "git commit" may not have to do CRLF conversion
  at all if it can use the sha1 value from the index (which depends on
  whether "add" and "commit" run in a single second).

> Thanks to Jeff King  for analizing t0027.
> Reporyed-By: Johannes Schindelin 

s/analizing/analyzing/; s/Reporyed/Reported/

> diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
> index 2860d2d..6e44382 100755
> --- a/t/t0027-auto-crlf.sh
> +++ b/t/t0027-auto-crlf.sh
> @@ -119,8 +119,7 @@ commit_chk_wrnNNO () {
>   fname=${pfx}_$f.txt &&
>   cp $f $fname &&
>   printf Z >>"$fname" &&
> - git -c core.autocrlf=$crlf add $fname 2>/dev/null &&
> - git -c core.autocrlf=$crlf commit -m "commit_$fname" $fname 
> >"${pfx}_$f.err" 2>&1
> + git -c core.autocrlf=$crlf add $fname 2>"${pfx}_$f.err"
>   done

So this is the meat of the fix.

> @@ -394,11 +393,10 @@ test_expect_success 'commit files attr=crlf' '
>  
>  # attrLFCRLF  CRLFmixLF   
> LF_mix_CR   CRLFNUL
>  commit_chk_wrnNNO ""  ""  false   """"""  "" 
>  ""
> -commit_chk_wrnNNO ""  ""  trueLF_CRLF   """"  "" 
>  ""
> +commit_chk_wrnNNO ""  ""  true""""""  "" 
>  ""
>  commit_chk_wrnNNO ""  ""  input   """"""  "" 
>  ""
> -
> -commit_chk_wrnNNO "auto"  ""  false   "$WILC"   """"  "" 
>  ""
> -commit_chk_wrnNNO "auto"  ""  trueLF_CRLF   """"  "" 
>  ""
> +commit_chk_wrnNNO "auto"  ""  false   """"""  "" 
>  ""
> +commit_chk_wrnNNO "auto"  ""  true""""""  "" 
>  ""
>  commit_chk_wrnNNO "auto"  ""  input   """"""  "" 
>  ""

I am not sure I understand why this reordering is necessary, but I guess
it's to group like things together in a single commit? Might be worth a
mention in the commit message.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git difftool and git mergetool aren't returning errors when the tool has issues

[Tom Tanner (BLOOMBERG/ LONDON)]

For instance, if you set your diff/mergetool to meld and you don't have it 
installed:
> git difftool

Viewing (1/1): 'blah'
Launch 'meld' [Y/n]? y
/home/ttanner/bin/meld[8]: /opt/swt/bin/meld: not found
> echo $?
0

> /home/ttanner/bin/meld
/home/ttanner/bin/meld[8]: /opt/swt/bin/meld: not found
> echo $?
127

or
> env DISPLAY=wibble git difftool

Viewing (1/1): blah'
Launch 'xxdiff' [Y/n]? y
xxdiff: cannot connect to X server wibble
> echo $?
0
> env DISPLAY=wibble xxdiff thisfile thatfile
xxdiff: cannot connect to X server wibble
> echo $?
1
and this one (with DISPLAY unset because it was being run elsewhere)
> git mergtool
Normal merge conflict for 'blah: 
{local}: modified file 
{remote}: modified file 
Could not find ':' in DISPLAY: yeah, right 
XIO: fatal IO error 73 (Connection reset by peer) on X server "server:66.0" 
after 0 requests (0 known processed) with 0 events remaining. 
> echo $?
0
which last looked like a successful merge to a script, because it returned 
0.N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf

[PATCH v5 00/12] Update git revisions

[Philip Oakley]

[2nd attempt : ISP troubles]

This has grown like topsy from a little two patch series that tried to
name the 2-dots notation [1] into this extended set of tweaks.

As documentation can be rather personal, I've split out each small change
so each can be individually justified.

Since V4, I've confirmed that the format breaking issue is that we cannot
quote code in headings in the man page layout - ultimately it's a docbook
decision, and follows the line of analysis Peff identified (see commentary
in the patch).

In addition the multi-parent notations have been clarified and extended.

Thus the old patch 4 has been split into three. The first three patches are
unchanged. The following 4 patches are also unchanged.

Finally, at the end an extra 2 patches are added to build up the examples by
including details of the notation expansions.

This updates po/range-doc (2016-07-20) 8 commits.

Hopefully my updated workflow will get the right patches to the right people.

[1] 
https://public-inbox.org/git/0648000B273C412AB7140AE959EBC99A%40PhilipOakley/

Philip Oakley (12):
  doc: use 'symmetric difference' consistently
  doc: revisions - name the left and right sides
  doc: show the actual left, right, and boundary marks
  doc: revisions: give headings for the two and three dot notations
  doc: revisions: extra clarification of ^! notation effects
  doc: revisions: single vs multi-parent notation comparison
  doc: gitrevisions - use 'reachable' in page description
  doc: gitrevisions - clarify 'latter case' is revision walk
  doc: revisions  - define `reachable`
  doc: revisions - clarify reachability examples
  doc: revisions: show revision expansion in examples
  doc: revisions: sort examples and fix alignment of the unchanged

 Documentation/gitk.txt |   2 +-
 Documentation/gitrevisions.txt |   6 +-
 Documentation/pretty-formats.txt   |   2 +-
 Documentation/rev-list-options.txt |   4 +-
 Documentation/revisions.txt| 121 +++--
 5 files changed, 84 insertions(+), 51 deletions(-)

-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 01/12] doc: use 'symmetric difference' consistently

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
unchanged
---
 Documentation/gitk.txt | 2 +-
 Documentation/rev-list-options.txt | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 6ade002..6c3eb15 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -70,7 +70,7 @@ linkgit:git-rev-list[1] for a complete list.
 
 --left-right::
 
-   Mark which side of a symmetric diff a commit is reachable
+   Mark which side of a symmetric difference a commit is reachable
from.  Commits from the left side are prefixed with a `<`
symbol and those from the right with a `>` symbol.
 
diff --git a/Documentation/rev-list-options.txt 
b/Documentation/rev-list-options.txt
index 4f009d4..6dc0bb0 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -225,7 +225,7 @@ excluded from the output.
 
 --left-only::
 --right-only::
-   List only commits on the respective side of a symmetric range,
+   List only commits on the respective side of a symmetric difference,
i.e. only those which would be marked `<` resp. `>` by
`--left-right`.
 +
@@ -766,7 +766,7 @@ ifdef::git-rev-list[]
 endif::git-rev-list[]
 
 --left-right::
-   Mark which side of a symmetric diff a commit is reachable from.
+   Mark which side of a symmetric difference a commit is reachable from.
Commits from the left side are prefixed with `<` and those from
the right with `>`.  If combined with `--boundary`, those
commits are prefixed with `-`.
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 03/12] doc: show the actual left, right, and boundary marks

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
Found while checking the 'symmetric difference' documentation
Unchanged from v4
---
 Documentation/pretty-formats.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 29b19b9..10719e1 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -166,7 +166,7 @@ endif::git-rev-list[]
   respecting the `auto` settings of the former if we are going to a
   terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
   on the next placeholders until the color is switched again.
-- '%m': left, right or boundary mark
+- '%m': left (`<`), right (`>`) or boundary (`-`) mark
 - '%n': newline
 - '%%': a raw '%'
 - '%x00': print a byte from a hex code
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 05/12] doc: revisions: extra clarification of ^! notation effects

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
new
Cc: Jakub Narębski 
https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/
---
 Documentation/revisions.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 3da0083..0b5044d 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -281,7 +281,8 @@ for naming a set that is formed by a commit and its parent 
commits.
 
 The 'r1{caret}@' notation means all parents of 'r1'.
 
-'r1{caret}!' includes commit 'r1' but excludes all of its parents.
+'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
+This is the single commit 'r1', if standalone.
 
 Revision Range Summary
 --
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 07/12] doc: gitrevisions - use 'reachable' in page description

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
unchanged
---
 Documentation/gitrevisions.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt
index e903eb7..33039c6 100644
--- a/Documentation/gitrevisions.txt
+++ b/Documentation/gitrevisions.txt
@@ -15,8 +15,8 @@ DESCRIPTION
 
 Many Git commands take revision parameters as arguments. Depending on
 the command, they denote a specific commit or, for commands which
-walk the revision graph (such as linkgit:git-log[1]), all commits which can
-be reached from that commit. In the latter case one can also specify a
+walk the revision graph (such as linkgit:git-log[1]), all commits which are
+reachable from that commit. In the latter case one can also specify a
 range of revisions explicitly.
 
 In addition, some Git commands (such as linkgit:git-show[1]) also take
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 04/12] doc: revisions: give headings for the two and three dot notations

[Philip Oakley]

While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).

We do not quote the notation within the headings as the asciidoc ->
docbook -> groff man viewer toolchain, particularly the docbook-groff
step, does not cope with two font changes, failing to return the heading
font to bold after the quotation of the notation.

Signed-off-by: Philip Oakley 
---
Cc: Marc Branchaud 
Cc: Jeff King 

ref email

Jeff King wrote on 12 July 2016 23:12
> On Tue, Jul 12, 2016 at 10:41:35PM +0100, Philip Oakley wrote:
> > Marc Branchaud  12 July 2016 14:44 noted
> > > +The '{caret}' (caret) notation
> > > +~~~
> > >   To exclude commits reachable from a commit, a prefix '{caret}'
> > >   notation is used.  E.g. '{caret}r1 r2' means commits reachable
> > >   from 'r2' but exclude the ones reachable from 'r1'.
> >
> > All of these headings render poorly in the manpage, at least for me
> > (Ubuntu 16.04).  Only the first word appears in bold; the '-quoted text
> > is not bold but underlined, and the rest of the header is plain.
>
> Which doc package is that with? It had formatted OK for the html web pages.

I get the same with:

  make gitrevisions.7
  man -l gitrevisions.7

Asciidoc 8.6.9, docbook-xsl 4.5 if it matters.

Rendering single-quotes as underline is normal in this case (though it's
not great for punctuation like this, as it kind of blends with the dots;
I know we use it elsewhere in this document, though).  The failure to
continue the bold through the end of line looks like a bug, though.

The generated XML (from asciidoc) looks reasonable:

  The .. (two-dot) range notation

The roff looks like:

  .SS "The \fI\&.\&.\fR (two\-dot) range notation"

The "\fR" switches us back to "Roman" from italics, which is presumably
the problem. We really want to say "switch back what we were using
before \fI".

Switching it to "\fP" fixes it, but it's not clear to me if that's
actually portable, or a groff-ism. I don't know roff very well and
documentation seems to be quite hard to find. So it's either a bug in
docbook, or an intentional decision they've made because roff can't
portably do better. I'm not sure which.

-Peff

The docbook folks have confirmed that \fP would only work across one
level, so they cannot use it for their XSLT conversion which must be
multi-level, so they always return to the default font.
-Philip
---
 Documentation/revisions.txt | 58 -
 1 file changed, 36 insertions(+), 22 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 6e9cd41..3da0083 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -242,35 +242,49 @@ specifying a single revision with the notation described 
in the
 previous section means the set of commits reachable from that
 commit, following the commit ancestry chain.
 
-To exclude commits reachable from a commit, a prefix '{caret}'
-notation is used.  E.g. '{caret}r1 r2' means commits reachable
-from 'r2' but exclude the ones reachable from 'r1'.
-
-This set operation appears so often that there is a shorthand
-for it.  When you have two commits 'r1' and 'r2' (named according
-to the syntax explained in SPECIFYING REVISIONS above), you can ask
-for commits that are reachable from r2 excluding those that are reachable
-from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'.
-
-A similar notation 'r1\...r2' is called symmetric difference
-of 'r1' and 'r2' and is defined as
-'r1 r2 --not $(git merge-base --all r1 r2)'.
-It is the set of commits that are reachable from either one of
-'r1' (left side) or 'r2' (right side) but not from both.
-
-In these two shorthands, you can omit one end and let it default to HEAD.
+Commit Exclusions
+~
+
+'{caret}' (caret) Notation::
+ To exclude commits reachable from a commit, a prefix '{caret}'
+ notation is used.  E.g. '{caret}r1 r2' means commits reachable
+ from 'r2' but exclude the ones reachable from 'r1'.
+
+Dotted Range Notations
+~~
+
+The '..' (two-dot) Range Notation::
+ The '{caret}r1 r2' set operation appears so often that there is a shorthand
+ for it.  When you have two commits 'r1' and 'r2' (named according
+ to the syntax explained in SPECIFYING REVISIONS above), you can ask
+ for commits that are reachable from r2 excluding those that are reachable
+ from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'.
+
+The '...' (three dot) Symmetric Difference Notation::
+ A similar notation 'r1\...r2' is called symmetric difference
+ of 'r1' and 'r2' and is defined as
+ 'r1 r2 --not $(git merge-base --all r1 r2)'.
+ It is the set of commits that are reachable from either one of
+ 'r1' (left side) or 'r2' (right side) but not from both.
+
+In these two shorthand notations, you can 

[PATCH v5 02/12] doc: revisions - name the left and right sides

[Philip Oakley]

The terms left and right side originate from the symmetric
difference. Name them there.

Signed-off-by: Philip Oakley 
---
unchanged
---
 Documentation/revisions.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 19314e3..6e9cd41 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -256,7 +256,7 @@ A similar notation 'r1\...r2' is called symmetric difference
 of 'r1' and 'r2' and is defined as
 'r1 r2 --not $(git merge-base --all r1 r2)'.
 It is the set of commits that are reachable from either one of
-'r1' or 'r2' but not from both.
+'r1' (left side) or 'r2' (right side) but not from both.
 
 In these two shorthands, you can omit one end and let it default to HEAD.
 For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 12/12] doc: revisions: sort examples and fix alignment of the unchanged

[Philip Oakley]

The previous commit adjusted the column alignment for revision
examples which show expansion. Fix the unchanged examples and sort
those that show expansions to the end of the list.

Signed-off-by: Philip Oakley 
---
new
---
 Documentation/revisions.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index ac7dd8e..8d65986 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -329,14 +329,14 @@ Revision Range Summary
 Here are a handful of examples using the Loeliger illustration above:
 
Args   Expansion   Selection
-   DG H D
-   D F  G H I J D F
-   ^G D H D
-   ^D B E I J F B
+   D  G H D
+   D FG H I J D F
+   ^G D   H D
+   ^D B   E I J F B
+   ^D B C E I J F B C
+   C  I J F C
B..C   = ^B C  C
B...C  = B ^F CG H D E B C
-   ^D B C   E I J F B C
-   CI J F C
C^@= C^1
   = F I J F
B^@= B^1 B^2 B^3
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 08/12] doc: gitrevisions - clarify 'latter case' is revision walk

[Philip Oakley]

The prior sentence has too many clauses for easy parsing.
Replace 'the latter case' with a direct quote.

Signed-off-by: Philip Oakley 
---
unchanged
---
 Documentation/gitrevisions.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt
index 33039c6..27dec5b 100644
--- a/Documentation/gitrevisions.txt
+++ b/Documentation/gitrevisions.txt
@@ -16,8 +16,8 @@ DESCRIPTION
 Many Git commands take revision parameters as arguments. Depending on
 the command, they denote a specific commit or, for commands which
 walk the revision graph (such as linkgit:git-log[1]), all commits which are
-reachable from that commit. In the latter case one can also specify a
-range of revisions explicitly.
+reachable from that commit. For commands that walk the revision graph one can
+also specify a range of revisions explicitly.
 
 In addition, some Git commands (such as linkgit:git-show[1]) also take
 revision parameters which denote other objects than commits, e.g. blobs
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 11/12] doc: revisions: show revision expansion in examples

[Philip Oakley]

The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.

Sort the examples and fix the alignment for those unaffected
in the next commit.

Signed-off-by: Philip Oakley 
---
new
Cc: Jakub Narębski 
---
 Documentation/revisions.txt | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 70864d5..ac7dd8e 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -326,16 +326,23 @@ Revision Range Summary
   as giving commit '' and then all its parents prefixed with
   '{caret}' to exclude them (and their ancestors).
 
-Here are a handful of examples:
+Here are a handful of examples using the Loeliger illustration above:
 
+   Args   Expansion   Selection
DG H D
D F  G H I J D F
^G D H D
^D B E I J F B
-   B..C C
-   B...CG H D E B C
+   B..C   = ^B C  C
+   B...C  = B ^F CG H D E B C
^D B C   E I J F B C
CI J F C
-   C^@  I J F
-   C^!  C
-   F^! DG H D F
+   C^@= C^1
+  = F I J F
+   B^@= B^1 B^2 B^3
+  = D E F D G H E F I J
+   C^!= C ^C^1
+  = C ^F  C
+   B^! = B ^B^1 ^B^2 ^B^3
+   = B ^D ^E ^F   B
+   F^! D  = F ^I ^J D G H D F
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 09/12] doc: revisions - define `reachable`

[Philip Oakley]

Do not self-define `reachable`, which can lead to misunderstanding.
Instead define `reachability` explictly.

Signed-off-by: Philip Oakley 
---
unchanged
---
 Documentation/revisions.txt | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 934d071..238be45 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -237,10 +237,16 @@ SPECIFYING RANGES
 -
 
 History traversing commands such as `git log` operate on a set
-of commits, not just a single commit.  To these commands,
-specifying a single revision with the notation described in the
-previous section means the set of commits reachable from that
-commit, following the commit ancestry chain.
+of commits, not just a single commit.
+
+For these commands,
+specifying a single revision, using the notation described in the
+previous section, means the set of commits `reachable` from the given
+commit.
+
+A commit's reachable set is the commit itself and the commits in
+its ancestry chain.
+
 
 Commit Exclusions
 ~
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 10/12] doc: revisions - clarify reachability examples

[Philip Oakley]

 For the r1..r2 case, the exclusion of r1, rather than inclusion of r2,
 would be the unexpected case in natural language for a simple linear
 development, i.e. start..end excludes start.

Signed-off-by: Philip Oakley 
---
unchanged
---
 Documentation/revisions.txt | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 238be45..70864d5 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -254,7 +254,8 @@ Commit Exclusions
 '{caret}' (caret) Notation::
  To exclude commits reachable from a commit, a prefix '{caret}'
  notation is used.  E.g. '{caret}r1 r2' means commits reachable
- from 'r2' but exclude the ones reachable from 'r1'.
+ from 'r2' but exclude the ones reachable from 'r1' (i.e. 'r1' and
+ its ancestors).
 
 Dotted Range Notations
 ~~
@@ -298,12 +299,12 @@ Revision Range Summary
 --
 
 ''::
-   Include commits that are reachable from (i.e. ancestors of)
-   .
+   Include commits that are reachable from  (i.e.  and its
+   ancestors).
 
 '{caret}'::
-   Exclude commits that are reachable from (i.e. ancestors of)
-   .
+   Exclude commits that are reachable from  (i.e.  and its
+   ancestors).
 
 '..'::
Include commits that are reachable from  but exclude
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 06/12] doc: revisions: single vs multi-parent notation comparison

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
new
Junio's final comment 
https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/
---
 Documentation/revisions.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0b5044d..934d071 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -284,6 +284,10 @@ The 'r1{caret}@' notation means all parents of 'r1'.
 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
 This is the single commit 'r1', if standalone.
 
+While '{caret}' was about specifying a single commit parent, these
+two notations consider all its parents. For example you can say
+'HEAD{caret}2^@', however you cannot say 'HEAD{caret}@{caret}2'.
+
 Revision Range Summary
 --
 
-- 
2.9.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html