Re: [PATCH v3 0/3] deprecate git stash save

[Jeff King]

On Mon, Oct 23, 2017 at 10:19:38AM +0900, Junio C Hamano wrote:

> > -   This option is deprecated in favour of 'git stash push'.
> > +   This option is deprecated in favour of 'git stash push'.  It
> > +   differs from "stash push" in that it cannot take pathspecs,
> > +   and any non-option arguments form the message.
> 
> Every time I saw this line, I misread s/form/from/ and got
> confused.

We could reverse the order:

   ...and the message is taken from any non-option arguments.

-Peff

Re: [PATCH v3 0/4] status: add option to show ignored files differently

[Junio C Hamano]

Jameson Miller  writes:

> Jameson Miller (4):
>   status: add option to show ignored files differently
>   status: report matching ignored and normal untracked
>   status: document options to show matching ignored files
>   status: test --ignored=matching

Thanks, queued.

Re: [PATCH v3 1/4] status: add option to show ignored files differently

[Junio C Hamano]

Jameson Miller  writes:

> Teach the status command more flexibility in how ignored files are
> reported. Currently, the reporting of ignored files and untracked
> files are linked. You cannot control how ignored files are reported
> independently of how untracked files are reported (i.e. `all` vs
> `normal`). This makes it impossible to show untracked files with the
> `all` option, but show ignored files with the `normal` option.
> 
> This work 1) adds the ability to control the reporting of ignored
> files independently of untracked files and 2) introduces the concept
> of status reporting ignored paths that explicitly match an ignored
> pattern. ...
>
> When status is set to report matching ignored files, it has the
> following behavior. Ignored files and directories that explicitly
> match an exclude pattern are reported. If an ignored directory matches
> an exclude pattern, then the path of the directory is returned. If a
> directory does not match an exclude pattern, but all of its contents
> are ignored, then the contained files are reported instead of the
> directory.

Thanks for an updated log message.  Very nicely explained.

