[PATCH v4 8/9] sequencer: try to commit without forking 'git commit'

From: Phillip Wood If the commit message does not need to be edited then create the commit without forking 'git commit'. Taking the best time of ten runs with a warm cache this reduces the time taken to cherry-pick 10 commits by 27% (from 282ms to 204ms), and the time

[PATCH v4 7/9] sequencer: load commit related config

From: Phillip Wood Load default values for message cleanup and gpg signing of commits in preparation for committing without forking 'git commit'. Note that we interpret commit.cleanup=scissors to mean COMMIT_MSG_CLEANUP_SPACE to be consistent with 'git commit'

[PATCH v4 9/9] t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1

From: Phillip Wood Now that the sequencer creates commits without forking 'git commit' it does not see an empty commit in these tests which fixes the known breakage. Note that logic for handling KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1 is not removed from

[PATCH v4 3/9] Add a function to update HEAD after creating a commit

From: Phillip Wood Add update_head_with_reflog() based on the code that updates HEAD after committing in builtin/commit.c that can be called by 'git commit' and other commands. Signed-off-by: Phillip Wood --- Notes: changes since v2:

[PATCH v4 5/9] commit: move print_commit_summary() to libgit

From: Phillip Wood Move print_commit_summary() from builtin/commit.c to sequencer.c so it can be shared with other commands. The function is modified by changing the last argument to a flag so callers can specify whether they want to show the author date in addition

Re: [PATCH v2 1/9] perf/run: add '--config' option to the 'run' script

On Mon, Oct 16 2017, Junio C. Hamano jotted: > Christian Couder writes: > >> It is error prone and tiring to use many long environment >> variables to give parameters to the 'run' script. > > This topic has been sitting in the list archive without getting much >

[PATCH v4 6/9] sequencer: simplify adding Signed-off-by: trailer

From: Phillip Wood Add the Signed-off-by: trailer in one place rather than adding it to the message when doing a recursive merge and specifying '--signoff' when running 'git commit'. This means that if there are conflicts when merging with a strategy other than

[PATCH v4 4/9] commit: move post-rewrite code to libgit

From: Phillip Wood Move run_rewrite_hook() from bulitin/commit.c to sequencer.c so it can be shared with other commands and add a new function commit_post_rewrite() based on the code in builtin/commit.c that encapsulates rewriting notes and running the post-rewrite

[PATCH v4 2/9] commit: move empty message checks to libgit

From: Phillip Wood Move the functions that check for empty messages from bulitin/commit.c to sequencer.c so they can be shared with other commands. The functions are refactored to take an explicit cleanup mode and template filename passed by the caller.

[PATCH v4 1/9] t3404: check intermediate squash messages

From: Phillip Wood When there is more than one squash/fixup command in a row check the intermediate messages are correct. Signed-off-by: Phillip Wood --- t/t3404-rebase-interactive.sh | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v4 0/9] sequencer: don't fork git commit

From: Phillip Wood I've updated the patches to fix the embarassing build failure in v3. I've also added a patch to remove the known breakage from some of the tests in t3512/t3513 that now pass - someone who knows about submodules should check this. The only other

Re: Re: Unify annotated and non-annotated tags

On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik wrote: > On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker > wrote: >> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote >>>Subject: Re: Unify annotated and non-annotated tags >>>On Sat, Nov

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

On Fri, 24 Nov 2017, Junio C Hamano wrote: > "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

Re: Re: Unify annotated and non-annotated tags

On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker wrote: > 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

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

Hi All, thx Max for jumping in, I wasn't able to complete this due to serious lack of time. Later I forgot it. Great to see that this finally made it. Mit freundlichen Grüßen / With kind regards Florian Manschwetus E-Mail: manschwe...@cs-software-gmbh.de Tel.: +49-(0)611-8908534   CS Software

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

On Fri, 24 Nov 2017, Junio C Hamano wrote: > "Robert P. J. Day" writes: ... snip ... > > -to indicate that it was after. > > +to indicate a single commit after that change. > > As to "identify", I would say it is better to consistently use > "indicate" like the original

