Re: BUG: attempt to trim too many characters

Just reminding people that this issue would seem to still exist in current master.. It's trivial to show: [torvalds@i7 git]$ git bisect start [torvalds@i7 git]$ git bisect bad master [torvalds@i7 git]$ git bisect good master~5 Bisecting: 23 revisions left to test after this (roughly

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

On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford wrote: > > Sorry. It was not in the sparse-checkout file. > $ git config core.sparsecheckout true > $ echo /i > .git/info/sparse-checkout > $ git checkout -f > was ran in the modified file case as well and "i" was the only

Re: [PATCH] format-patch: use raw format for notes

On Tue, Sep 12, 2017 at 10:33:37AM -0700, Stefan Beller wrote: > On Sun, Sep 10, 2017 at 9:27 PM, Sam Bobroff wrote: > > > (If only there were a way to set the coverletter text automatically as > > well...) > > > > Checkout branch..description AH! I had seen this

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

> From: Jacob Keller [mailto:jacob.kel...@gmail.com] > Sent: Tuesday, September 12, 2017 4:29 PM > > On Tue, Sep 12, 2017 at 1:20 PM, Kevin Willford wrote: > > > > I think this is where I need to do a better job of explaining so here is a > > simple example. > > > > I have

[PATCH] doc: fix minor typos (extra/duplicated words)

Following are several fixes for duplicated words ("of of") and one case where an extra article ("a") slipped in. Signed-off-by: Evan Zacks --- Documentation/git-cat-file.txt | 2 +- Documentation/git-checkout.txt | 2 +- Documentation/git-notes.txt| 2 +-

[RFC v2] refs: strip out not allowed flags from ref_transaction_update

Callers are only allowed to pass certain flags into ref_transaction_update, other flags are internal to it. To prevent mistakes from the callers, strip the internal only flags out before continuing. This was noticed because of a compiler warning gcc 7.1.1 issued about passing a NULL parameter as

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

Am 20.08.2017 um 11:06 schrieb Jeff King: > I actually think it would be reasonable to omit the empty directory in > t5004. The main thing we care about there is that we produce an archive > with no files rather than barfing. Checking that the empty directory is > actually there was mostly "this

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

On Tue, Sep 12, 2017 at 1:20 PM, Kevin Willford wrote: >> From: Junio C Hamano [mailto:gits...@pobox.com] >> Sent: Monday, September 11, 2017 9:57 PM >> >> Let's imagine a path P that is outside the sparse checkout area. >> And we check out a commit that has P. P would

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

> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Monday, September 11, 2017 9:57 PM > > 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.

GERARD SANCHEZ

"My name is Gerard Sanchez , a real estate agent presently based in UAE. I have been diagnosed with Oesophageal cancer. I have been on medical treatment after which it was confirmed by my doctor that I have cancer in 2012. The sad part now is that it has also been confirmed that i may not live

[no subject]

<>

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

Sorry I don't understand your question. The commit-msg hook runs properly in all cases except when I perform a merge with the --no-ff option enabled. On Mon, Sep 11, 2017 at 12:25 PM, Stefan Beller wrote: > On Mon, Sep 11, 2017 at 7:34 AM, Joseph Dunne

Re: SHA1 collision in production repo?! (probably not)