> +static void handle_ignored_arg(struct wt_status *s)
> +{
> + if (!ignored_arg)
> + ; /* default already initialized */
> + else if (!strcmp(ignored_arg, "traditional"))
> + s->show_ignored_mode = SHOW_TRADITIONAL_IGNORED;
> + else if (!strcmp(ignored_arg, "no"))
> + s->show_ignored_mode = SHOW_NO_IGNORED;
> + else if (!strcmp(ignored_arg, "matching"))
> + s->show_ignored_mode = SHOW_MATCHING_IGNORED;
> + else
> + die(_("Invalid ignored mode '%s'"), ignored_arg);
> +}
>  
>  static void handle_untracked_files_arg(struct wt_status *s)
>  {
> @@ -1363,8 +1376,10 @@ int cmd_status(int argc, const char **argv, const char 
> *prefix)
> N_("mode"),
> N_("show untracked files, optional modes: all, normal, no. 
> (Default: all)"),
> PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
> - OPT_BOOL(0, "ignored", _ignored_in_status,
> -  N_("show ignored files")),
> + { OPTION_STRING, 0, "ignored", _arg,
> +   N_("mode"),
> +   N_("show ignored files, optional modes: traditional, 
> matching, no. (Default: traditional)"),
> +   PARSE_OPT_OPTARG, NULL, (intptr_t)"traditional" },

We used to use "show_ignored_in_status" variable that can be either
0 (when no --ignored is given, or an explicit --no-ignored is given,
on the command line) or 1 (when --ignored is given on the command
line).

We still allow "--ignored" without value for backward compatibility,
but 

$ git status -uall --ignored \*.c

may trigger die() from handle_ignored_arg().  I wonder if this is
something we care about.

... goes and digs ...

OK, because of PARSE_OPT_OPTARG, the above is safe; "*.c" is not
mistaken as the value given to the --ignored option.  It also means
that

$ git status -uno --ignored matching

would not mean what a naïve reader may expect and does not error
out, even though

$ git status -uno --ignored=matching

would.  Which is something we eventually might care about, but that
is how parse-options PARSE_OPT_OPTARG works, and I consider "fixing"
it is totally out of the scope of this series (e.g. the next option
"--ignore-submodules" below shares exactly the same issue).

>   { OPTION_STRING, 0, "ignore-submodules", _submodule_arg, 
> N_("when"),
> N_("ignore changes to submodules, optional when: all, dirty, 
> untracked. (Default: all)"),
> PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },

> diff --git a/wt-status.c b/wt-status.c
> index 6f730ee8f2..8301c84946 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -660,10 +660,15 @@ static void wt_status_collect_untracked(struct 
> wt_status *s)
>   if (s->show_untracked_files != SHOW_ALL_UNTRACKED_FILES)
>   dir.flags |=
>   DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
> - if (s->show_ignored_files)
> + if (s->show_ignored_mode) {

Now we no longer use show_ignored_files that was a boolean yes/no,
and instead use an enum show_ignored_mode, we'd better spell this
out like so:

if (s->show_ignored_mode == SHOW_NO_IGNORED) {

>   dir.flags |= DIR_SHOW_IGNORED_TOO;
> - else
> +
> + if (s->show_ignored_mode == SHOW_MATCHING_IGNORED)
> + dir.flags |= DIR_SHOW_IGNORED_TOO_MODE_MATCHING;

Mental note: the old "show_ignored_files is true" case is now split
into two, i.e. traditional vs matching.  When matching is used,
dir.flags gets a new bit, i.e. DIR_SHOW_IGNORED_TOO_MODE_MATCHING.
Lack of that bit means dir.c helpers should behave as before.

> + } else {
>   dir.untracked = the_index.untracked;
> + }
> +
>   setup_standard_excludes();
>  

Re: Ascertaining amount of "original" code across files/repo

[Junio C Hamano]

Thomas Adam  writes:

> What I did was first of all ascertain the number of original lines in each of
> the files I was interested in:
>
>   for i in *.[ch]
>   do
>   c="$(git --no-pager blame "$i" | grep -c '^\^')"
>   [ $c -gt 0 ] && echo "$i:$c"
>   done | sort -t':' -k2 -nr

Another approach I've used when I was curious how many among 1244
lines Linus originally wrote for Git in 2005 remains in today's
codebase goes the other way [*1*].

The "reverse" approach makes use of the -S option of blame to
fabricate a hypothetical history where the very initial version of
Git is today's version, and then there is another version that was
built on it (eh, rather reduced out of it) which is Linus's
original.

$ git tag initial e83c5163316f89
$ cat >fake-history <
e83c5163316  5) #include 
e83c5163316  6) #include 
e83c5163316  7) #include 

The idea is that a line that is blamed to the "root" commit
(i.e. blank prefix) is what survived since Linus's version down to
our current version.  In the fake world, Linus started from our
today's version and ended up with the same result in his version for
these lines.  A line that is blamed to e83c516 is something we do
not have in our today's version that is "added" by Linus in this
fake world---that in reality is what we "lost" from Linus's original
over time.

By adding -M and -C on "git blame" command line, you'll find more
lines that survived over time from Linus's original by getting moved
around inside the same file and across file boundaries.  By adding -w,
indentation-only changes would also be ignored.

I am not judging which is more correct to go in the forward
direction like your approach does or to go in the reverse, as I
haven't thought about it deeply enough.


[Reference]

*1* https://docs.google.com/file/d/0Bw3FApcOlPDhMFR3UldGSHFGcjQ/view

Slide #11 was created using the above method.

Re: [PATCH v3 0/3] deprecate git stash save

[Junio C Hamano]

Overall the result looks reasonable and get us closer to the ideal
world where nobody recalls "stash save" has ever existed ;-)

Will queue; thanks.

Re: [PATCH v3 0/3] deprecate git stash save

[Junio C Hamano]

Thomas Gummerer  writes:

> Interdiff below:

Thanks.  Looks much more polished.

>
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index 89b6a0e672..8be661007d 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -86,7 +86,9 @@ The `--patch` option implies `--keep-index`.  You can use
>  
>  save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
> [-q|--quiet] []::
>  
> - This option is deprecated in favour of 'git stash push'.
> + This option is deprecated in favour of 'git stash push'.  It
> + differs from "stash push" in that it cannot take pathspecs,
> + and any non-option arguments form the message.

Every time I saw this line, I misread s/form/from/ and got
confused.

I know the below is what the above wants the readers to eventually
[*1*] know:

'git stash save' cannot take pathspecs (nor it can be
enhanced with new options in the future) because any
non-option argument to it is treated as the message and has
been deprecated.  'git stash push' supersedes 'git stash
save'; it corrects the command line syntax by requiring '-m'
before the message.

but I feel that the text in your patch still does not read clearly
enough.  But it may only be me.

Thanks.


[Footnote]

*1* By "eventually" what I mean is that it may not be necessarily a
good idea to lay it out all to the reader here at this point in the
document---they may not care why a subcommand is being deprecated,
but for those who want to know, we need to write it down somewhere.

Re: Consider escaping special characters like 'less' does

[Jeff King]

On Sun, Oct 22, 2017 at 08:27:20AM -0400, Jason Pyeron wrote:

> > ESC (for color)
> > +   if ($line =~ s/[\000-\011\013-\032\034-\037]/?/g) {
> 
> What about CR [0x0D] ?

I assumed that CR was one of the things we'd want to avoid (and it was
in fact what I used to test this). E.g., try:

  echo base >file
  git add file
  printf 'foo\r+bar\n' >file

Running through "less" shows something like:

  diff --git a/file b/file
  index df967b9..5b6ee80 100644
  --- a/file
  +++ b/file
  @@ -1 +1 @@
  -base
  +foo^M+bar

but "git add -p" shows:

  $ git add -p
  diff --git a/file b/file
  index df967b9..5b6ee80 100644
  --- a/file
  +++ b/file
  @@ -1 +1 @@
  -base
  +bar
  Stage this hunk [y,n,q,a,d,/,e,?]? 

For systems where CRLF is the native line ending, we'd still expect to
see only LFs here when line-ending conversion is on (since the diff
shows the canonical in-repo form).

For files where the CRs must remain for some reason, they'd show as a
"?" at the end. The "^M" shown by "less" is a bit more informative. If
we really do want to pursue this direction, it might make sense to use
more descriptive placeholders.

-Peff

Re: [PATCH v3 0/3] deprecate git stash save

[Jeff King]

On Sun, Oct 22, 2017 at 06:04:06PM +0100, Thomas Gummerer wrote:

> Thanks Peff for the review of the previous rounds.
> 
> In addition to addressing the review comments, this round adds another
> patch getting rid of the extra help with an unknown option to git
> stash push.

Yeah, the reasoning in the commit message of patch 3 makes sense to me.

> Thomas Gummerer (3):
>   replace git stash save with git stash push in the documentation
>   mark git stash push deprecated in the man page
>   stash: remove now superfluos help for "stash push"

The whole thing looks good. Thanks!

-Peff

Re: "Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?

[Jeff King]

On Sun, Oct 22, 2017 at 07:54:57PM +0530, Kaartic Sivaraam wrote:

> On Fri, 2017-10-20 at 13:45 -0700, Stefan Beller wrote:
> > 
> > The git-test from Michael sounds intriguing. Initially I put off using
> > it as I had my main working dir (or rather test dir) on a spinning
> > disk, still. Now I test in memory only, which is a lot faster, so I could
> > try if git-test can keep up with my local commit pace.
> > 
> 
> Excuse my ignorance but I don't get your statement correctly. What do
> you mean by "I test in memory only"? How do you do that?

I assume it means pointing "--root" at a tmpfs or ram disk in
GIT_TEST_OPTS. That makes the test suite run _way_ faster.

-Peff

Ascertaining amount of "original" code across files/repo

[Thomas Adam]

Hi all,

I was recently left with an interesting problem of looking at a heuristic to
determine how much original code was left in a repository.  Or to put another
way, how much the code had changed since.  In my case "original code" means
"since the initial commit", as this code base had been imported from CVS long
ago; and that was the correct starting point.

What I came up with was the following heuristic.  What I'm curious to know is
whether there's an alternative way to look at this and/or if such tooling
already exists.

What I did was first of all ascertain the number of original lines in each of
the files I was interested in:

for i in *.[ch]
do
c="$(git --no-pager blame "$i" | grep -c '^\^')"
[ $c -gt 0 ] && echo "$i:$c"
done | sort -t':' -k2 -nr

Given this, I then did some maths on the total lines from each of those files
and to work out a percentage by file, and over all.

What I'm curious to know is whether this approach of using "git blame" is a
good approach or not.

Thanks for your time.

-- Thomas Adam

N/A

[Maureend David Kaltschmidt]

Claim Donation

[PATCH v3 2/3] mark git stash push deprecated in the man page

[Thomas Gummerer]

'git stash push' fixes a historical wart in the interface of 'git stash
save'.  As 'git stash push' has all functionality of 'git stash save',
with a nicer, more consistent user interface deprecate 'git stash
save'.  To do this, remove it from the synopsis of the man page, and
move it to a separate section, stating that it is deprecated.

Helped-by: Robert P. J. Day 
Helped-by: Jeff King 
Signed-off-by: Thomas Gummerer 
---
 Documentation/git-stash.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 53b2e60aeb..8be661007d 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -13,8 +13,6 @@ SYNOPSIS
 'git stash' drop [-q|--quiet] []
 'git stash' ( pop | apply ) [--index] [-q|--quiet] []
 'git stash' branch  []
-'git stash' save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
-[-u|--include-untracked] [-a|--all] []
 'git stash' [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
 [-u|--include-untracked] [-a|--all] [-m|--message ]]
 [--] [...]]
