Re: [PATCH v2 1/2] doc/for-each-ref: consistently use '=' to between argument names and values

2017-09-11 Thread Kevin Daudt
On Tue, Sep 12, 2017 at 11:28:00AM +0900, Junio C Hamano wrote:
> Kevin Daudt  writes:
> 
> > The synopsis and description inconsistently add a '=' between the
> > argument name and it's value. Make this consistent.
> >
> > Signed-off-by: Kevin Daudt 
> > ---
> >  Documentation/git-for-each-ref.txt | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> Good idea, and I think it is in line with an earlier suggestion by
> Jonathan (cc'ed).
> 
> Thanks.
> 

Yeah, this is his diff applied. Forgot to CC him.


Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

2017-09-11 Thread Junio C Hamano
Johannes Schindelin  writes:

>> Stepping back a bit, I am not sure if it is sane or even valid for the
>> end-user to modify paths outside sparse-checkout area, but that is
>> probably a separate tangent.
>
> That is not at all the scenario that Kevin fixed.

I know, but in this tangent I was reacting to this part of Kevin's
message

>>  create $path
>>  git add $path
>>  git commit
>>  git checkout // where $path is not in the sparse-checkout
>>  git reset HEAD~1

to which I was responding to.

> ...
> Yet without Kevin's fix, `git status` would report that the user *deleted
> files outside the sparse checkout*.
> ...
> That is such an obvious bug, and Kevin's fix is such an obvious
> improvement over the current upstream Git version, that I would think the
> only thing worth discussing is whether the patch goes about it in a way of
> which you approve.

When reviewing any topic, I'd ask three (or four) questions to
myself:

 * Are we solving a right problem?  Is the problem addressed valid?
 * Are we solving it with a right approach?
 * Does the patch implement the approach correctly?

(the fourth is s/correct/efficient/ of the third, which is optional).

and any "no" to an earlier question will make it a moot point to ask
further questions.

Let's imagine a path P that is outside the sparse checkout area.
And we check out a commit that has P.  P would still be recorded in
the index but it would not materialize in the working tree.  "git
status" and friends are asked not to treat this as "locally removed",
to prevent "commit -a" from recording a removal, of course.

Now, let's further imagine that you have a checkout of the same
project but at a commit that does not have P.  Then you reset to
another commit that does have P.  My understanding of what Kevin's
first test wants to demonstrate is that the index is populated with
P (because you did reset to a commit with that path) but it does not
materialize in the working tree (perhaps because that is outside the
sparse checkout area?), yet there is something missing compared to
the earlier case where "git status" and friends are asked not to
treat P as "locally removed".  They instead show P as locally removed,
and "commit -a" would record a removal---that is indeed a problem.

Am I reading the problem description correctly so far?  If so, then
my answer to my first question (are we solving a right problem?) is
yes.

My response to an earlier version of the patch was written while
assuming (read: without thinking deeply but trusting that the
contributor thought things through) that the first two answers were
"yes".  If the right approach were to check out what is in the index
to silence "git status" and friends by matching the index and the
working tree, then the implementation in the patch (i.e. setting up
some cache entry and calling checkout_entry() to make it materialize
in the working tree) looked correct, and that is what I meant by
"Other than that, the patch looks quite cleanly done and well
explained."

But this time, I am trying to see if the approach is good.  I am not
so sure if the approach taken by this patch is so obviously good as
you seem to think.  A logical consequence of the approach "git
status thinks that P appears in the index and missing in the working
tree is a local removal, so let's squelch it by creating the file in
the working tree" is that we will end up fully populating the
working tree with paths that are clearly outside the area the user
designated as the sparse checkout area---surely that may squelch
"status", but to me, it looks like it is breaking what the user
wanted to achieve with "sparse checkout" in the first place.

When we make a sparse checkout that places P outside the checked-out
area, with P in the index and not in the working tree, what asks
"git status" and friends not to treat P as "locally removed"?
Shouldn't "reset HEAD~1" that resurrected P that was missing in the
commit in the state before you did the "reset" be doing the same
(e.g. flipping the bit in the index for path P that says "not having
this in the working tree is not a removal---it is deliberately not
checked out")?  If that is the right approach to solve the issue
(which we established is a right problem to solve already), and the
approach that the patch wants to take is quite the opposite of it,
then my answer to the second question (are we solving the problem
with the right approach?) is no.  And at that point, it is moot to
ask if the code correctly and/or efficiently implements that wrong
solution, isn't it?


Re: [PATCH v2 1/2] doc/for-each-ref: consistently use '=' to between argument names and values

2017-09-11 Thread Junio C Hamano
Kevin Daudt  writes:

> The synopsis and description inconsistently add a '=' between the
> argument name and it's value. Make this consistent.
>
> Signed-off-by: Kevin Daudt 
> ---
>  Documentation/git-for-each-ref.txt | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)

Good idea, and I think it is in line with an earlier suggestion by
Jonathan (cc'ed).

Thanks.

> diff --git a/Documentation/git-for-each-ref.txt 
> b/Documentation/git-for-each-ref.txt
> index bb370c9c7..1015c88f6 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -10,8 +10,9 @@ SYNOPSIS
>  [verse]
>  'git for-each-ref' [--count=] [--shell|--perl|--python|--tcl]
>  [(--sort=)...] [--format=] [...]
> -[--points-at ] [(--merged | --no-merged) []]
> -[--contains []] [--no-contains []]
> +[--points-at=]
> +(--merged[=] | --no-merged[=])
> +[--contains[=]] [--no-contains[=]]
>  
>  DESCRIPTION
>  ---
> @@ -65,24 +66,24 @@ OPTIONS
>   the specified host language.  This is meant to produce
>   a scriptlet that can directly be `eval`ed.
>  
> ---points-at ::
> +--points-at=::
>   Only list refs which points at the given object.
>  
> ---merged []::
> +--merged[=]::
>   Only list refs whose tips are reachable from the
>   specified commit (HEAD if not specified),
>   incompatible with `--no-merged`.
>  
> ---no-merged []::
> +--no-merged[=]::
>   Only list refs whose tips are not reachable from the
>   specified commit (HEAD if not specified),
>   incompatible with `--merged`.
>  
> ---contains []::
> +--contains[=]::
>   Only list refs which contain the specified commit (HEAD if not
>   specified).
>  
> ---no-contains []::
> +--no-contains[=]::
>   Only list refs which don't contain the specified commit (HEAD
>   if not specified).


Re: What's cooking in git.git (Sep 2017, #02; Mon, 11)

2017-09-11 Thread Junio C Hamano
Thomas Gummerer  writes:

> On 09/11, Kevin Willford wrote:
>> > 
>> > * kw/write-index-reduce-alloc (2017-09-08) 2 commits
>> >  - read-cache: fix index corruption with index v4
>> >  - Add t/helper/test-write-cache to .gitignore
>> > 
>> >  Expecting a reroll.
>> >  cf. > > q...@mail.gmail.com>
>> > 
>> I didn't submit these patches so what would you like
>> me to do?

Nothing ;-).  

These two are fixups to a recent topic; the name of the topic branch
does not mean fixes and updates must come only from those who share
the initial 'kw'.

>> The reroll for read-cache fix was submitted here
>> https://public-inbox.org/git/20170907192412.8085-1-t.gumme...@gmail.com/
>
> I noticed that it has already been picked up as well, as
> 0b90b881e0c1de110c724fe63df6d2c3c9680d6a.  Maybe it's just the What's
> cooking that needs to be updated, or is there something else missing?

Yeah, thanks for keeping an eye on what's on 'pu'.



I NEED YOUR URGENT ASSISTANT

2017-09-11 Thread Salif Musa
-- 
Hi friend

I am a banker in ADB BANK. I want to transfer an abandoned sum of
USD15.6Million to your Bank account. 40/percent will be your share.

No risk involved but keeps it as secret. Contact me for more details.
Please reply me through my alternative email id only (salif.musa...@gmail.com)
for confidential reasons.

