Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

Matthieu Moy wrote: > Samuel GROOT writes: > > > Parsing and processing in send-email is done in the same loop. > > > > To make the code more maintainable, we create two subroutines: > > - `parse_email` to separate header and body > > - `parse_header` to retrieve data from header > > These rout

error: Can't cherry-pick into empty head

Hello everyone, I'm trying to understand why I'm getting the error as per subject. The scenario is the following: I'm on the master branch (which contains several commits) and I would like to create a new empty branch (let's call it new-orphan) and cherry-pick only the commits related to a specif

[PATCH] patch-id: use starts_with() and skip_prefix()

Get rid of magic numbers and avoid running over the end of a NUL terminated string by using starts_with() and skip_prefix() instead of memcmp(). Signed-off-by: Rene Scharfe --- builtin/patch-id.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/builti

[PATCH] apply: remove unused parameters from name_terminate()

Signed-off-by: Rene Scharfe --- builtin/apply.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index 8e4da2e..c770d7d 100644 --- a/builtin/apply.c +++ b/builtin/apply.c @@ -442,7 +442,7 @@ static int is_dev_null(const char *str) #define

Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

Samuel GROOT writes: > Parsing and processing in send-email is done in the same loop. > > To make the code more maintainable, we create two subroutines: > - `parse_email` to separate header and body > - `parse_header` to retrieve data from header These routines are not specific to git send-email

[PATCH v2 8/8] grep: -W: don't extend context to trailing empty lines

Empty lines between functions are shown by grep -W, as it considers them to be part of the function preceding them. They are not interesting in most languages. The previous patches stopped showing them for diff -W. Stop showing empty lines trailing a function with grep -W. Grep scans the lines

[PATCH v2 7/8] t7810: add test for grep -W and trailing empty context lines

Add a test demonstrating that git grep -W prints empty lines following the function context we're actually interested in. The modified test file makes it necessary to adjust three unrelated test cases. Signed-off-by: Rene Scharfe --- t/t7810-grep.sh | 19 --- 1 file changed, 16

[PATCH v2 6/8] xdiff: don't trim common tail with -W

The function trim_common_tail() exits early if context lines are requested. If -U0 and -W are specified together then it can still trim context lines that might belong to a changed function. As a result that function is shown incompletely. Fix that by calling trim_common_tail() only if no functi

Re: [WIP-PATCH 0/2] send-email: refactor the email parser loop

Eric Wong writes: > Samuel GROOT wrote: > >>(mbox) Adding cc: A from line 'Cc: >> A, One' >>(mbox) Adding cc: One from line 'Cc: >> A, One' >> >> Though `git send-email` now outputs something like: >> >>(mbox) Adding cc: A from line 'Cc: >> A' >>(mbox) Adding cc: One fro

[PATCH v2 5/8] xdiff: -W: don't include common trailing empty lines in context

Empty lines between functions are shown by diff -W, as it considers them to be part of the function preceding them. They are not interesting in most languages. The previous patch stopped showing them in the special case of a function added at the end of a file. Stop extending context to those em

[PATCH v2 4/8] xdiff: ignore empty lines before added functions with -W

If a new function and a preceding empty line is appended, diff -W shows the previous function in full in order to provide context for that empty line. In most languages empty lines between sections are not interesting in and off themselves and showing a whole extra function for them is not what we