@@ -48,7 +46,6 @@ stash index (e.g. the integer `n` is equivalent to 
`stash@{n}`).
 OPTIONS
 ---
 
-save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
[-q|--quiet] []::
 push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
[-q|--quiet] [-m|--message ] [--] [...]::
 
Save your local modifications to a new 'stash entry' and roll them
@@ -87,6 +84,12 @@ linkgit:git-add[1] to learn how to operate the `--patch` 
mode.
 The `--patch` option implies `--keep-index`.  You can use
 `--no-keep-index` to override this.
 
+save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
[-q|--quiet] []::
+
+   This option is deprecated in favour of 'git stash push'.  It
+   differs from "stash push" in that it cannot take pathspecs,
+   and any non-option arguments form the message.
+
 list []::
 
List the stash entries that you currently have.  Each 'stash entry' is
-- 
2.15.0.rc0.2.g8fac3e73c8.dirty

[PATCH v3 3/3] stash: remove now superfluos help for "stash push"

[Thomas Gummerer]

With the 'git stash save' interface, it was easily possible for users to
try to add a message which would start with "-", which 'git stash save'
would interpret as a command line argument, and fail.  For this case we
added some extra help on how to create a stash with a message starting
with "-".

For 'stash push', messages are passed with the -m flag, avoiding this
potential pitfall.  Now only pathspecs starting with "-" would have to
be distinguished from command line parameters by using
"-- --".  This is fairly common in the git command line
interface, and we don't try to guess what the users wanted in the other
cases.