Urgent Message

Dear Western Union Customer, You have been awarded with the sum of $250,000 USD by our office, as one of our customers who use Western Union in their daily business transaction. This award was been selected through the internet, where your e-mail address was indicated and notified. Please

What's cooking in git.git (Nov 2017, #07; Fri, 24)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Quite a few "fixes" have been

Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals

On Fri, Nov 24, 2017 at 2:59 PM, Elijah Newren wrote: > In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug, > 2014-05-01), it was observed that removing files could be problematic on > case insensitive file systems, because we could end up removing files > that

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

On Thu, Nov 23, 2017 at 9:25 PM, Elijah Newren wrote: > 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:

Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals

On Fri, Nov 24, 2017 at 12:04 PM, Eric Sunshine wrote: > On Fri, Nov 24, 2017 at 2:59 PM, Elijah Newren wrote: >> In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug, >> 2014-05-01), it was observed that removing files could be

Re: [PATCH 1/1] convert: tighten the safe autocrlf handling

On Fri, Nov 24, 2017 at 11:14 AM, wrote: > When a text file had been commited with CRLF and the file is commited > again, the CRLF are kept if .gitattributs has "text=auto". > This is done by analyzing the content of the blob stored in the index: > If a '\r' is found, Git assumes

[PATCH] checkout: include the checkout.h header file

Signed-off-by: Ramsay Jones --- Hi Thomas, If you need to re-roll your 'tg/worktree-create-tracking' branch, could you please squash this into the relevant patch (commit 6736ae9593, "checkout: factor out functions to new lib file", 2017-11-22). [noticed by sparse]

[PATCH] merge-recursive: ignore_case shouldn't reject intentional removals

In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug, 2014-05-01), it was observed that removing files could be problematic on case insensitive file systems, because we could end up removing files that differed in case only rather than deleting the intended file -- something that

HELLO

-- Dear Friend, I am MR. WILFRED KABORE, THE MANAGER, BILL AND EXCHANGE DEPT., BANK OF AFRICA - Burkina Faso. I know this message will come to you as a surprise. Don't worry I was totally convinced to write you, I hope that you will not expose or betray this trust and confident that i am about

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

"Robert P. J. Day" writes: > in this sense, i don't think "indicate" and "identify" are > completely interchangeable. in my mind, the word "identify" does > nothing more than, you know, point at something and say, "that one, > that's the one i'm talking about;" it goes

RE: offering

I have been trying to reach you contact me--(jonathansymonds...@hotmail.com) for more details

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

Junio C Hamano writes: > "Robert P. J. Day" writes: > >> in this sense, i don't think "indicate" and "identify" are >> completely interchangeable. in my mind, the word "identify" does >> nothing more than, you know, point at something and say, "that

Re: [PATCH v4 7/9] sequencer: load commit related config

Phillip Wood writes: > From: Phillip Wood > > Load default values for message cleanup and gpg signing of commits in > preparation for committing without forking 'git commit'. Note that we > interpret commit.cleanup=scissors to mean

RE: Re: Unify annotated and non-annotated tags

On November 24, 2017 4:52 AM anatoly techtonik wrote: >On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker >wrote: >> 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

Re: [PATCH v4 7/9] sequencer: load commit related config

On 24/11/17 13:48, Junio C Hamano wrote: > Phillip Wood writes: > >> From: Phillip Wood >> >> Load default values for message cleanup and gpg signing of commits in >> preparation for committing without forking 'git commit'. Note that we >>

[PATCH 1/1] convert: tighten the safe autocrlf handling

From: Torsten Bögershausen When a text file had been commited with CRLF and the file is commited again, the CRLF are kept if .gitattributs has "text=auto". This is done by analyzing the content of the blob stored in the index: If a '\r' is found, Git assumes that the blob was

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

