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

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

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

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,

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

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

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

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.

I NEED YOUR URGENT ASSISTANT

-- 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)

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

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

Re: [idea] File history tracking hints

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

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

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

Re: [idea] File history tracking hints

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

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

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

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

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

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

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

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

> > * 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

Re: RFC v3: Another proposed hash function transition plan

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*]. > > ... >

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

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: >

Re: [idea] File history tracking hints

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

Re: [idea] File history tracking hints

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;

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

$ 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

Re: [idea] File history tracking hints

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

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

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 >

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

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 && "$@") > } >

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

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

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

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'

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

> 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

FEDERAL BUREAU OF INVESTIGATION

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

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

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

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

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

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

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

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

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

Executable File Violation

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

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.

[idea] File history tracking hints

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