Because this way of passing pathspecs is quite common in other git
commands, and we don't provide any extra help there, do the same in the
error message for 'git stash push'.

Signed-off-by: Thomas Gummerer 
---
 git-stash.sh | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 3a4e5d157c..4b74951440 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -260,18 +260,7 @@ push_stash () {
;;
-*)
option="$1"
-   # TRANSLATORS: $option is an invalid option, like
-   # `--blah-blah'. The 7 spaces at the beginning of the
-   # second line correspond to "error: ". So you should 
line
-   # up the second line with however many characters the
-   # translation of "error: " takes in your language. E.g. 
in
-   # English this is:
-   #
-   #$ git stash push --blah-blah 2>&1 | head -n 2
-   #error: unknown option for 'stash push': --blah-blah
-   #   To provide a message, use git stash push -m 
'--blah-blah'
-   eval_gettextln "error: unknown option for 'stash push': 
\$option
-   To provide a message, use git stash push -m '\$option'"
+   eval_gettextln "error: unknown option for 'stash push': 
\$option"
usage
;;
*)
-- 
2.15.0.rc0.2.g8fac3e73c8.dirty

[PATCH v3 0/3] deprecate git stash save

[Thomas Gummerer]

Thanks Peff for the review of the previous rounds.

In addition to addressing the review comments, this round adds another
patch getting rid of the extra help with an unknown option to git
stash push.