Re: [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body

Tom Russello writes: > Currently, `send-email` without `--compose` implies `--annotate`. I don't get it. Did you mean s/without/with/? Even if so, this is not exactly true: "git send-email --compose -1" will open the editor only for the cover-letter, while adding --annotate will also open it for

[PATCH v2 3/8] xdiff: handle appended chunks better with -W

If lines are added at the end of a file, diff -W shows the whole file. That's because get_func_line() only considers the pre-image and gives up if it sees a record index beyond its end. Consider the post-image as well to see if the added lines already make up a full function. If it doesn't then s

[PATCH v2 2/8] xdiff: factor out match_func_rec()

Add match_func_rec(), a helper that wraps accessing a record and calling the appropriate function for checking if it contains a function line. Signed-off-by: Rene Scharfe --- xdiff/xemit.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/xdiff/xemit.c b/xdiff/

[PATCH v2 1/8] t4051: rewrite, add more tests

Remove the tests that checked diff -W output against a fixed expected result and replace them with more focused checks of desired properties of the created diffs. That way we get more detailed and meaningful diagnostics. Store test file contents in files in a subdirectory in order to avoid clutte

Re: [Bug?] log -p -W showing the whole file for a patch that adds to the end?

Am 21.05.2016 um 20:42 schrieb René Scharfe: > Am 11.05.2016 um 00:51 schrieb Junio C Hamano: >> The helper function get_func_line() however gets confused when a >> hunk adds a new function at the very end, and returns -1 to signal >> that it did not find a suitable "function header line", i.e. the

Re: [RFC-PATCH v2 1/2] send-email: quote-email populates the fields

Tom Russello writes: > --- a/Documentation/git-send-email.txt > +++ b/Documentation/git-send-email.txt > @@ -106,6 +106,11 @@ illustration below where `[PATCH v2 0/3]` is in reply to > `[PATCH 0/2]`: > Only necessary if --compose is also set. If --compose > is not set, this will be prompted f

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Johannes Schindelin writes: > Hi David, > > On Sat, 28 May 2016, David Kastrup wrote: > >> > The short version of your answer is that you will leave this patch in >> > its current form and address none of my concerns because you moved on, >> > correct? If so, that's totally okay, it just needs to

ssh key

Hi, Can i add SSH id_rsa.pub to GIT by shell terminal? Thank you! Mikhail. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

IT- Desk Password Update

Dear user Due to the congestion in all users accounts, Would be shutting down all unused accounts. click here to activate Your account Now. Sincerely, IT- Desk Service Desk -- To unsubscribe from this list: send the line "unsubscribe git" in

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Hi David, On Sat, 28 May 2016, David Kastrup wrote: > > The short version of your answer is that you will leave this patch in > > its current form and address none of my concerns because you moved on, > > correct? If so, that's totally okay, it just needs to be spelled out. > > Yes, that's it.

Re: RFC: new git-splice subcommand for non-interactive branch splicing

On Sat, May 28, 2016 at 09:06:59AM +0200, Johannes Schindelin wrote: > Hi Adam, > > please reply-to-all on this list. Sorry, I forgot that was the policy here. Every list and individual has different preferences on whether to Cc: on list mail, so I find it almost impossible to keep track of who

[PATCH v2] Require 0 context lines in git-blame algorithm

Previously, the core part of git blame -M required 1 context line. There is no rationale to be found in the code (one guess would be that the old blame algorithm was unable to deal with immediately adjacent regions), and it causes artifacts like discussed in the thread

Re: [PATCH v8 0/9] connect: various cleanups

On Sat, May 28, 2016 at 10:17:19AM +0200, Torsten Bögershausen wrote: > On 28.05.16 07:33, Mike Hommey wrote: > > On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote: > >> On 27.05.16 23:59, Mike Hommey wrote: > >>> On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wro

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Johannes Schindelin writes: > On Fri, 27 May 2016, David Kastrup wrote: > >> Johannes Schindelin writes: >> >> > On Fri, 27 May 2016, David Kastrup wrote: >> > >> >> pressure particularly when the history contains lots of merges from >> >> long-diverged branches. In practice, this optimization

Re: [PATCH v2 00/22] i18n and test updates

Às 17:11 de 27-05-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> Marks several messages for translation and updates tests to pass under >> GETTEXT_POISON. Some tests were updated to fit previous i18n marks, others >> were updated to fit marks made by these patches. Patches that only

Re: [PATCH v8 0/9] connect: various cleanups

On 28.05.16 07:33, Mike Hommey wrote: > On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote: >> On 27.05.16 23:59, Mike Hommey wrote: >>> On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: On 27.05.16 04:27, Mike Hommey wrote: > Changes from v7: > -

Re: RFC: new git-splice subcommand for non-interactive branch splicing

Hi Adam, please reply-to-all on this list. On Fri, 27 May 2016, Adam Spiers wrote: > My feeling is that rebase -i provides something tremendously > important, which the vast majority of users use on a regular basis, > but that git is currently missing a convenient way to > *non-interactively* pe