Re: Make patch-id more flexible?

Eugeniu Rosca writes: > file-names. Here comes my actual question. Would it be conceptually fine > to implement some `git patch-id` parameter, which would allow ignoring > the file-names (or reducing those to their `basename`) before computing > the patch id? Or would it

Re: [PATCH 1/1] diffcore: add a filter to find a specific blob

Stefan Beller writes: > Sometimes users are given a hash of an object and they want to > identify it further (ex.: Use verify-pack to find the largest blobs, > but what are these? or [1]) > > One might be tempted to extend git-describe to also work with blobs, > such that

Make patch-id more flexible?

Dear git Community, This is my first post to the git mailing list, so I would first like to express my gratitude to everyone involved in developing one of my favorite development tools. I will make my question short and concrete. My day to day job is doing Linux kernel integration, which also

Re: [PATCHv5 7/7] builtin/describe.c: describe a blob

Stefan Beller writes: > On Tue, Nov 21, 2017 at 11:55 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> ... >>> fixed. >>> ... >>> fixed the text... >>> ... >>> I am not fully convinced all descriptions are in recent history,

Re: [PATCH v4 4/4] worktree: make add dwim

Thomas Gummerer writes: > Currently 'git worktree add ' creates a new branch named after the > basename of the , that matches the HEAD of whichever worktree we > were on when calling "git worktree add ". > > Make 'git worktree add behave more like the dwim machinery in >

Re: [PATCH v4 3/4] worktree: make add dwim

Thomas Gummerer writes: > Currently 'git worktree add ', errors out when 'branch' > is not a local branch. It has no additional dwim'ing features that one > might expect. > > Make it behave more like 'git checkout ' when the branch doesn't > exist locally, but a remote

Re: [PATCH v4 2/4] worktree: add --[no-]track option to the add subcommand

Thomas Gummerer writes: > diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh > index b5c47ac602..53042ce565 100755 > --- a/t/t2025-worktree-add.sh > +++ b/t/t2025-worktree-add.sh > @@ -313,5 +313,60 @@ test_expect_success 'checkout a branch under bisect' ' >

Re: [PATCH v4 1/4] checkout: factor out functions to new lib file

Thomas Gummerer writes: > Factor the functions out, so they can be re-used from other places. In > particular these functions will be re-used in builtin/worktree.c to make > git worktree add dwim more. > > While there add some docs to the function. > > Signed-off-by:

Re: [PATCH v2] launch_editor(): indicate that Git waits for user input