Interdiff below:

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 89b6a0e672..8be661007d 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -86,7 +86,9 @@ The `--patch` option implies `--keep-index`.  You can use
 
 save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
[-q|--quiet] []::
 
-   This option is deprecated in favour of 'git stash push'.
+   This option is deprecated in favour of 'git stash push'.  It
+   differs from "stash push" in that it cannot take pathspecs,
+   and any non-option arguments form the message.
 
 list []::
 
diff --git a/git-stash.sh b/git-stash.sh
index 16919277ba..4b74951440 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -260,18 +260,7 @@ push_stash () {
;;
-*)
option="$1"
-   # TRANSLATORS: $option is an invalid option, like
-   # `--blah-blah'. The 7 spaces at the beginning of the
-   # second line correspond to "error: ". So you should 
line
-   # up the second line with however many characters the
-   # translation of "error: " takes in your language. E.g. 
in
-   # English this is:
-   #
-   #$ git stash push --blah-blah 2>&1 | head -n 2
-   #error: unknown option for 'stash push': --blah-blah
-   #   To provide a message, use git stash push -- 
'--blah-blah'
-   eval_gettextln "error: unknown option for 'stash push': 
\$option
-   To provide a message, use git stash push -m '\$option'"
+   eval_gettextln "error: unknown option for 'stash push': 
\$option"
usage
;;
*)


Thomas Gummerer (3):
  replace git stash save with git stash push in the documentation
  mark git stash push deprecated in the man page
  stash: remove now superfluos help for "stash push"

 Documentation/git-stash.txt| 21 -
 Documentation/gitworkflows.txt |  2 +-
 Documentation/user-manual.txt  |  2 +-
 git-stash.sh   | 13 +
 4 files changed, 15 insertions(+), 23 deletions(-)

-- 
2.15.0.rc0.2.g8fac3e73c8.dirty

[PATCH v3 1/3] replace git stash save with git stash push in the documentation

[Thomas Gummerer]

git stash push is the newer interface for creating a stash.  While we
are still keeping git stash save around for the time being, it's better
to point new users of git stash to the more modern (and more feature
rich) interface, instead of teaching them the older version that we
might want to phase out in the future.

Signed-off-by: Thomas Gummerer 
---
 Documentation/git-stash.txt| 12 ++--
 Documentation/gitworkflows.txt |  2 +-
 Documentation/user-manual.txt  |  2 +-
 git-stash.sh   | 10 +-
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 00f95fee1f..53b2e60aeb 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -33,7 +33,7 @@ and reverts the working directory to match the `HEAD` commit.
 The modifications stashed away by this command can be listed with
 `git stash list`, inspected with `git stash show`, and restored
 (potentially on top of a different commit) with `git stash apply`.
-Calling `git stash` without any arguments is equivalent to `git stash save`.
+Calling `git stash` without any arguments is equivalent to `git stash push`.
 A stash is by default listed as "WIP on 'branchname' ...", but
 you can give a more descriptive message on the command line when
 you create one.
@@ -118,7 +118,7 @@ pop [--index] [-q|--quiet] []::
 
Remove a single stashed state from the stash list and apply it
on top of the current working tree state, i.e., do the inverse
-   operation of `git stash save`. The working directory must
+   operation of `git stash push`. The working directory must
match the index.
 +
 Applying the state can fail with conflicts; in this case, it is not
@@ -137,7 +137,7 @@ apply [--index] [-q|--quiet] []::
 
Like `pop`, but do not remove the state from the stash list. Unlike 
`pop`,
`` may be any commit that looks like a commit created by
-   `stash save` or `stash create`.
+   `stash push` or `stash create`.
 
 branch  []::
 
@@ -148,7 +148,7 @@ branch  []::
`stash@{}`, it then drops the ``. When no ``
is given, applies the latest one.
 +
-This is useful if the branch on which you ran `git stash save` has
+This is useful if the branch on which you ran `git stash push` has
 changed enough that `git stash apply` fails due to conflicts. Since
 the stash entry is applied on top of the commit that was HEAD at the
 time `git stash` was run, it restores the originally stashed state
@@ -255,14 +255,14 @@ $ git stash pop
 
 Testing partial commits::
 