Yours
Dr Salif Musa


Re: Unexpected pass for t6120-describe.sh on cygwin

2017-09-11 Thread Ramsay Jones


On 11/09/17 11:31, Adam Dinwoodie wrote:
> On Sat, Sep 09, 2017 at 02:13:32PM +0100, Ramsay Jones wrote:
>> I ran the test-suite on the 'pu' branch last night (simply because
>> that was what I had built at the time!), which resulted in a PASS,
>> but t6120 was showing a 'TODO passed' for #52.
> 
> Confirmed, I also see this unexpected pass.
> 
>> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'
>> branch, which uses 'ulimit -s' to try and force a stack overflow.
>> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created
>> a test program (see below) to eat up the stack and tried running it
>> with various ulimit values (128, 12, 8), but it always seg-faulted
>> at the same stack-frame. (after using approx 2MB stack space).
> 
> Yes, Cygwin does not implement the ulimit API from the Single Unix
> Specification, per https://cygwin.com/cygwin-api/std-notimpl.html.  I

Isn't that ulimit(3) not ulimit the bash built-in - which would
more than likely be implemented by {get,set}rlimit(). (I haven't
looked to find out, obviously!).

> suspect the Bash builtin still exists because (a) nobody has bothered to
> remove it, (b) including it avoids breaking scripts that assume it
> exists but don't particularly rely on its output being sensical, or
> (c) both.

(d) it seems to provide useful information on some of the limits anyway.

>> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled
>> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,
>> but haven't looked into it.
>>
>> Given that 'ulimit' is a bash built-in, this may also be a problem
>> on MinGW and Git-For-Windows, but I can't test on those platforms.
> 
> I'll leave this to the relevant folks to test; I don't have a useful
> test environment for those either.  That said, I'll note the comment in
> t6120 says the ULIMIT_STACK_SIZE prerequisite excludes running the test
> on Windows, so I assume it's not a problem there.

I suspect that was a guess. ;-)

> On Sun, Sep 10, 2017 at 05:58:49PM +0100, Ramsay Jones wrote:
>> On 10/09/17 13:27, Michael J Gruber wrote:
>>> So, I guess, short of testing the effect of "ulimit -s" with another
>>> expensive test, it's best to simply set these prerequisites based on
>>> "uname -s".
>>
>> Yes, I was going to suggest adding !CYGWIN to the test(s) (or perhaps
>> to the 'test_lazy_prereq' expression(s)).
> 
> Given the issue is Cygwin not implementing ulimit at all, but Cygwin
> Bash pretending everything's fine, I think handling this as a special
> case for Cygwin seems like the correct approach.  Something like the
> below, based on the existing code in test-lib.sh for the PIPE prereq?
> 
> -- >8 --
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 83f5d3dd2..376cd91ae 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1166,14 +1166,32 @@ test_lazy_prereq UNZIP '
>   test $? -ne 127
>  '
>  
> +# On Cygwin, ulimit has no effect because the underlying API hasn't been
> +# implemented.  Just fail if trying to do something with ulimit.
>  run_with_limited_cmdline () {
> - (ulimit -s 128 && "$@")
> + case $(uname -s) in
> + CYGWIN*)
> + false
> + ;;
> + *)
> + (ulimit -s 128 && "$@")
> + ;;
> + esac
>  }
>  
>  test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
>  
> +# On Cygwin, ulimit has no effect because the underlying API hasn't been
> +# implemented.  Just fail if trying to do something with ulimit.
>  run_with_limited_stack () {
> - (ulimit -s 128 && "$@")
> + case $(uname -s) in
> + CYGWIN*)
> + false
> + ;;
> + *)
> + (ulimit -s 128 && "$@")
> + ;;
> + esac
>  }
>  
>  test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'
> 

What about the other uses of ulimit? (No, I still haven't tried
ulimit with open file descriptors - I will assume it doesn't work).

I was thinking something more like this:

  $ git diff
  diff --git a/t/test-lib.sh b/t/test-lib.sh
  index 83f5d3dd2..6c939708a 100644
  --- a/t/test-lib.sh
  +++ b/t/test-lib.sh
  @@ -1009,6 +1009,11 @@ case $uname_s in
  GIT_TEST_CMP=mingw_test_cmp
  ;;
   *CYGWIN*)
  +   # the ulimit bash built-in is ineffective
  +   # but always succeeds, so always fail instead
  +   ulimit () {
  +   false
  +   }
  test_set_prereq POSIXPERM
  test_set_prereq EXECKEEPSPID
  test_set_prereq CYGWIN
  $ 

This assumes that 'ulimit -n 32' fails to limit the number
of open files, of course.

ATB,
Ramsay Jones



Re: [idea] File history tracking hints

2017-09-11 Thread Philip Oakley

From: "Pavel Kretov" 

Hi all,

Excuse me if the topic I'm going to raise here has been already discussed
on the mailing list, forums, or IRC, but I couldn't find anything related.


The problem:

Git, being "a stupid content tracker", doesn't try to keep an eye on
operations which happens to individual files; things like file renames
aren't recorded during commit, but heuristically detected later.

Unfortunately, the heuristic can only deal with simple file renames with
no substantial content changes; it's helpless when you:

- rename file and change it's content significantly;
- split single file into several files;
- merge several files into another;
- copy entire file from another commit, and do other things like these.

However, if we're able to preserve this information, it's possible
not only to do more accurate 'git blame', but also merge revisions with
fewer conflicts.


The proposal:

The idea is to let user give hints about what was changed during
the commit. For example, if user did a rename which wasn't automatically
detected, he would append something like the following to his commit
message:

   Tracking-hints: rename dev-vcs/git/git-1.0.ebuild ->
dev-vcs/git/git-2.0.ebuild

or (if full paths of affected files can be unambiguously omitted):

   Tracking-hints: rename git-1.0.ebuild -> git-2.0.ebuild

There may be other hint types:

   Tracking-hint: recreate LICENSE.txt
   Tracking-hint: split main.c -> main.c cmdline.c
   Tracking-hint: merge linalg.py <- vector.py matrix.py

or even something like this:

   Tracking-hint: copy json.py <-
libs/json.py@4db88291251151d8c5c8e4f20430fa4def2cb2ed

If file transformation cannot be described by a single tracking hint, it 
shall

be possible to specify a sequence of hints at once:

   Tracking-hint:
   split Utils.java -> AppHelpers.java StringHelpers.java
   recreate Utils.java

Note that in the above example the order of operations really matters, so
both lines have to reside in one 'Tracking-hint' block.

* * *

How do you think, is this idea worth implementing?
Any other thoughts on this?

-- Pavel Kretov.


Maybe use the "interpret-trailers" methods for standardising your hints 
locally (in your team / workplace) to see how it goes and flesh out what 
works and what doesn't. Trying to decide, a-priori, what are the right hints 
is likely to be the hard part.

--
Philip 



Re: [PATCH 06/34] clone: release strbuf after use in remove_junk()

2017-09-11 Thread René Scharfe
Am 10.09.2017 um 19:38 schrieb Jeff King:
> On Sun, Sep 10, 2017 at 12:37:06PM +0200, René Scharfe wrote:
> 
>>> And in fact, being called from a signal handler means we should
>>> generally avoid touching malloc or free (which could be holding locks).
>>> That would mean preferring a leak to strbuf_release(). Of course that is
>>> the tip of the iceberg. We call strbuf_addstr() here, and
>>> remove_dir_recursively() will grow our buffer.
>>
>> And we call opendir(3), readdir(3), and closedir(3), which are also not
>> listed as async-safe functions by POSIX [1].
> 
> Good point. I don't know how dangerous those are in the real-world
> (i.e., is POSIX leaving an out for some implementations, or are they
> really unsafe on common platforms like Linux).

No idea.