Lars Schneider writes: >> Of course it is possible, if you really wanted to. The code knows >> if it gave the "we launched and waiting for you" notice, so it can >> maintain not just one (i.e. "how I close the notice?") but another >> one (i.e. "how I do so upon an

Re: Changing encoding of a file : What should happen to CRLF in file ?

Great work !!! Thanks On Fri, Nov 24, 2017 at 1:55 AM, Torsten Bögershausen wrote: > On Thu, Nov 23, 2017 at 10:01:40PM +0530, Ashish Negi wrote: >> Thanks for confirming. >> Is it possible to track this via a bug number ? >> It will help me to try out the fix when its available.

Re: [PATCH v3] doc: tweak "man gitcli" for clarity

Junio C Hamano writes: >> - * Without disambiguating `--`, Git makes a reasonable guess, but errors >> - out and asking you to disambiguate when ambiguous. E.g. if you have a >> - file called HEAD in your work tree, `git diff HEAD` is ambiguous, and >> + * In cases where

Re: [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

Max Kirillov writes: > http-backend reads whole input until EOF. However, the RFC 3875 specifies > that a script must read only as many bytes as specified by CONTENT_LENGTH > environment variable. This causes hang under IIS/Windows, for example. > > Make http-backend read only

$27M USD

Apologies! I am a military woman ,seeking your kind assistance. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Re: [PATCH v2 2/2] stash-store: add failing test for same-ref

Phil Hord writes: > stash-store cannot create a new stash with the same ref as stash@{0}. No > error is returned even though no new stash log is created. Add a failing > test to track. > > Signed-off-by: Phil Hord > --- Sorry, I lost track. Where is

Re: [PATCH v2] Teach stash to parse -m/--message like commit does

Phil Hord writes: > `git stash push -m foo` uses "foo" as the message for the stash. But > `git stash push -m"foo"` does not parse successfully. Similarly > `git stash push --message="My stash message"` also fails. The stash > documentation doesn't suggest this syntax

Re: Bisect marking new commits incorrectly

Jeff King writes: > Yeah, I really would have expected this to work, too. Should we be > taking the merge base of the set of "new" commits, and using that as the > true "new"? > ... > So maybe that's not workable. > > (I've never really dug into the bisect algorithm, and this is

Re: [PATCH v3 00/33] Add directory rename detection to git

On Thu, Nov 23, 2017 at 2:28 PM, Elijah Newren wrote: > On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote: >> On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: >>> >>> >>> merge-recursive.c | 1243 +++- >>>

Re: [PATCH v3] doc: tweak "man gitcli" for clarity

"Robert P. J. Day" writes: > -This manual describes the convention used throughout Git CLI. > +This manual describes the conventions used throughout Git CLI. OK. > Many commands take revisions (most often "commits", but sometimes > "tree-ish", depending on the context

Re: [PATCH v2] doc: clarify that "git bisect" accepts one or more good commits

"Robert P. J. Day" writes: > This command uses a binary search algorithm to find which commit in > -your project's history introduced a bug. You use it by first telling > -it a "bad" commit that is known to contain the bug, and a "good" > -commit that is known to be

Re*: Documentation of post-receive hook

Junio C Hamano writes: > Your suggesting to mention that particular message hints at me that > you feel that the users may not necessarily understand that push did > not result in any update of references on the other side when they > see it. If the message was clear enough

Re: [PATCH] grep: Add option --max-line-len

Marc-Antoine Ruel writes: > This tells git grep to skip files longer than a specified length, > which is often the result of generators and not actual source files. > > ... > +-M:: > +--max-line-len:: > + Match the pattern only for line shorter or equal to this length. >

Re: [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Thu, Nov 23, 2017 at 6:45 PM, Max Kirillov wrote: > [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875 The "RFC" seems to be missing from the subject line of this unpolished patch. > http-backend reads whole input until EOF. However, the RFC 3875 specifies

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

Kevin Daudt writes: > Just for completeness, as it is somewhat covered by point 1 already, but > there are cases where there is no real ambiguity but you are required to > add '--' to tell git that it should not look for the file in the working > tree: > > $ git show abc123

Re: [PATCH v3 5/5] Testing: provide tests requiring them with ellipses after SHA-1 values

"Philip Oakley" writes: >> We do not know until this change is released to the wild, at which >> time we will hear noises about the lack of expected ellipses their >> (poorly written) scripts rely on and tell them to set the workaround >> environment variable. We may not

Re: Problem installing Git (followup)

Hi Phil, On 24/11/2017 00:44, Phil Martel wrote: > On 11/23/2017 4:30 PM, Igor Djordjevic wrote: >> On 23/11/2017 19:51, Phil Martel wrote: >>> I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 >>> machine. When I run this installer program no matter what >>> options I try or

[PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

http-backend reads whole input until EOF. However, the RFC 3875 specifies that a script must read only as many bytes as specified by CONTENT_LENGTH environment variable. This causes hang under IIS/Windows, for example. Make http-backend read only CONTENT_LENGTH bytes, if it's defined, rather than

Re: Problem installing Git (followup)

Hi Buga, That solved my problem.  I apparently had enough cruft left over from a hard disk issue for Windows to think I still had a copy of Git installed.  when I got rid of it, the new version installed with no problems. Thanks again, --Phil Martel On 11/23/2017 4:30 PM, Igor Djordjevic

Re: Problem installing Git

Thank you.  I'll look into it. Best wishes, --Phil Martel On 11/23/2017 4:30 PM, Igor Djordjevic wrote: [ +Cc: Git for Windows mailing list ] Hi Phil, On 23/11/2017 19:51, Phil Martel wrote: I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 machine. When I run this

Re: [PATCH v3 00/33] Add directory rename detection to git

On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote: > On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: >> >> >> merge-recursive.c | 1243 +++- >> merge-recursive.h | 17 + >> t/t3501-revert-cherry-pick.sh

Re: Delivery Status Notification (Failure)

On 23/11/2017 22:30, Mail Delivery Subsystem wrote: > Hello igor.d.djordje...@gmail.com, > > We're writing to let you know that the group you tried to contact > (git-for-windows) may not exist, or you may not have permission to post > messages to the group. A few more details on why you weren't

Re: Problem installing Git

[ +Cc: Git for Windows mailing list ] Hi Phil, On 23/11/2017 19:51, Phil Martel wrote: > I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 > machine. When I run this installer program no matter what options I > try or whether I run as administrator it ends up with an error box

Re: Unify annotated and non-annotated tags

Am 23.11.2017 um 16:08 schrieb Randall S. Becker: [...] >> So my proposal is to get rid of non-annotated tags, so to get all >> tags with commits that they point to, one would use: >> git for-each-ref --format='%(*objectname) %(refname)' refs/tags> >> For so-called non-annotated tags just leave

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Thu, Nov 23, 2017 at 08:51:55AM -0500, Jeff King wrote: > On Thu, Nov 23, 2017 at 02:45:44AM -0500, Robert P. J. Day wrote: > > > > It's pretty clear to me as it is, but maybe we can write it differently. > > > Like: > > > > > > Without a disambiguating `--`, Git makes a reasonable guess. If

Re: Changing encoding of a file : What should happen to CRLF in file ?

On Thu, Nov 23, 2017 at 10:01:40PM +0530, Ashish Negi wrote: > Thanks for confirming. > Is it possible to track this via a bug number ? > It will help me to try out the fix when its available. > No worry, the fix is nearly complete and will come out in a couple of days.

Re: RFC: Native clean/smudge filter for UTF-16 files

On Thu, Nov 23, 2017 at 04:18:59PM +0100, Lars Schneider wrote: > Hi, > > I am working with a team that owns a repository with lots of UTF-16 files. > Converting these files to UTF-8 is no good option as downstream applications > require the UTF-16 encoding. Keeping the files in UTF-16 is no good

Re: [PATCH] grep: Add option --max-line-len

On Thu, Nov 23, 2017 at 10:41 AM, Marc-Antoine Ruel wrote: > This tells git grep to skip files longer than a specified length, s/files/lines/ > which is often the result of generators and not actual source files. > > Signed-off-by: Marc-Antoine Ruel >

Problem installing Git

Hi, I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 machine.  When I run this installer program no matter what options I try or whether I run as administrator it ends up with an error box saying "The drive or UNC share you selected does not exist or is not accessible. Please

I wait for your prompt response.

Good day, I am Mr. Sam Azada from Burkina Faso a Minister confide on me to look for foreign partner who will assist him to invest the sum of Fifty Million Dollars ($50,000,000) in your country. He has investment interest in mining, exotic properties for commercial resident, development

Re: Changing encoding of a file : What should happen to CRLF in file ?

Thanks for confirming. Is it possible to track this via a bug number ? It will help me to try out the fix when its available. On Thu, Nov 16, 2017 at 9:45 PM, Torsten Bögershausen wrote: > On Thu, Nov 16, 2017 at 12:35:33AM +0530, Ashish Negi wrote: >> On windows : >> > git

[PATCH] grep: Add option --max-line-len

This tells git grep to skip files longer than a specified length, which is often the result of generators and not actual source files. Signed-off-by: Marc-Antoine Ruel --- Documentation/git-grep.txt | 5 + builtin/grep.c | 2 ++ grep.c |

RFC: Native clean/smudge filter for UTF-16 files

Hi, I am working with a team that owns a repository with lots of UTF-16 files. Converting these files to UTF-8 is no good option as downstream applications require the UTF-16 encoding. Keeping the files in UTF-16 is no good option either as Git and Git related tools (e.g. GitHub) consider the

RE: Re: Unify annotated and non-annotated tags

On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote >Subject: Re: Unify annotated and non-annotated tags >On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote: >> Igor Djordjevic writes: >> >>> If you would like to mimic output of "git

[PATCH v2 1/2] test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites

Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, respectively. The syntax of PCRE1 and PCRE2 isn't the same in all cases (see pcresyntax(3) and pcre2syntax(3)). If test are added that test for those they'll need to

[PATCH v2 2/2] grep: fix segfault under -P + PCRE2 <=10.30 + (*NO_JIT)

Fix a bug in the compilation of PCRE2 patterns under JIT (the most common runtime configuration). Any pattern with a (*NO_JIT) verb would segfault in any currently released PCRE2 version: $ git grep -P '(*NO_JIT)hi.*there' Segmentation fault That this segfaulted was a bug in PCRE2

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Thu, Nov 23, 2017 at 02:45:44AM -0500, Robert P. J. Day wrote: > > It's pretty clear to me as it is, but maybe we can write it differently. > > Like: > > > > Without a disambiguating `--`, Git makes a reasonable guess. If it > > cannot guess (because your request is ambiguous), then it

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: > > > merge-recursive.c | 1243 +++- > merge-recursive.h | 17 + > t/t3501-revert-cherry-pick.sh |5 +- > t/t6043-merge-rename-directories.sh | 3821 >

[no subject]

Welcome to HEARTLAND LOAN FIRM, we give out loans from the range of € 9,000 to € 900,000,000 at 2% interest rate. Kindly apply by providing the details below - Your name .. Your country ... Amount of loan needed . Phone number ... REGARDS CHARLENE TAYLOR HEARTLAND LOAN FIRM

From Precious

Hi dear, My name is Precious, I saw your profile and i became interested in you, I will also like to know you more, please contact me with this e-mail address so I can give you my picture for you to know whom I am, because I have something very important to tell you. Precious.

Re: [PATCH 2/2] grep: fix segfault under -P + PCRE2 + (*NO_JIT)

On Wed, Nov 22 2017, Eric Sunshine jotted: > On Wed, Nov 22, 2017 at 8:36 AM, Ævar Arnfjörð Bjarmason > wrote: >> Fix a bug in the compilation of PCRE2 patterns under JIT (the most >> common runtime configuration), any pattern with a (*NO_JIT) verb would >> segfault. This bug

Re: [PATCH 1/2] test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites

On Wed, Nov 22 2017, Jonathan Nieder jotted: > Hi, > > Ævar Arnfjörð Bjarmason wrote: > >> Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is >> compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, >> respectively. >> >> The syntax of PCRE1 and PCRE2 isn't the same in

Re: [PATCH 2/2] grep: fix segfault under -P + PCRE2 + (*NO_JIT)

On Wed, Nov 22, 2017 at 01:36:30PM +, Ævar Arnfjörð Bjarmason wrote: > + * > + * This is because if the pattern contains the > + * (*NO_JIT) verb (see pcre2syntax(3)) > + * pcre2_jit_compile() will exit early with 0. If we > + *