-You can use `git stash save --keep-index` when you want to make two or
+You can use `git stash push --keep-index` when you want to make two or
 more commits out of the changes in the work tree, and you want to test
 each change before committing:
 +
 
 # ... hack hack hack ...
 $ git add --patch foo# add just first part to the index
-$ git stash save --keep-index# save all other changes to the stash
+$ git stash push --keep-index# save all other changes to the stash
 $ edit/build/test first part
 $ git commit -m 'First part' # commit fully tested change
 $ git stash pop  # prepare to work on all other changes
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 177610e44e..02569d0614 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -40,7 +40,7 @@ beginning. It is always easier to squash a few commits 
together than
 to split one big commit into several.  Don't be afraid of making too
 small or imperfect steps along the way. You can always go back later
 and edit the commits with `git rebase --interactive` before you
-publish them.  You can use `git stash save --keep-index` to run the
+publish them.  You can use `git stash push --keep-index` to run the
 test suite independent of other uncommitted changes; see the EXAMPLES
 section of linkgit:git-stash[1].
 
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index b4d88af133..3a03e63eb0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1556,7 +1556,7 @@ so on a different branch and then coming back), unstash 
the
 work-in-progress changes.
 
 
-$ git stash save "work in progress for foo feature"
+$ git stash push -m "work in progress for foo feature"
 
 
 This command will save your changes away to the `stash`, and
diff --git a/git-stash.sh b/git-stash.sh
index 8b2ce9afda..3a4e5d157c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -267,11 +267,11 @@ push_stash () {
# translation of "error: " takes in your language. E.g. 
in
# English this is:
#
-   #$ git stash 

Re: [PATCH v2 2/2] mark git stash push deprecated in the man page

[Thomas Gummerer]

On 10/21, Jeff King wrote:
> On Thu, Oct 19, 2017 at 07:33:04PM +0100, Thomas Gummerer wrote:
> 
> > 'git stash push' fixes a historical wart in the interface of 'git stash
> > save'.  As 'git stash push' has all functionality of 'git stash save',
> > with a nicer, more consistent user interface deprecate 'git stash
> > save'.  To do this, remove it from the synopsis of the man page, and
> > move it to a separate section, stating that it is deprecated.
> 
> This looks fine.
> 
> > @@ -87,6 +84,10 @@ linkgit:git-add[1] to learn how to operate the `--patch` 
> > mode.
> >  The `--patch` option implies `--keep-index`.  You can use
> >  `--no-keep-index` to override this.
> >  
> > +save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] 
> > [-a|--all] [-q|--quiet] []::
> > +
> > +   This option is deprecated in favour of 'git stash push'.
> > +
> 
> We could possibly go into more detail, like:
> 
>   It differs from "stash push" in that it cannot take pathspecs, and any
>   non-option arguments form the message.
> 
> or something. Since we don't want people to use it, it probably doesn't
> matter much. I just wondered if people would peer at the (long) synopsis
> line trying to figure out how it's different.

Yeah, feels like it could potentially help somebody.  I'll add that, thanks!

> -Peff

Re: [PATCH v2 1/2] replace git stash save with git stash push in the documentation

[Thomas Gummerer]