Jeff King writes: > There is an open question of how carefully we want to document it, but I > think the strategy so far has been: > > - if you want to be careful, use "--" > > - if you don't, git will use black magic to guess, but that magic is >subject to change, so don't

Re: [PATCH 1/1] convert: tighten the safe autocrlf handling

tbo...@web.de writes: > From: Torsten Bögershausen > > When a text file had been commited with CRLF and the file is commited > again, the CRLF are kept if .gitattributs has "text=auto". > This is done by analyzing the content of the blob stored in the index: > If a '\r' is found,

Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals

Elijah Newren writes: > But what it really is forced to do is more of a 4-way merge; a good > chunk of its annoying complexity is based around this (undocumented > and unfortunate) reality. It derives from what I consider a simple > design flaw. Yes, and it

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

Jeff King writes: > So anyway, that is an alternate strategy, but I think I like "canonical > in-repo text is utf-8" approach a lot more, since then git operations > work consistently. There are still a few rough edges (e.g., I'm not sure Sounds like a good way forward. > if you

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

Jeff King writes: > So I dunno. That is far from exhaustive, but it does seem like most > cases should assume the presence of the file. You are right. I should have considered that "we got a random object-name looking thing and we do not care if it does not exist" is a very

RE

Hello Dear I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for

Re: [PATCH] bash completion: Add --autostash and --no-autostash to pull

> Ideally we should only autocomplete if pull has --rebase since > they only work with it but could not figure out how to do that > and the error message of doing git pull --autostash points out > that you need --rebase so i guess it's good enough You could use the completion script's

Re: [PATCH 1/1] convert: tighten the safe autocrlf handling

On Fri, Nov 24, 2017 at 12:24:48PM -0500, Eric Sunshine wrote: > On Fri, Nov 24, 2017 at 11:14 AM, wrote: > > When a text file had been commited with CRLF and the file is commited > > again, the CRLF are kept if .gitattributs has "text=auto". > > This is done by analyzing the

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

On Thu, Nov 23, 2017 at 09:55:03PM +0100, Kevin Daudt wrote: > > > > Without a disambiguating `--`, Git makes a reasonable guess. If it > > > > cannot guess (because your request is ambiguous), then it will error > > > > out. > [...] > > > 1) even without the "--", git can generally parse

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

On Thu, Nov 23, 2017 at 11:35:21AM +0900, Junio C Hamano wrote: > Not limiting us to the caller in the "fetch" codepath, I think the > expectation by callers of lookup_commit_reference_gently() in the > ideal world would be: > > - It has an object name, and wants to use it as point in the

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

On Thu, Nov 23, 2017 at 04:18:59PM +0100, Lars Schneider wrote: > Alternatively, I could add a native attribute to Git that translates UTF-16 > to UTF-8 and back. A conversion function is already available in "mingw.h" [3] > on Windows. Limiting this feature to Windows wouldn't be a problem from

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

On Fri, Nov 24, 2017 at 10:01:41AM +0900, Junio C Hamano wrote: > Actually the second example is a lot worse (and that is why I am > bringing it up). If git does spend cycles to realize that "git > could", for consistency, it must also check if "next" is unambiguous > between a path or a rev,

[PATCH] Fixed Russian translation

--- po/ru.po | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/po/ru.po b/po/ru.po index d4370b5941a13..4ce3d38047303 100644 --- a/po/ru.po +++ b/po/ru.po @@ -1,7 +1,7 @@ # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is

Re: [PATCH v4 1/6] diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value

Ann T Ropea writes: > Neither Git nor the user are in need of this (visual) aid anymore, but > we must offer a transition period. > > Also, fix a typo: "abbbreviated" ---> "abbreviated". > > Signed-off-by: Ann T Ropea > --- > v2: rename patch series & focus

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

Junio C Hamano writes: > If that is the case, shouldn't we make this new mode imply > --full-history to forbid history simplification? "git log" is a > tool to find _an_ explanation of the current state, and the usual > history simplification makes tons of sense there, but