>>> So I actually wonder if junk_git_dir and junk_work_tree should be
>>> pre-sized strbufs themselves. And that makes the leak "go away" in the
>>> eyes of leak-checkers because we hold onto the static strbufs until
>>> program exit.
>>
>> We could start with a small buffer and expand it to match the path
>> length of written files as we go.
> 
> Yes, but I didn't want to touch each code site that creates a file,
> which is a lot more invasive. I expect expanding to 4096 (or PATH_MAX)
> would be sufficient in practice.

Perhaps it is in most cases.  Having certainty would be better.  We can
leave unpack_trees() untouched and instead traverse the tree beforehand,
in order to find the longest path.  Perhaps we can do something similar
for init_db().

> I'd also note that the current code isn't _remotely_ async safe and
> nobody's complained. So I'm perfectly happy doing nothing, too. I care
> a bit more about the tempfile.c interface because it's invoked a lot
> more frequently.

I guess clones are not interrupted very often during checkout; same
with worktree creation.  So perhaps nasty things could happen with a
low probability, but nobody tried hard enough to hit that case?

>> Deletion without readdir(3) requires us to keep a list of all written
>> files and directories, though.  Perhaps in the form of an append-only
>> log; the signal handler could then go through them in reverse order
>> and remove them.  Or is there a better way?
> 
> No, I think that's how you'd have to do it. The implementation isn't all
> that bad, but hitting every file-creation would be invasive. I'd
> almost rather bail to exec-ing "rm -rf $dir", but we probably can't do
> _that_ in a signal-handler either. :)

Well, fork(2), execve(2), and waitpid(2) are on the list, so actually
you can.

mingw_spawnvpe(), which is used by start_command() on Windows,
allocates memory, though.  Preparing environment and argument list
in advance and just calling CreateProcess() in the signal handler
might work.

René


Re: [idea] File history tracking hints

2017-09-11 Thread Igor Djordjevic
Hi Pavel,

On 11/09/2017 09:11, Pavel Kretov wrote:
> Hi all,
> 
> Excuse me if the topic I'm going to raise here has been already discussed
> on the mailing list, forums, or IRC, but I couldn't find anything related.
> 
> 
> The problem:
> 
> Git, being "a stupid content tracker", doesn't try to keep an eye on
> operations which happens to individual files; things like file renames
> aren't recorded during commit, but heuristically detected later.
> 
> Unfortunately, the heuristic can only deal with simple file renames with
> no substantial content changes; it's helpless when you:
> 
>  - rename file and change it's content significantly;
>  - split single file into several files;
>  - merge several files into another;
>  - copy entire file from another commit, and do other things like these.
> 
> However, if we're able to preserve this information, it's possible
> not only to do more accurate 'git blame', but also merge revisions with
> fewer conflicts.
> 
> 
> The proposal:
> 
> The idea is to let user give hints about what was changed during
> the commit. For example, if user did a rename which wasn't automatically
> detected, he would append something like the following to his commit
> message:
> 
> Tracking-hints: rename dev-vcs/git/git-1.0.ebuild ->
> dev-vcs/git/git-2.0.ebuild
> 
> or (if full paths of affected files can be unambiguously omitted):
> 
> Tracking-hints: rename git-1.0.ebuild -> git-2.0.ebuild
> 
> There may be other hint types:
> 
> Tracking-hint: recreate LICENSE.txt
> Tracking-hint: split main.c -> main.c cmdline.c
> Tracking-hint: merge linalg.py <- vector.py matrix.py
> 
> or even something like this:
> 
> Tracking-hint: copy json.py <-
> libs/json.py@4db88291251151d8c5c8e4f20430fa4def2cb2ed
> 
> If file transformation cannot be described by a single tracking hint, it shall
> be possible to specify a sequence of hints at once:
> 
> Tracking-hint:
> split Utils.java -> AppHelpers.java StringHelpers.java
> recreate Utils.java
> 
> Note that in the above example the order of operations really matters, so
> both lines have to reside in one 'Tracking-hint' block.
> 
> * * *
> 
> How do you think, is this idea worth implementing?
> Any other thoughts on this? 