On 10/21, Jeff King wrote:
> On Thu, Oct 19, 2017 at 07:33:03PM +0100, Thomas Gummerer wrote:
> 
> > diff --git a/git-stash.sh b/git-stash.sh
> > index 8b2ce9afda..16919277ba 100755
> > --- a/git-stash.sh
> > +++ b/git-stash.sh
> > @@ -267,11 +267,11 @@ push_stash () {
> > # translation of "error: " takes in your language. E.g. 
> > in
> > # English this is:
> > #
> > -   #$ git stash save --blah-blah 2>&1 | head -n 2
> > -   #error: unknown option for 'stash save': --blah-blah
> > -   #   To provide a message, use git stash save -- 
> > '--blah-blah'
> > -   eval_gettextln "error: unknown option for 'stash save': 
> > \$option
> > -   To provide a message, use git stash save -- '\$option'"
> > +   #$ git stash push --blah-blah 2>&1 | head -n 2
> > +   #error: unknown option for 'stash push': --blah-blah
> > +   #   To provide a message, use git stash push -- 
> > '--blah-blah'
> > +   eval_gettextln "error: unknown option for 'stash push': 
> > \$option
> > +   To provide a message, use git stash push -m '\$option'"
> 
> The user message is fixed here, but doesn't the message for translators
> need the same treatment?  I guess it's just talking about the spacing,
> so it doesn't need to be completely accurate. But it probably makes
> sense to update it at the same time.

Yeah, I was completely blind here, that should definitely have been
updated as well.  Thanks for catching.

> As an aside, I do kind of wonder if the right advice for "push" is
> different than for "save" here. I.e., should it say "to provide a
> pathspec that starts with --, use push -- --blah-blah". I'm not sure it
> matters that much. Second-guessing what a user meant seems likely to go
> wrong (e.g., "--icnlude-untracked" would trigger this message, which is
> just silly). But that's largely orthogonal to what you're doing here.

The best advice for it might indeed be different for "save" and
"push".  The slight weirdness we have here is that both "save" and
"push" are using the same option parsing.

Now that we're deprecating "save", I don't think it's worth the effort
to try to get rid of this weirdness.

I think using "--" to distinguish the the pathspec from the command
line options is a common enough pattern that we don't need to give
advice to the users.  I feel like that second line was mostly there
because of the weirdness in the user interface for "stash save".
Maybe we should just get rid of that part alltogether?

> -Peff

Re: "Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?

[Kaartic Sivaraam]

On Fri, 2017-10-20 at 13:45 -0700, Stefan Beller wrote:
> 
> The git-test from Michael sounds intriguing. Initially I put off using
> it as I had my main working dir (or rather test dir) on a spinning
> disk, still. Now I test in memory only, which is a lot faster, so I could
> try if git-test can keep up with my local commit pace.
> 

Excuse my ignorance but I don't get your statement correctly. What do
you mean by "I test in memory only"? How do you do that?

---
Kaartic

(no subject)

[Barr. Richard Williams]

--
Hello,

I am writing you this email to solicit your co-operation and 
partnership  in a business that would benefit us immensely.


I would like to name you the beneficiary to my late client's fund who 
died along with his next-of-kin during a summer vacation in the Middle 
East.


I shall offer you 50 percent of the fund, and you will be in custody of 
my intended  investment in your country with my share.


Do reply for details.

Regards
Richard Williams
Email:richawill1...@gmail.com

Re: [RFE] Add minimal universal release management capabilities to GIT

[Kaartic Sivaraam]

Heads up, I'm gonna play the devil's advocate a little, here.

On Sat, 2017-10-21 at 15:56 +0200, nicolas.mail...@laposte.net wrote:
> No that is not up to the hash function. First because hashes are too
> long to be manipulated by humans, and second no hash will ever
> capture human intent. You need an explicit human action to mark "I
> want others to use this particular state of my project because I am
> confident it is solid".
> 

I would say you're just limiting your thoughts. There's no strict rule
saying hash functions should be "incomprehensible" to humans or that
different hashes should be "uncomparable". No one's going to stop
someone from creating a hypothetical hash function that's totally
ordered (!) unless you violate the basis of a "hash". (surprise,
there's already attempts at it,

https://stackoverflow.com/q/28043857/5614968


)


> Except, the releasing happens outside git, it's still fairly manual. 

You seem to be more frustrated by "manual" work. I suspect why you
can't automate that. Given all the work done during a release of "Git",
(https://public-inbox.org/git/xmqqr2tygvp4@gitster.mtv.corp.google.
com/)
may be the maintainer could possibly give some good advise on this.

+cc Junio

> All I'm proposing is to integrate the basic functions in git to
> simplify the life of those projects and help smaller projects that
> want completely intergrated git workflows.
> 

Wait, aren't you just trying to make git more than a "version control
system"? I don't think it's encouraged a lot here given that there have
patches that have not been accepted because they might make git
opinionated and the result "doesn't quite fit into the broad picture of
a version control system"

cf. https://public-inbox.org/git/20170711233827.23486-1-sbel...@google.com/

cf. 
https://public-inbox.org/git/cagz79kyarf6r-vx1-lm4x_anlmrxc3vnd2acqmnqq3j6y-s...@mail.gmail.com/


> Yes and it is so fun to herd hundreds of management tools with
> different conventions and quirks. About as much fun as managing
> dozens of scm before most projects settled on git. All commonalities
> need to migrate in the common git layer to simplify management and
> release id is the first of those.

It's better to have a "good" (generic) release management tool that
does what you ask (probably with some help from git) than try to turn
Git into one (which is not possible without making Git opinionated,
more on that later). I guess there should already be one that meets
your expectation and you probably just have to discover it.

Further, if there's no "generic" release management tool in existence,
I suspect that because there's no such thing a "generic release
management strategy" and it always depends on context (or) create one
on your own in the spirit of letting "git" handle just "version
control" and letting your "genereic" tool handle your concerns. Who
knows, if you have developed a good enough "generic" tool it might be
used widely for "release management" just as a lot of projects starting
using Git for "version control". (I still suspect that there should be
one that already exists)


> > git tags ?
> 
> Too loosely defined to be relied on by project-agnostic tools. That's
> what most tools won't ever try to use those. Anything you will define
> around tags as they stand is unlikely to work on the project of
> someone else
> 

They are loosely defined because you can't define them "tightly" and if
you try to it would make Git opinionated !?

> > > 5. a command, such as "git release", allow a human with control of the 
> > > repo to set an explicit release version to a commit. 
> > 
> > This sounds fairly specific to an environment that you are in, maybe
> > write git-release for your environment and then open source it. The
> > world will love it (assuming they have the same environment and
> > needs).
> 
> If you take the time to look at it it is not specific, it is generic.
> 

I would say that you might haven't looked broadly enough.

1) If it's generic, why isn't there any "generic" release management
tool?