On Tue, Sep 12, 2017 at 06:18:32PM +0200, Lars Schneider wrote: > we are seeing this now in Git 2.14.1: > > ... > error: inflate: data stream error (unknown compression method) > error: unable to unpack 7b513f98a66ef9488e516e7abbc246438597c6d5 header > error: inflate: data stream error (unknown

Re: [PATCH] format-patch: use raw format for notes

On Sun, Sep 10, 2017 at 9:27 PM, Sam Bobroff wrote: > (If only there were a way to set the coverletter text automatically as > well...) > Checkout branch..description

[PATCH 4/4] packed refs: pass .git dir instead of packed-refs path to init_fn

From: Stefan Beller The first argument of a ref_store_init_fn is documented to represent the $GIT_DIR, not the path to the packed-refs file. This brings the packed-refs store more in line with the usual ref store interface. Signed-off-by: Jonathan Nieder

[PATCH 3/4] replace-objects: evaluate replacement refs without using the object store

From: Stefan Beller Pass DO_FOR_EACH_INCLUDE_BROKEN when iterating over replacement refs so that the iteration does not require opening the named objects from the object store. This avoids a dependency cycle between object access and replace ref iteration. Moreover the ref

[PATCH 2/4] push, fetch: error out for submodule entries not pointing to commits

From: Stefan Beller The check_has_commit helper uses resolves a submodule entry to a commit, when validating its existence. As a side effect this means tolerates a submodule entry pointing to a tag, which is not a valid submodule entry that git commands would know how to cope

[PATCH 1/4] pack: make packed_git_mru global a value instead of a pointer

The MRU cache that keeps track of recently used packs is represented using two global variables: struct mru packed_git_mru_storage; struct mru *packed_git_mru = _git_mru_storage; Callers never assign to the packed_git_mru pointer, though, so we can simplify by eliminating it and

[PATCH 0/4] Fixes from the per-repository object store series

Hi, This is a continuation of the series at [1]. That was part 1 --- you can think of this as part 0, since it contains the simplest and least controversial part of the series --- each patch in this series is a bugfix in its own right. Patch 1 should be familiar if you reviewed the series [1].

Re: SHA1 collision in production repo?! (probably not)

> On 31 Mar 2017, at 19:45, Jeff King wrote: > > On Fri, Mar 31, 2017 at 10:35:06AM -0700, Junio C Hamano wrote: > >> Lars Schneider writes: >> >>> Hi, >>> >>> I just got a report with the following output after a "git fetch" operation >>> using Git

Re: Buffered value should be shown when requesting username for remote authentication

On Tue, Sep 12, 2017 at 06:17:29PM +0530, Kaartic Sivaraam wrote: > I noted a little issue with the interaction to a remote git repository. > The issue occurs when the network used for remote communication is a > bit sluggish. The main issue is illustrated by the following shell > interaction, >

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On Tue, Sep 12, 2017 at 07:11:38PM +0530, Kaartic Sivaraam wrote: > On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote: > > This patch introduces an UNLEAK() macro that lets us do so. > > To understand its design, let's first look at some of the > > alternatives. > > > > > This patch adds the

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On Tue, Sep 12, 2017 at 08:04:52PM +0530, Kaartic Sivaraam wrote: > > On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote: > > > > After having a sneak peak at the implementation > > it is O(1) in runtime for each added element, and the > > space complexity is O(well). > > > > Incidentally

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

> On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote: > > After having a sneak peak at the implementation > it is O(1) in runtime for each added element, and the > space complexity is O(well). > Incidentally I was reading about "complexity of algorithms" and there was the following

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote: > This patch introduces an UNLEAK() macro that lets us do so. > To understand its design, let's first look at some of the > alternatives. > > This patch adds the UNLEAK() macro and enables it > automatically when Git is compiled with

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

Hi Ramsay, On Sat, 9 Sep 2017, 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. > > This is a test introduced by Michael's

Buffered value should be shown when requesting username for remote authentication

Hello all, I noted a little issue with the interaction to a remote git repository. The issue occurs when the network used for remote communication is a bit sluggish. The main issue is illustrated by the following shell interaction, $ git push -u fork sivaraamUsername for '

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

> On 11 Sep 2017, at 05:27, 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

Re: [PATCH 00/12] Clean up notes-related code around `load_subtree()`

> On 10 Sep 2017, at 09:39, Jeff King wrote: > > On Sun, Sep 10, 2017 at 06:45:08AM +0200, Michael Haggerty wrote: > >>> So nothing to see here, but since I spent 20 minutes scratching my head >>> (and I know others look at Coverity output and may scratch their heads >>> too), I

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

> On 11 Sep 2017, at 16:52, SZEDER Gábor wrote: > >> 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? Agreed, maybe: "If we push a branch and a tag

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

Hi Junio, On Mon, 11 Sep 2017, Junio C Hamano wrote: > * js/rebase-i-final (2017-07-27) 10 commits > - rebase -i: rearrange fixup/squash lines using the rebase--helper > - t3415: test fixup with wrapped oneline > - rebase -i: skip unnecessary picks using the rebase--helper > - rebase -i:

[PATCH] help: change a message to be more precise

When the user tries to use '--help' option on an aliased command information about the alias is printed as sshown below, $ git co --help `git co' is aliased to `checkout' This doesn't seem correct as the user has aliased only 'co' and not 'git co'. This might even be incorrect in cases

[PATCH] commit-template: change a message to be more intuitive

It's not possible to 'touch' the cut-line that is shown when the user requests a patch in his commit template. So, make the sentence more intuitive. Signed-off-by: Kaartic Sivaraam --- Just a small tweak. May or may not be worth the patch. wt-status.c | 2 +-

[PATCH/RFC] branch: strictly don't allow a branch with name 'HEAD'

Allowing a branch with a name 'HEAD' could trigger ambiguity. We could avoid this by checking for it manually. Moreover this has been done partially in 8efb8899c ("branch: segfault fixes and validation", 2013-02-23) There was still a way to create a branch with name 'HEAD' by using $ git

hello..

>From The Regional Manager!, best regards!, How are you doing including your family, hope all is well? My purpose of contacting you is to crave your indulgence to assist me in securing some funds abroad. (US$7,500,000.00 ) I am writing you this proposal in good faith, believing that I can

Re: [PATCH 4/4] imap-send: use curl by default

Le 12/09/2017 à 09:02, Junio C Hamano a écrit : > Junio C Hamano writes: > >> I was sweeping my mailbox to collect loose ends that haven't been >> tied down, and noticed that this topic does not seem to have reached >> a conclusion. Do we want to reboot the effort? Or

Re: [PATCH 4/4] imap-send: use curl by default

Junio C Hamano writes: > I was sweeping my mailbox to collect loose ends that haven't been > tied down, and noticed that this topic does not seem to have reached > a conclusion. Do we want to reboot the effort? Or should we just > throw it in the #leftoverbits bin for now?

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

On Tue, 2017-09-12 at 15:49 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > Thanks. Now I get it. What about doing that check in > > branch.c::create_branch or branch.c::validate_new_branchname? I guess > > creating a branch named HEAD isn't that

Re: Suggestion: better error message when an ambiguous checkout is executed

Junio C Hamano writes: > Mahmoud Al-Qudsi writes: > >> The default git behavior when attempting to `git checkout xxx` for >> some value of "xxx" that cannot be resolved to a single, unique >> file/path/branch/tag/commit/etc is to display the following: >

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

Kaartic Sivaraam writes: > On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote: >> You said that "checkout" does not do a necessary check that is done >> in "branch", so presumably "branch" already has a code to do so that >> is not called by the current

Re: [PATCH 00/12] Clean up notes-related code around `load_subtree()`

On Sun, Sep 10, 2017 at 9:39 AM, Jeff King wrote: > On Sun, Sep 10, 2017 at 06:45:08AM +0200, Michael Haggerty wrote: > >> > So nothing to see here, but since I spent 20 minutes scratching my head >> > (and I know others look at Coverity output and may scratch their heads >> >

Re: [PATCH 4/4] imap-send: use curl by default

Jeff King writes: > On Mon, Aug 07, 2017 at 04:04:05PM +0200, Nicolas Morey-Chaisemartin wrote: > >> Signed-off-by: Nicolas Morey-Chaisemartin > > Thanks for moving forward with this. > > Can you please flesh out your commit messages with some of