Here[1] you can find Linus` reply (from 2005-04-15) to "rename 
tracking" discussion, usually quoted to explain the Git philosophy on 
this point, even referred to as "one of the most important messages 
in the list archive"[2] by Junio himself.

[1] 
https://public-inbox.org/git/pine.lnx.4.58.0504150753440.7...@ppc970.osdl.org/
[2] https://public-inbox.org/git/xmqqr30qflk9@gitster.mtv.corp.google.com/

Regards,
Buga


Re: What's cooking in git.git (Sep 2017, #02; Mon, 11)

2017-09-11 Thread Thomas Gummerer
On 09/11, Kevin Willford wrote:
> > 
> > * kw/write-index-reduce-alloc (2017-09-08) 2 commits
> >  - read-cache: fix index corruption with index v4
> >  - Add t/helper/test-write-cache to .gitignore
> > 
> >  Expecting a reroll.
> >  cf.  > q...@mail.gmail.com>
> > 
> I didn't submit these patches so what would you like
> me to do?
> 
> The reroll for read-cache fix was submitted here
> https://public-inbox.org/git/20170907192412.8085-1-t.gumme...@gmail.com/

I noticed that it has already been picked up as well, as
0b90b881e0c1de110c724fe63df6d2c3c9680d6a.  Maybe it's just the What's
cooking that needs to be updated, or is there something else missing?

> - Kevin
> 


[PATCH v2 2/2] doc/for-each-ref: explicitly specify option names

2017-09-11 Thread Kevin Daudt
For count, sort and format, only the argument names were listed under
OPTIONS, not the option names.

Add the option names to make it clear the options exist

Signed-off-by: Kevin Daudt 
---
 Documentation/git-for-each-ref.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 1015c88f6..66b4e0a40 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -26,19 +26,25 @@ host language allowing their direct evaluation in that 
language.
 
 OPTIONS
 ---
-::
+...::
+   If one or more patterns are given, only refs are shown that
+   match against at least one pattern, either using fnmatch(3) or
+   literally, in the latter case matching completely or from the
+   beginning up to a slash.
+
+--count=::
By default the command shows all refs that match
``.  This option makes it stop after showing
that many refs.
 
-::
+--sort=::
A field name to sort on.  Prefix `-` to sort in
descending order of the value.  When unspecified,
`refname` is used.  You may use the --sort= option
multiple times, in which case the last key becomes the primary
key.
 
-::
+--format=::
A string that interpolates `%(fieldname)` from a ref being shown
and the object it points at.  If `fieldname`
is prefixed with an asterisk (`*`) and the ref points
@@ -51,12 +57,6 @@ OPTIONS
`xx`; for example `%00` interpolates to `\0` (NUL),
`%09` to `\t` (TAB) and `%0a` to `\n` (LF).
 
-...::
-   If one or more patterns are given, only refs are shown that
-   match against at least one pattern, either using fnmatch(3) or
-   literally, in the latter case matching completely or from the
-   beginning up to a slash.
-
 --shell::
 --perl::
 --python::
-- 
2.14.1.459.g238e487ea9



[PATCH v2 1/2] doc/for-each-ref: consistently use '=' to between argument names and values

2017-09-11 Thread Kevin Daudt
The synopsis and description inconsistently add a '=' between the
argument name and it's value. Make this consistent.

Signed-off-by: Kevin Daudt 
---
 Documentation/git-for-each-ref.txt | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index bb370c9c7..1015c88f6 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -10,8 +10,9 @@ SYNOPSIS
 [verse]
 'git for-each-ref' [--count=] [--shell|--perl|--python|--tcl]
   [(--sort=)...] [--format=] [...]
-  [--points-at ] [(--merged | --no-merged) []]
-  [--contains []] [--no-contains []]
+  [--points-at=]
+  (--merged[=] | --no-merged[=])
+  [--contains[=]] [--no-contains[=]]
 
 DESCRIPTION
 ---
@@ -65,24 +66,24 @@ OPTIONS
the specified host language.  This is meant to produce
a scriptlet that can directly be `eval`ed.
 
---points-at ::
+--points-at=::
Only list refs which points at the given object.
 
---merged []::
+--merged[=]::
Only list refs whose tips are reachable from the
specified commit (HEAD if not specified),
incompatible with `--no-merged`.
 
---no-merged []::
+--no-merged[=]::
Only list refs whose tips are not reachable from the
specified commit (HEAD if not specified),
incompatible with `--merged`.
 
---contains []::
+--contains[=]::
Only list refs which contain the specified commit (HEAD if not
specified).
 
---no-contains []::
+--no-contains[=]::
Only list refs which don't contain the specified commit (HEAD
if not specified).
 
-- 
2.14.1.459.g238e487ea9



RE: What's cooking in git.git (Sep 2017, #02; Mon, 11)

2017-09-11 Thread Kevin Willford
> 
> * kw/write-index-reduce-alloc (2017-09-08) 2 commits
>  - read-cache: fix index corruption with index v4
>  - Add t/helper/test-write-cache to .gitignore
> 
>  Expecting a reroll.
>  cf.  q...@mail.gmail.com>
> 
I didn't submit these patches so what would you like
me to do?

The reroll for read-cache fix was submitted here
https://public-inbox.org/git/20170907192412.8085-1-t.gumme...@gmail.com/

- Kevin



Re: RFC v3: Another proposed hash function transition plan

2017-09-11 Thread Brandon Williams
On 09/08, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
> > One thing I still do not know how I feel about after re-reading the
> > thread, and I didn't find the above doc, is Linus's suggestion to
> > use the objects themselves as NewHash-to-SHA-1 mapper [*1*].  
> > ...
> > [Reference]
> >
> > *1* 
> 
> I think this falls into the same category as the often-talked-about
> addition of the "generation number" field.  It is very tempting to
> add these "mechanically derivable but expensive to compute" pieces
> of information to the sha3-content while converting from
> sha1-content and creating anew.  

We didn't discuss that in the doc since this particular transition plan
we made uses an external NewHash-to-SHA1 map instead of an internal one
because we believe that at some point we would be able to drop
compatibility with SHA1.  Now I suspect that wont happen for a long time
but I think it would be preferable over carrying the SHA1 luggage
indefinitely.  At some point, then, we would be able to stop hashing
objects twice (once with SHA1 and once with NewHash) instead of always
requiring that we hash them with each hash function which was used
historically.

> 
> Because the "sha1-name" or the "generation number" can mechanically
> be computed, as long as everybody agrees to _always_ place them in
> the sha3-content, the same sha1-content will be converted into
> exactly the same sha3-content without ambiguity, and converting them
> back to sha1-content while pushing to an older repository will
> correctly produce the original sha1-content, as it would just be the
> matter of simply stripping these extra pieces of information.
> 
> The reason why I still feel a bit uneasy about adding these things
> (aside from the fact that sha1-name thing will be a baggage we would
> need to carry forever even after we completely wean ourselves off of
> the old hash) is because I am not sure what we should do when we
> encounter sha3-content in the wild that has these things _wrong_.
> An object that exists today in the SHA-1 world is fetched into the
> new repository and converted to SHA-3 contents, and Linus's extra
> "original SHA-1 name" field is added to the object's header while
> recording the SHA-3 content.  But for whatever reason, the original
> SHA-1 name is recorded incorrectly in the resulting SHA-3 object.

This wasn't one of the issues that I thought of but it just makes the
argument against adding sha1's to the sha3 content stronger.

> 
> The same thing could happen if we decide to bake "generation number"
> in the SHA-3 commit objects.  One possible definition would be that
> a root commit will have gen #0; a commit with 1 or more parents will
> get max(parents' gen numbers) + 1 as its gen number.  But somebody
> may botch the counting and records sum(parents' gen numbers) as its
> gen number.
> 
> In these cases, not just the SHA3-content but also the resulting
> SHA-3 object name would be different from the name of the object
> that would have recorded the same contents correctly.  So converting
> back to SHA-1 world from these botched SHA-3 contents may produce
> the original contents, but we may end up with multiple "plausibly
> looking" set of SHA-3 objects that (clain to) correspond to a single
> SHA-1 object, only one of which is a valid one.
> 
> Our "git fsck" already treats certain brokenness (like a tree whose
> entry has mode that is 0-padded to the left) as broken but still
> tolerate them.  I am not sure if it is sufficient to diagnose and
> declare broken and invalid when we see sha3-content that records
> these "mechanically derivable but expensive to compute" pieces of
> information incorrectly.
> 
> I am leaning towards saying "yes, catching in fsck is enough" and
> suggesting to add generation number to sha3-content of the commit
> objects, and to add even the "original sha1 name" thing if we find
> good use of it.  But I cannot shake this nagging feeling off that I
> am missing some huge problems that adding these fields and opening
> ourselves to more classes of broken objects.
> 
> Thoughts?
> 
> 

-- 
Brandon Williams


Re: --work-tree does not work for git-stash

2017-09-11 Thread Allen Li
On Mon, Sep 11, 2017 at 11:32 AM, Allen Li  wrote:
> $ git --version
> git version 2.14.1.581
>
> This does not work:
>
> $ git --git-dir ~/foo/.git --work-tree ~/foo stash create
> fatal: /usr/lib/git-core/git-stash cannot be used without a working tree.
>
> This does:
>
> $ git --git-dir ~/foo/.git --work-tree ~/foo -C ~/foo stash create
>
> I found a description of the bug here:
>
> https://stackoverflow.com/a/5863555

I think that this bug may be quite serious.

If you were to run:

$ git --git-dir ~/tmp/.git stash

This will actually stash using your current directory as the worktree,
which could potentially screw up things quite seriously.  In my case,
I had an unstaged file at ~/tmp/tmp, so Git decided to remove the
entire ~/tmp directory as my current directory was ~ and I have a git
repo in ~ for my dotfiles.


Re: [idea] File history tracking hints

2017-09-11 Thread Jacob Keller
On Mon, Sep 11, 2017 at 11:11 AM, Stefan Beller  wrote:
> On Mon, Sep 11, 2017 at 12:11 AM, Pavel Kretov  wrote:
>> Hi all,
>>
>> Excuse me if the topic I'm going to raise here has been already discussed
>> on the mailing list, forums, or IRC, but I couldn't find anything related.
>>
>>
>> The problem:
>>
>> Git, being "a stupid content tracker", doesn't try to keep an eye on
>> operations which happens to individual files; things like file renames
>> aren't recorded during commit, but heuristically detected later.
>>
>> Unfortunately, the heuristic can only deal with simple file renames with
>> no substantial content changes; it's helpless when you:
>>
>>  - rename file and change it's content significantly;
>>  - split single file into several files;
>>  - merge several files into another;
>>  - copy entire file from another commit, and do other things like these.
>>
>> However, if we're able to preserve this information, it's possible
>> not only to do more accurate 'git blame', but also merge revisions with
>> fewer conflicts.
>>
>>
>> The proposal:
>>
>> The idea is to let user give hints about what was changed during
>> the commit. For example, if user did a rename which wasn't automatically
>> detected, he would append something like the following to his commit
>> message:
>>
>> Tracking-hints: rename dev-vcs/git/git-1.0.ebuild ->
>> dev-vcs/git/git-2.0.ebuild
>>
>> or (if full paths of affected files can be unambiguously omitted):
>>
>> Tracking-hints: rename git-1.0.ebuild -> git-2.0.ebuild
>>
>> There may be other hint types:
>>
>> Tracking-hint: recreate LICENSE.txt
>> Tracking-hint: split main.c -> main.c cmdline.c
>> Tracking-hint: merge linalg.py <- vector.py matrix.py
>>
>> or even something like this:
>>
>> Tracking-hint: copy json.py <-
>> libs/json.py@4db88291251151d8c5c8e4f20430fa4def2cb2ed
>>
>> If file transformation cannot be described by a single tracking hint, it 
>> shall
>> be possible to specify a sequence of hints at once:
>>
>> Tracking-hint:
>> split Utils.java -> AppHelpers.java StringHelpers.java
>> recreate Utils.java
>>
>> Note that in the above example the order of operations really matters, so
>> both lines have to reside in one 'Tracking-hint' block.
>>
>> * * *
>>
>> How do you think, is this idea worth implementing?
>> Any other thoughts on this?
>>
>> -- Pavel Kretov.
>
> This was discussed a couple of times on the mailing list
> (though not recently).
>
> I searched for "rename tracking files site:public-inbox.org/git"
> and came up with
> https://public-inbox.org/git/pine.lnx.4.58.0504141102430.7...@ppc970.osdl.org/
> (the nearby emails seem to also be relevant to this discussion)
>
> tl:dr: When encoding these hints, you do it at commit time,
> but the heuristic can be improved upon later.
> So you can assume the heuristic is better for the
> common case, as someone will fix the heuristic for the
> common case. Also Gits model is to track objects.

Linus has a pretty long post about this, it's somewhere in that
discussion. Essentially, if you bake in rename detection (or other
hints) at commit time, then you're stuck with it forever.

Additionally, there are similar but not *quite* the same operations
which you probably wouldn't bake into at the start, and the types of
questions a user wants to ask isn't known at commit time, but rather
known at *debug* time in the future when you're digging up history. In
this time frame, the user does know what to care about and what kind
of questions to ask, so it's already natural to ask these questions at
that time.

Additionally, if you have to generate the heuristic every commit,
you're increasing time "wasted" every commit, where as doing the
lookup later when a user starts asking questions like during blame or
diff would only add time during an operation the user already expects
to take some time.

Thanks,
Jake


Re: [idea] File history tracking hints

2017-09-11 Thread Jeff King
On Mon, Sep 11, 2017 at 10:11:31AM +0300, Pavel Kretov wrote:

> Unfortunately, the heuristic can only deal with simple file renames with
> no substantial content changes; it's helpless when you:
> 
>  - rename file and change it's content significantly;
>  - split single file into several files;
>  - merge several files into another;
>  - copy entire file from another commit, and do other things like these.
> 
> However, if we're able to preserve this information, it's possible
> not only to do more accurate 'git blame', but also merge revisions with
> fewer conflicts.

This is definitely something that's been discussed before on the list
(though I'm not sure of the best keywords to dig for; Stefan found one
thread but I know there have been others).

And I don't think it's a totally unreasonable idea, but there are some
complications. The biggest one is that renames are really part of a
_diff_ between two endpoints. We think of them as attached to a commit
because we tend to talk about commits as a diff from state A to state B.

So obviously in the diff HEAD^ versus HEAD, we can look at the hints for
HEAD. But what about "git diff v1.0 v1.1", that may cover multiple
commits? Right now Git doesn't look at the intermediate commits at all.
And in fact we may not even know what they are, if the command is fed
two trees. Or the two endpoints may not have a sensible history (e.g.,
consider diffing between two branches, one of which has been rebased).

But even if we had a sensible set of commits to pull hints from (e.g.,
if v1.0 and v1.1 were in a linear relationship), it's not clear to me
how you would want to apply them to an end-to-end diff.

So I don't think that these kind of tracking hints make sense for a lot
of diffs (including merges, which use diffs between the endpoints and
the merge base).

Which isn't to say that they're useless. I agree that something like
"--follow" could benefit from an annotation that tells us when and how
to pick up the next step in the traversal. But of course somebody has to
make those annotations. If we had a tool to do it automatically, then we
could apply the same tool at run-time later.

But maybe if it were an optional annotation, people would want to use it
when the normal rename logic doesn't kick in. So perhaps a baby step in
this direction would be to teach something like "--follow" to "jump"
across a non-rename when it sees a special marking in the commit
message.

-Peff


--work-tree does not work for git-stash

2017-09-11 Thread Allen Li
$ git --version
git version 2.14.1.581

This does not work:

$ git --git-dir ~/foo/.git --work-tree ~/foo stash create
fatal: /usr/lib/git-core/git-stash cannot be used without a working tree.

This does:

$ git --git-dir ~/foo/.git --work-tree ~/foo -C ~/foo stash create

I found a description of the bug here:

https://stackoverflow.com/a/5863555


Re: [idea] File history tracking hints

2017-09-11 Thread Stefan Beller
On Mon, Sep 11, 2017 at 12:11 AM, Pavel Kretov  wrote:
> Hi all,
>
> Excuse me if the topic I'm going to raise here has been already discussed
> on the mailing list, forums, or IRC, but I couldn't find anything related.
>
>
> The problem:
>
> Git, being "a stupid content tracker", doesn't try to keep an eye on
> operations which happens to individual files; things like file renames
> aren't recorded during commit, but heuristically detected later.
>
> Unfortunately, the heuristic can only deal with simple file renames with
> no substantial content changes; it's helpless when you:
>
>  - rename file and change it's content significantly;
>  - split single file into several files;
>  - merge several files into another;
>  - copy entire file from another commit, and do other things like these.
>
> However, if we're able to preserve this information, it's possible
> not only to do more accurate 'git blame', but also merge revisions with
> fewer conflicts.
>
>
> The proposal:
>
> The idea is to let user give hints about what was changed during
> the commit. For example, if user did a rename which wasn't automatically
> detected, he would append something like the following to his commit
> message:
>
> Tracking-hints: rename dev-vcs/git/git-1.0.ebuild ->
> dev-vcs/git/git-2.0.ebuild
>
> or (if full paths of affected files can be unambiguously omitted):
>
> Tracking-hints: rename git-1.0.ebuild -> git-2.0.ebuild
>
> There may be other hint types:
>
> Tracking-hint: recreate LICENSE.txt
> Tracking-hint: split main.c -> main.c cmdline.c
> Tracking-hint: merge linalg.py <- vector.py matrix.py
>
> or even something like this:
>
> Tracking-hint: copy json.py <-
> libs/json.py@4db88291251151d8c5c8e4f20430fa4def2cb2ed
>
> If file transformation cannot be described by a single tracking hint, it shall
> be possible to specify a sequence of hints at once:
>
> Tracking-hint:
> split Utils.java -> AppHelpers.java StringHelpers.java
> recreate Utils.java
>
> Note that in the above example the order of operations really matters, so
> both lines have to reside in one 'Tracking-hint' block.
>
> * * *
>
> How do you think, is this idea worth implementing?
> Any other thoughts on this?
>
> -- Pavel Kretov.

This was discussed a couple of times on the mailing list
(though not recently).

I searched for "rename tracking files site:public-inbox.org/git"
and came up with
https://public-inbox.org/git/pine.lnx.4.58.0504141102430.7...@ppc970.osdl.org/
(the nearby emails seem to also be relevant to this discussion)

tl:dr: When encoding these hints, you do it at commit time,
but the heuristic can be improved upon later.
So you can assume the heuristic is better for the
common case, as someone will fix the heuristic for the
common case. Also Gits model is to track objects.


Re: [PATCH 0/4] Test name-rev with small stack

2017-09-11 Thread Jeff King
On Fri, Sep 08, 2017 at 02:33:35PM +0200, Michael J Gruber wrote:

> Looking at it more closely, the solution in cbc60b6720 ("git tag
> --contains: avoid stack overflow", 2014-04-24) seems to be a bit "ad
> hoc" to me:
> 
> First of all, there is more than "tag --contains" that may exceed the
> stack by recursion. So I would expect the solution to be more general,
> and not localised and specialised to builtin/tag.c

At the time, tag was the only one using this depth-first contains
algorithm. It's since been adapted to ref-filter.c, but of course the
stack handling went with it.

Most traversals have a date-sorted queue, so are effectively doing a
breadth-first iteration with no recursion.

> Second, this is a walk, so I'm wondering whether our revision walk
> machinery should be the place to add missing functionality (if any).
> That way, everything would benefit from possible or existing
> improvements there. For example, I think some of our "extra walkers"
> don't heed object replacements. (I need to test more.)

It's possible that name-rev could make better use of the existing
traversal machinery. It's often tough to do so, though, because that
machinery gives you a linearized ordering of the commits. Whereas
something like name-rev really cares about the order that it visits the
commits, because it's building up the names.

It's the same for this "tag --contains" traversal. It _used_ to be a
series of merge-base computations. But by doing a custom traversal, we
can cache incremental results through the graph and avoid walking over
the same bits multiple times. There actually is a way to do it with the
regular breadth-first traversal, but you have to store one bit per ref
you're checking for each commit.

I played around with that a bit a while ago, and it did seem to work. I
can dig up the patches if you're interested. But one downside is that
one bit per ref per commit adds up if you have a lot of refs. A large
number of those bitfields will be the same, so you could probably get by
with a copy-on-write scheme, but I never implemented that.

Of course somebody may have a more clever algorithm, too. I don't claim
the above is a proof. ;)

-Peff


Re: Unexpected pass for t6120-describe.sh on cygwin

2017-09-11 Thread Jeff King
On Sun, Sep 10, 2017 at 02:27:47PM +0200, Michael J Gruber wrote:

> This apparantly expects "ulimit -s" to fail on platforms that don't
> support it, so set the prereq accordingly. I moved the following to
> t/test-lib.sh:
> 
> run_with_limited_stack () {
> (ulimit -s 128 && "$@")
> }
> 
> test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'
> 
> Same things as above. Two things to note:
> - Those requisites could be the same, also they are used in different ways.
> - "ulimit -s" returning success without doing anything means that, all
> along, we ran the existing tests when we didn't mean to (on Win), and
> they succeeded for the wrong reason, which we did not notice.

Right, if ulimit doesn't actually limit, then the test isn't really
accomplishing anything. But we likely have several tests in our suite
that do that. As long as they do something on _some_ platforms, they're
still useful. And as long as their failure mode is a false-pass, they
don't bother people on the other platforms.

So I think one option is to just leave it.

> So, I guess, short of testing the effect of "ulimit -s" with another
> expensive test, it's best to simply set these prerequisites based on
> "uname -s".

You can make a cheap test that uses a lot of stack. E.g., this program
runs in about 3ms on my machine, and you can reliably run "ulimit -s 128
&& ./a.out >/dev/null" to detect it segfaulting:

-- >8 --
#include 

/*
 * Our goal is to use a lot of stack space relatively cheaply. To do that,
 * allocate a big stack buffer and recurse. But we take a few precautions to
 * avoid a clever compiler optimizing away our stack:
 *
 *   - we need to use the buffer so that it can't be eliminated
 *
 *   - we recurse after touching the buffer but before printing it,
 * which makes it hard to do tail-recursion.
 */
static void foo(unsigned x)
{
size_t i;
unsigned char buf[1024];

if (!x)
return;

for (i = 0; i < sizeof(buf); i++)
buf[x] = x & 0xff;

foo(x - 1);

fwrite(buf, 1, sizeof(buf), stdout);
}

int main(void)
{
foo(128);
return 0;
}
-- 8< --

One downside is that it means git's test suite would (on a successful
run) stimulate segfaults, which are sometimes tracked and logged by the
kernel (or may even generate coredumps outside of the test suite area).

-Peff


Re: commit-msg hook does not run on merge with --no-ff option

2017-09-11 Thread Stefan Beller
On Mon, Sep 11, 2017 at 7:34 AM, Joseph Dunne  wrote:

> When I merge ... however my commit-msg hook does not run.  (The
> commit-msg hook works fine in all other commits / merges.)

When using git-commit, but not git-merge?

See the discussion of patches at
https://public-inbox.org/git/20170907220429.31312-1-sbel...@google.com/


Re: [PATCHv3] builtin/merge: honor commit-msg hook for merges

2017-09-11 Thread Stefan Beller
On Thu, Sep 7, 2017 at 6:13 PM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>>  The --no-verify option however is not remembered across invocations
>> of git-merge. Originally the author assumed an alternative in which the
>> 'git merge --continue' command accepts the --no-verify flag, but that
>> opens up the discussion which flags are allows to the continued merge
>> command and which must be given in the first invocation.
>
> This leaves a reader (me) wondering what the final conclusion was,
> after the author assumed something and thought about alternatives.

I did not draw a conclusion, I was just saying, that this has to be
thought about.
It looks to me as if --continue currently wants to take no extra arguments,
but to remember all flags from the previous invocation of merge.

But that only looks this way as all the command line flags are related
for tree manipulation, not (indirect) commit message manipulation.

So I think having --no-verify be respected (either by restating, or by
remembering, or both) by the `git merge --continue` call would be a
reasonable thing to want.

So that new patch just added the test as a #needswork for the future,
not actually making a decision how to approach it.

> I am guessing that your final decision was not to remember
> "--no-verify" so a user who started "merge --no-verify" that stopped
> in the middle must say "merge --continue --no-verify" or "commit
> --no-verify" to conclude the merge?  Or you added some mechanism to
> remember the fact that no-verify was given so that "merge --continue"
> will read from there, ignoring "merge --continue --verify" from the
> command line?  Not just the above part of the log message confusing,
> but there is no update to the documentation, and we shouldn't expect
> end-users to find out what ought to happen by reading t7504 X-<.

Interestingly the documentation that I read to approach the problem
is already in shape as it would not specify the specific command for the
'--no-verify' option. I missed that we need to add documentation for
the continued merge case.

> The new test in t7504 tells me that you remember --[no-]verify from
> the initial invocation and use the same when --continue is given; it
> is unclear how that remembered one interacts with --[no-]verify that
> is given when --continue is given.  It is not documented, tested and
> explained in the log message.  I would expect that the command line
> trumps what was given in the initial invocation.

I would expect that, too.

>
>
>> +static int verify_msg = 1;
>>
>>  static struct strategy all_strategy[] = {
>>   { "recursive",  DEFAULT_TWOHEAD | NO_TRIVIAL },
>> @@ -236,6 +237,7 @@ static struct option builtin_merge_options[] = {
>> N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
>>   OPT_BOOL(0, "overwrite-ignore", _ignore, N_("update ignored 
>> files (default)")),
>>   OPT_BOOL(0, "signoff", , N_("add Signed-off-by:")),
>> + OPT_BOOL(0, "verify", _msg, N_("verify commit-msg hook")),
>>   OPT_END()
>>  };
>
> I suspect that the previous iteration gives a much better end-user
> experience when "git merge -h" is used.  This will give the
> impression that the user MUST say "merge --verify" if the user wants
> to verify commit-msg hook (whatever that means), but because the
> option defaults to true, that is not what happens.  The user instead
> must say "merge --no-verify" if the verification is unwanted.

ok, will revert to that in a resend.

>> +test_expect_failure 'merge --continue remembers --no-verify' '
>> + test_when_finished "git branch -D newbranch" &&
>> + test_when_finished "git checkout -f master" &&
>> + git checkout master &&
>> + echo a >file2 &&
>> + git add file2 &&
>> + git commit --no-verify -m "add file2 to master" &&
>> + git checkout -b newbranch master^ &&
>> + echo b >file2 &&
>> + git add file2 &&
>> + git commit --no-verify file2 -m in-side-branch &&
>> + git merge --no-verify -m not-rewritten-by-hook master &&
>> + # resolve conflict:
>> + echo c >file2 &&
>> + git add file2 &&
>> + git merge --continue &&
>> + commit_msg_is not-rewritten-by-hook
>>  '
>
> OK.  What should happen when the last "merge --continue" was given
> "--verify" at the same time?

Currently not possible, due to --continue requiring that it is the
only argument. In the future where --continue works well with other
arguments, we should override the original.

> A similar test whose title is
> "--no-verify remembered by merge --continue can be overriden" may be
> a good thing to follow this one, perhaps?

Note that this is already test_expect_failure, which I used to mark
that this particular flag is broken across a --continue invocation of git-merge,
so I would not add yet another test that describes the future yet to be
implemented?

Thanks.


Re: [PATCH v1 2/2] travis-ci: skip a branch build if equal tag is present

2017-09-11 Thread SZEDER Gábor
> If we push a branch and a tag pointing to the HEAD of this branch,

s/the HEAD of//, perhaps?
There is no such thing as "HEAD" (all capital!) of a branch, is it?

> then Travis CI would run the build twice. This wastes resources and

Nit: s/run the build/build and test the same tree/, to further stress
that the two builds are redundant.

> slows the testing.
> 
> Add a function to detect this situation and skip the build the branch

s/skip the build/skip building/ ?

> if appropriate. Invoke this function on every build.
> 
> Helped-by: Junio C Hamano 
> Signed-off-by: Lars Schneider 
> ---
>  ci/lib-travisci.sh | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
> index 44d6ba2dd2..9c4ae9bdd0 100755
> --- a/ci/lib-travisci.sh
> +++ b/ci/lib-travisci.sh
> @@ -1,5 +1,28 @@
>  # Library of functions shared by all CI scripts
>  
> +skip_branch_tip_with_tag () {
> + # Sometimes, a branch is pushed at the same time the tag that points
> + # at the same commit as the tip of the branch is pushed, and building
> + # both at the same time is a waste.
> + #
> + # Travis gives a tagname e.g. v2.14.0 in $TRAVIS_BRANCH when
> + # the build is triggered by a push to a tag.  Let's see if
> + # $TRAVIS_BRANCH is exactly at a tag, and if so, if it is
> + # different from $TRAVIS_BRANCH.  That way, we can tell if
> + # we are building the tip of a branch that is tagged and
> + # we can skip the build because we won't be skipping a build
> + # of a tag.
> +
> + if TAG=$(git describe --exact-match "$TRAVIS_BRANCH" 2>/dev/null) &&
> + $TAG != $TRAVIS_BRANCH

This must be

[ $TAG != $TRAVIS_BRANCH ]

otherwise the shell will rightfully complain:

  $ TRAVIS_BRANCH=v2.14.0 ./ci/lib-travisci.sh 
  ./ci/lib-travisci.sh: line 17: v2.14.0: command not found

Furthermore, I would prefer quotes around $TAG and $TRAVIS_BRANCH.  If
either one of those two variables were empty (or contain multiple
words) at that point, the shell would complain.  Now, I don't think
that either can end up being empty, so quotes are not necessary, but
having quotes around them would save future readers from spending
brain cycles on this unnecessarily.

> + then
> + echo "Tip of $TRAVIS_BRANCH is exactly at $TAG"
> + exit 0
> + fi
> +}
> +
>  # Set 'exit on error' for all CI scripts to let the caller know that
>  # something went wrong
>  set -e
> +
> +skip_branch_tip_with_tag
> -- 
> 2.14.1
> 
> 


FEDERAL BUREAU OF INVESTIGATION

2017-09-11 Thread Andrew G. McCabe
Hi,

I am Andrew McCabe the United States FBI director charge, am hereby announcing 
to you that your ATM Card fund from Benin Republic government authorities, and 
Mrs. Jane Frederick, came forward and claimed that they are having problem in 
the process of your Card.

This is to bring to your notice that we have just been informed through secrete 
source that the fund will be cancel at any time without date, the lady that 
contacted us, earlier and presented some documentations evidence that you have 
chose to ignore their messages.

I want to personally assure you once again that you will have every course to 
smile and be happy upon conclusion of this project, as we are monitoring all 
they service with them in any level as well as your correspondence, until you 
receive your ATM Card fund, as an LEGAL OWNER, we are here to protect your 
interest and that is the reason why we are doing all we can to make sure all 
goes well, this is a huge amount of money which we don’t wish for you to 
lose.contact United Bank For African, with below info, and you need to pay the 
required Custom Clearance Certificate charges as imposed to enable them route 
your fund to you with immediate effect. This is a life time opportunity and we 
will advise you to take advantage of it, before it will be too late.

Director Name :Hon. Benjamin Adam
E-Mail: unitedbankcoto...@gmail.com


God bless you!

Thanks.

Yours in service

Best Regards

Andrew G. McCabe

BADGE – JTT047101
FEDERAL BUREAU OF INVESTIGATION
UNITED STATES DEPARTMENT OF JUSTICE
WASHINGTON, D.C. 20535


commit-msg hook does not run on merge with --no-ff option

2017-09-11 Thread Joseph Dunne
I’ve globally configured git master branch to use the –no-ff option in
my .gitconfig file:
[branch "master"]
mergeoptions = “-–no-ff”

When I merge a branch into master that would normally be a fast
forward merge, the merge happens fine and follows the option –no-ff,
creating a new commit, however my commit-msg hook does not run.  (The
commit-msg hook works fine in all other commits / merges.)

I tried changing my commit-msg hook to just be “exit 1” and it doesn’t
abort a no-ff merge, so I’m certain the hook is just not being
executed.


Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported

2017-09-11 Thread Ben Peart



On 9/10/2017 11:27 PM, Junio C Hamano wrote:

Junio C Hamano  writes:


I still think we would want to turn warning() to die(), but it
probably is better to do so in a separate follow-up patch.  That
will give us a good place to record the reason why the current "just
call a warning() and pretend as if nothing bad happend" is wrong.


And here is such an update.  It seems that pretty much all comments
in the original thread were "warning is wrong--we should die here",
but nobody seems to have bothered following it through.

cf. <20170815111725.5d009...@twelve2.svl.corp.google.com>

-- >8 --
Subject: [PATCH] subprocess: loudly die when subprocess asks for an unsupported 
capability

The handshake_capabilities() function first advertises the set of
capabilities it supports, so that the other side can pick and choose
which ones to use and ask us to enable in its response.  Then we
read the response that tells us what choice the other side made.  If
we saw something that we never advertised, that indicates one of two
things.  The other side, i.e. the "upgraded" filter, is not paying
attention of the capabilities advertisement, and asking something
its correct operation relies on, but we are not capable of giving
that unknown feature and operate without it, so after that point the
exchange of data is a garbage-in-garbage-out.  Or the other side
wanted to ask for one of the capabilities we advertised, but the
code has typo and their wish to enable a capability that its correct
operation relies on is not understood on this end.  The result is
the same garbage-in-garbage-out.

Instead of sweeping such a potential bug under the rug, die loudly
when we see a request for an unsupported capability in order to
force sloppily-written filter scripts to get corrected.



The documentation states "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:"


Anything else is clearly a bug so a "die" is more appropriate than a 
warning.


Patch looks good.  Thanks for making sure this didn't fall through the 
cracks.



Signed-off-by: Junio C Hamano 
---
  sub-process.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sub-process.c b/sub-process.c
index fcc4832c14..ec9a51b7b1 100644
--- a/sub-process.c
+++ b/sub-process.c
@@ -181,8 +181,8 @@ static int handshake_capabilities(struct child_process 
*process,
if (supported_capabilities)
*supported_capabilities |= capabilities[i].flag;
} else {
-   warning("subprocess '%s' requested unsupported capability 
'%s'",
-   process->argv[0], p);
+   die("subprocess '%s' requested unsupported capability 
'%s'",
+   process->argv[0], p);
}
}
  



Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

2017-09-11 Thread Johannes Schindelin
Hi Junio,

On Mon, 11 Sep 2017, Junio C Hamano wrote:

> Stepping back a bit, I am not sure if it is sane or even valid for the
> end-user to modify paths outside sparse-checkout area, but that is
> probably a separate tangent.

That is not at all the scenario that Kevin fixed. Just have a quick look
at the regression test: in a sparse checkout, the user checked out a
branch, then called `reset` to switch to a different commit. No file was
touched by the user outside the sparse checkout.

Yet without Kevin's fix, `git status` would report that the user *deleted
files outside the sparse checkout*.

That is such an obvious bug, and Kevin's fix is such an obvious
improvement over the current upstream Git version, that I would think the
only thing worth discussing is whether the patch goes about it in a way of
which you approve.

For example, you mentioned that you would want to move the declaration of
`two` and `was_missing` into the conditional code block. That is a valid
suggestion for `was_missing` (but of course not for `two`, which is used
in the condition of the code block). That suggestion is more about code
style (and of course easily fixed by Kevin using Edit>Refactor>Move
Definition Location in VS), though, than about the correctness of the post
image.

Much more interesting would be a review of the conditional code block. And
I am not talking about the camelCasing of `ceBefore` (which will be fixed
as easily by Edit>Refactor>Rename). I am talking about the stuff where
tools cannot help, but where your experience is necessary: is it correct
to use make_cache_entry()/checkout_entry() in this case? Are the
parameters passed to those functions correct? Is the call to
cache_name_pos() followed by ce_skip_worktree() the best way to find out
whether the file that is absent was not actually deleted by the user, or
is there a less CPU-intensive way, seeing as we are already guaranteed to
iterate over the queue diff in alphabetical order?

I understand that those latter questions are a lot harder to answer, sorry
about that.

Ciao,
Dscho


Re: Unexpected pass for t6120-describe.sh on cygwin

2017-09-11 Thread Adam Dinwoodie
On Sat, Sep 09, 2017 at 02:13:32PM +0100, Ramsay Jones wrote:
> I ran the test-suite on the 'pu' branch last night (simply because
> that was what I had built at the time!), which resulted in a PASS,
> but t6120 was showing a 'TODO passed' for #52.

Confirmed, I also see this unexpected pass.

> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'
> branch, which uses 'ulimit -s' to try and force a stack overflow.
> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created
> a test program (see below) to eat up the stack and tried running it
> with various ulimit values (128, 12, 8), but it always seg-faulted
> at the same stack-frame. (after using approx 2MB stack space).

Yes, Cygwin does not implement the ulimit API from the Single Unix
Specification, per https://cygwin.com/cygwin-api/std-notimpl.html.  I
suspect the Bash builtin still exists because (a) nobody has bothered to
remove it, (b) including it avoids breaking scripts that assume it
exists but don't particularly rely on its output being sensical, or
(c) both.

> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled
> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,
> but haven't looked into it.
> 
> Given that 'ulimit' is a bash built-in, this may also be a problem
> on MinGW and Git-For-Windows, but I can't test on those platforms.

I'll leave this to the relevant folks to test; I don't have a useful
test environment for those either.  That said, I'll note the comment in
t6120 says the ULIMIT_STACK_SIZE prerequisite excludes running the test
on Windows, so I assume it's not a problem there.

On Sun, Sep 10, 2017 at 05:58:49PM +0100, Ramsay Jones wrote:
> On 10/09/17 13:27, Michael J Gruber wrote:
> > So, I guess, short of testing the effect of "ulimit -s" with another
> > expensive test, it's best to simply set these prerequisites based on
> > "uname -s".
> 
> Yes, I was going to suggest adding !CYGWIN to the test(s) (or perhaps
> to the 'test_lazy_prereq' expression(s)).

Given the issue is Cygwin not implementing ulimit at all, but Cygwin
Bash pretending everything's fine, I think handling this as a special
case for Cygwin seems like the correct approach.  Something like the
below, based on the existing code in test-lib.sh for the PIPE prereq?

-- >8 --
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 83f5d3dd2..376cd91ae 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1166,14 +1166,32 @@ test_lazy_prereq UNZIP '
test $? -ne 127
 '
 
+# On Cygwin, ulimit has no effect because the underlying API hasn't been
+# implemented.  Just fail if trying to do something with ulimit.
 run_with_limited_cmdline () {
-   (ulimit -s 128 && "$@")
+   case $(uname -s) in
+   CYGWIN*)
+   false
+   ;;
+   *)
+   (ulimit -s 128 && "$@")
+   ;;
+   esac
 }
 
 test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
 
+# On Cygwin, ulimit has no effect because the underlying API hasn't been
+# implemented.  Just fail if trying to do something with ulimit.
 run_with_limited_stack () {
-   (ulimit -s 128 && "$@")
+   case $(uname -s) in
+   CYGWIN*)
+   false
+   ;;
+   *)
+   (ulimit -s 128 && "$@")
+   ;;
+   esac
 }
 
 test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'


Executable File Violation

2017-09-11 Thread IT
You attempted to send a message that contained an executable file.  Our company 
policy prohibits the sending of executable files via email.  The message was 
not delivered.


Re: Commit dropped when swapping commits with rebase -i -p

2017-09-11 Thread Sebastian Schuberth
On 2017-09-02 02:04, Jonathan Nieder wrote:

>> Anyway, this should really more explicitly say *what* you need to know
>> about, that is, reordering commits does not work.
> 
> It tries to explain that, even with an example.  If you have ideas for
> improving the wording, that would be welcome.

As a first step, I indeed believe the wording must the stronger / clearer. How 
about this:

>From f69854ce7b9359603581317d152421ff6d89f345 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth 
Date: Mon, 11 Sep 2017 10:41:27 +0200
Subject: [PATCH] docs: use a stronger wording when describing bugs with rebase 
-i -p

Signed-off-by: Sebastian Schuberth 
---
 Documentation/git-rebase.txt | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 6805a74aec..ccd0a04d54 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -782,10 +782,11 @@ case" recovery too!
 
 BUGS
 
-The todo list presented by `--preserve-merges --interactive` does not
-represent the topology of the revision graph.  Editing commits and
-rewording their commit messages should work fine, but attempts to
-reorder commits tend to produce counterintuitive results.
+Be careful when combining the `-i` / `--interactive` and `-p` /
+`--preserve-merges` options.  Reordering commits will drop commits from the
+main line. This is because the todo list does not represent the topology of the
+revision graph in this case.  However, editing commits and rewording their
+commit messages 'should' work fine.
 
 For example, an attempt to rearrange
 
-- 
2.14.1.windows.1


[idea] File history tracking hints

2017-09-11 Thread Pavel Kretov
Hi all,

Excuse me if the topic I'm going to raise here has been already discussed
on the mailing list, forums, or IRC, but I couldn't find anything related.


The problem:

Git, being "a stupid content tracker", doesn't try to keep an eye on
operations which happens to individual files; things like file renames
aren't recorded during commit, but heuristically detected later.

Unfortunately, the heuristic can only deal with simple file renames with
no substantial content changes; it's helpless when you:

 - rename file and change it's content significantly;
 - split single file into several files;
 - merge several files into another;
 - copy entire file from another commit, and do other things like these.

However, if we're able to preserve this information, it's possible
not only to do more accurate 'git blame', but also merge revisions with
fewer conflicts.


The proposal:

The idea is to let user give hints about what was changed during
the commit. For example, if user did a rename which wasn't automatically
detected, he would append something like the following to his commit
message:

Tracking-hints: rename dev-vcs/git/git-1.0.ebuild ->
dev-vcs/git/git-2.0.ebuild

or (if full paths of affected files can be unambiguously omitted):

Tracking-hints: rename git-1.0.ebuild -> git-2.0.ebuild

There may be other hint types:

Tracking-hint: recreate LICENSE.txt
Tracking-hint: split main.c -> main.c cmdline.c
Tracking-hint: merge linalg.py <- vector.py matrix.py

or even something like this:

Tracking-hint: copy json.py <-
libs/json.py@4db88291251151d8c5c8e4f20430fa4def2cb2ed

If file transformation cannot be described by a single tracking hint, it shall
be possible to specify a sequence of hints at once:

Tracking-hint:
split Utils.java -> AppHelpers.java StringHelpers.java
recreate Utils.java

Note that in the above example the order of operations really matters, so
both lines have to reside in one 'Tracking-hint' block.

* * *

How do you think, is this idea worth implementing?
Any other thoughts on this?

-- Pavel Kretov.