2) if it's possible to create a "generic" release management tool and
it just doesn't exist yet, why not try to create instead of trying to
integrate release management into Git ? (you could make it depend on
git, of course)

> You need to identify software during
> its whole lifecycle, and the id needs to start in the scm, because
> that's where the lifecycle starts.

It might not for everyone!

-- 
Kaartic

RE: Consider escaping special characters like 'less' does

[Jason Pyeron]

> -Original Message-
> From: Jeff King
> Sent: Monday, October 16, 2017 6:13 PM
> To: Joris Valette
> Cc: Andreas Schwab; Jason Pyeron; git@vger.kernel.org
> Subject: Re: Consider escaping special characters like 'less' does
> 

> 
> I.e., something like this would probably help your case 
> without hurting
> anybody:
> 
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 28b325d754..d44e5ea459 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -714,6 +714,16 @@ sub parse_diff {
>   push @{$hunk[-1]{DISPLAY}},
>   (@colored ? $colored[$i] : $diff[$i]);
>   }
> +
> + foreach my $hunk (@hunk) {
> + foreach my $line (@{$hunk->{DISPLAY}}) {
> + # all control chars minus newline and 
> ESC (for color)
> + if ($line =~ s/[\000-\011\013-\032\034-\037]/?/g) {

What about CR [0x0D] ?

> + $hunk->{CONTROLCHARS} = 1;
> + }
> + }
> + }
> +
>   return @hunk;
>  }
>  
> @@ -1407,6 +1417,9 @@ sub patch_update_file {
>   if ($hunk[$ix]{TYPE} eq 'hunk') {
>   $other .= ',e';
>   }
> + if ($hunk[$ix]->{CONTROLCHARS}) {
> + print "warning: control characters in 
> hunk have been replaced by '?'\n";
> + }
>   for (@{$hunk[$ix]{DISPLAY}}) {
>   print;
>   }
> 
> I can't help but feel this is the tip of a larger iceberg, 
> though. E.g.,
> what about characters outside of the terminal's correct encoding? Or
> broken UTF-8 characters?
> 
> -Peff
> 

RE:

[John Galvan]

Re: Re* Is t5601 flaky for anybody else?

[Kaartic Sivaraam]

On Tue, 2017-10-17 at 17:08 -0400, Jeff King wrote:
> On Wed, Oct 18, 2017 at 06:02:59AM +0900, Junio C Hamano wrote:
> 
> FWIW, I can't replicate the problem on either "master" or "pu". I wonder
> why.
> 

Neither can I. I tried running t5601 on "master" and on "pu" after
reverting the patch found in this thread. Both ran successfully without
issues.

-- 
Kaartic