Re: [PATCH v3 2/6] t9001: check email address is in Cc: field

Tom Russello writes: > Check if the given utf-8 email address is in the Cc: field. I wouldn't harm to explain what was the problem with existing code here. If I understand correctly, that would be: Existing code just checked that the address appeared in a line

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

Junio C Hamano writes: > Tom Russello writes: > >> +# Check if two files have the same content, non-order sensitive >> +test_cmp_noorder () { >> +sort $1 >$1; > > Here is what I think happens: > > 0) the shell parses this command line; >

Re: [PATCH 5/5] attr.c: always pass check[] to collect_some_attrs()

On Wed, Jun 8, 2016 at 3:58 PM, Junio C Hamano wrote: > This function used to be called with check=NULL to signal it to > collect all attributes in the global check_all_attr[] array. > > Because the longer term plan is to allocate check_all_attr[] and > attr_stack data

Re: [PATCH v4 4/6] send-email: create email parser subroutine

Samuel GROOT wrote: > Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1]. > Should we handle \n\r at end of line as well? "\n\r" can never happen with local $/ = "\n" > [1] * >

Re: [PATCH 1/5] attr.c: add push_stack() helper

Stefan Beller writes: All of your questions is about !origin vs !*origin. This applies to the code in 'master', not specific to jc/attr topic's improvements. It is how the prepare_attr_stack() tells where the .gitattributes for the top-level directory is when popping the

Re: [PATCH 3/5] fixup! d5ad6c13

Stefan Beller writes: > On Wed, Jun 8, 2016 at 3:58 PM, Junio C Hamano wrote: >> As the topic is in 'next' already, I'll leave this floating near the >> tip for now, until we can rewind the topic after the next release. > > I don't quite understand the

Re: `git help svn` missing description of `propset`

Eric, Would love to contribute more to git! I'm in the middle of a major product launch, so I can do this next week. Of course no hard feelings will be had if someone else wants to do it. I'm making myself a calendar invite to remind myself right now. I'll ping y'all in a week hopefully

Re: [PATCH 3/5] fixup! d5ad6c13

On Wed, Jun 8, 2016 at 3:58 PM, Junio C Hamano wrote: > As the topic is in 'next' already, I'll leave this floating near the > tip for now, until we can rewind the topic after the next release. I don't quite understand the motivation behind this commit. We return the last

Re: [PATCH 2/5] attr.c: pass struct git_attr_check down the callchain

On Wed, Jun 8, 2016 at 3:58 PM, Junio C Hamano wrote: > The callchain that starts from git_check_attrs() down to > collect_some_attrs() used to take an array of git_attr_check_elem > as their parameters. Pass the enclosing git_attr_check instance > instead, so that they will

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 10:17 PM, Junio C Hamano wrote: Eric Sunshine writes: An embedded CR probably shouldn't happen, but I'm not convinced that folding it out is a good idea. I would think that you'd want to preserve the header's value verbatim. If anything, I'd expect to

Re: [PATCH 1/5] attr.c: add push_stack() helper

On Wed, Jun 8, 2016 at 3:58 PM, Junio C Hamano wrote: > +static void push_stack(struct attr_stack **attr_stack_p, > + struct attr_stack *elem, char *origin, size_t > originlen) > +{ > + if (elem) { > + elem->origin = origin; > +

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

Jeff King writes: > I agree it can be confusing (especially on the output side your errors > are likely deferred until the next flush). But in this particular case, > I think it's an improvement (see the patch I just sent and its > discussion of error handling). Yes, for this

[PATCH 3/5] fixup! d5ad6c13

As the topic is in 'next' already, I'll leave this floating near the tip for now, until we can rewind the topic after the next release. --- attr.c | 9 ++--- attr.h | 2 +- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/attr.c b/attr.c index 4e2172a..0e61950 100644 ---

[PATCH 1/5] attr.c: add push_stack() helper

There are too many repetitious "I have this new attr_stack element; push it at the top of the stack" sequence. The new helper function push_stack() gives us a way to express what is going on at these places, and as a side effect, halves the number of times we mention the attr_stack global

[PATCH 2/5] attr.c: pass struct git_attr_check down the callchain

The callchain that starts from git_check_attrs() down to collect_some_attrs() used to take an array of git_attr_check_elem as their parameters. Pass the enclosing git_attr_check instance instead, so that they will have access to new fields we will add to the data structure. Signed-off-by: Junio

[PATCH 4/5] attr.c: correct ugly hack for git_all_attrs()

The collect_some_attrs() function has an ugly hack since 06a604e6 (attr: avoid heavy work when we know the specified attr is not defined, 2014-12-28) added an optimization that relies on the fact that the caller knows what attributes it is interested in, so that we can leave once we know the

[PATCH 0/5] A bit more "attributes"

The whole jc/attr topic is now depended on Stefan's "pathspec label" topic, both of which are in 'next' and cannot be rewound until the next cycle. These five patches are to continue my recent "attributes" work while the tree is in frozen state. A few central data structures, namely "attr_stack"

[PATCH 5/5] attr.c: always pass check[] to collect_some_attrs()

This function used to be called with check=NULL to signal it to collect all attributes in the global check_all_attr[] array. Because the longer term plan is to allocate check_all_attr[] and attr_stack data structures per git_attr_check instance (i.e. "check" here) to make the attr subsystem

Re: [PATCH v4 4/6] send-email: create email parser subroutine

Samuel GROOT wrote: > +++ b/perl/Git.pm > +sub parse_email { > + my %mail = (); > + my $fh = shift; > + my $last_header; > + > + # Unfold and parse multiline header fields When you libify, I suggest you localize $/ since $/ may be set to something

Re: [PATCH v4 4/6] send-email: create email parser subroutine

Eric Sunshine writes: > An embedded CR probably shouldn't happen, but I'm not convinced that > folding it out is a good idea. I would think that you'd want to > preserve the header's value verbatim. If anything, I'd expect to see > the regex tightened to: > >

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On Wed, Jun 8, 2016 at 3:30 PM, Samuel GROOT wrote: > On 06/08/2016 08:12 PM, Eric Sunshine wrote: >> On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote: >>> Samuel GROOT writes: >>> The pattern is not anchored

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

On Wed, Jun 08, 2016 at 12:48:36PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > That made me wonder if we could repeatedly reuse a buffer attached to > > the file descriptor. And indeed, isn't that what stdio is? The whole > > reason this buffer exists is because we are

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

Jeff King writes: > That made me wonder if we could repeatedly reuse a buffer attached to > the file descriptor. And indeed, isn't that what stdio is? The whole > reason this buffer exists is because we are using a direct descriptor > write. If we switched this function to use

[PATCH] send-pack: use buffered I/O to talk to pack-objects

On Wed, Jun 08, 2016 at 03:19:18PM -0400, Jeff King wrote: > That made me wonder if we could repeatedly reuse a buffer attached to > the file descriptor. And indeed, isn't that what stdio is? The whole > reason this buffer exists is because we are using a direct descriptor > write. If we switched

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 09:31 PM, Junio C Hamano wrote: Samuel GROOT writes: I think it's the best way to do it indeed. Furthermore, we did trim CRs and LFs in header fields, but not in the message, making the subroutine inconsistent. Should we rename the subroutine to

Re: [PATCH v4 3/6] send-email: shorten send-email's output

On 06/08/2016 09:33 PM, Junio C Hamano wrote: Samuel GROOT writes: On 06/08/2016 07:37 PM, Junio C Hamano wrote: Samuel GROOT writes: + printf("Adding cc: %s from From: header\n", +

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 07:58 PM, Junio C Hamano wrote: Samuel GROOT writes: +sub parse_email { + my %mail = (); + my $fh = shift; + my $last_header; + # Unfold and parse multiline header fields + while (<$fh>) { + last if

Re: [PATCH v4 3/6] send-email: shorten send-email's output

Samuel GROOT writes: > On 06/08/2016 07:37 PM, Junio C Hamano wrote: >> Samuel GROOT writes: >>> + printf("Adding cc: %s from From: header\n", >>> + $1) unless $quiet; >>

Re: [PATCH v4 4/6] send-email: create email parser subroutine

Samuel GROOT writes: > I think it's the best way to do it indeed. Furthermore, we did trim > CRs and LFs in header fields, but not in the message, making the > subroutine inconsistent. > > Should we rename the subroutine to `parse_header` or leave it as it is? If

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 08:12 PM, Eric Sunshine wrote: On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote: Samuel GROOT writes: +sub parse_email { + my %mail = (); + my $fh = shift; + my $last_header; + # Unfold and parse multiline

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

On 06/08/2016 06:56 PM, Junio C Hamano wrote: > The earliest address pa...@example.com and later addresses have > quite different meaning (the first one is meant to be the envelope > sender address, and does not name a recipient). While I think it is > a good idea to tell the test that the order

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 08:32 PM, Junio C Hamano wrote: Eric Sunshine writes: + # Separate body from header + $mail{"body"} = [(<$fh>)]; + + return \%mail; The name of the local thing is not observable from the caller, but because this is "parse-email-header" and

Re: [PATCH v4 2/6] t9001: check email address is in Cc: field

On 06/08/2016 07:34 PM, Junio C Hamano wrote: Samuel GROOT writes: diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index 56ad8ce..943e6b7 100755 --- a/t/t9001-send-email.sh +++ b/t/t9001-send-email.sh @@ -888,8 +888,8 @@ test_expect_success $PREREQ

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

On 06/08/2016 07:17 PM, Junio C Hamano wrote: Here is an illustration of an organization that I think would be easier to read, and would result in a more readable patch when modification is made on top. The first two hunks collapse the overall "setup" steps that appear as three separate tests

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

On Wed, Jun 08, 2016 at 06:20:41PM +0200, Michael Haggerty wrote: > Instead, one could write > > > static int feed_object(const unsigned char *sha1, int fd, int negative) > > { > > char buf[GIT_SHA1_HEXSZ + 2]; > > struct strbuf line = WRAPPED_FIXED_STRBUF(buf); > > > > if (negative

Re: [PATCH v4 3/6] send-email: shorten send-email's output

On 06/08/2016 07:37 PM, Junio C Hamano wrote: Samuel GROOT writes: + printf("Adding cc: %s from From: header\n", + $1) unless $quiet; + printf("Adding to:

Re: [PATCH v2 4/4] bundle v3: the beginning

On Wed, Jun 08, 2016 at 11:05:20AM -0700, Junio C Hamano wrote: > > Likewise, I'm not sure if "get" should be allowed to return contents > > that don't match the sha1. > > Yes, this is what I was getting at. It would be ideal to come up > with a way to do the large-blob offload without

Re: [PATCH] refs: mark the file-local vtable symbols as static

Ramsay Jones writes: > Signed-off-by: Ramsay Jones > --- > > Hi Michael, Junio, > > I would normally ask you to squash this into the relevant patch when > you next re-roll your 'mh/ref-iterators' branch, but this has already > been

Re: [RFC/PATCH] verify-tag: add --check-name flag

Santiago Torres writes: > Sorry I'm trying to follow this. Would it be best to then have > > verify-tag [--check-name=tagname] (tag-ref|tag-name|sha1)? > > and > > tag -v [--check-name] (tag-name) > > Or would --format still work better? No matter what you do, don't

Re: [PATCH v4 4/6] send-email: create email parser subroutine

Eric Sunshine writes: >>> + # Separate body from header >>> + $mail{"body"} = [(<$fh>)]; >>> + >>> + return \%mail; >> >> The name of the local thing is not observable from the caller, but >> because this is "parse-email-header" and returns "header fields" >>

Re: feature request: git svn dommit --preserve-timestamps

On Mon, Jun 06 2016, Peter Münster wrote: > It would be nice, if timestamps could be preserved when rewriting the > git-log. > > Use case: I often make a dcommit after several days of development > (20 or 30 commits), because > - the users of the svn-server don't need it more often; > - and for

Re: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields

Samuel GROOT writes: > +if ($initial_reply_to && -f $initial_reply_to) { > + my $error = validate_patch($initial_reply_to); This call is wrong, isn't it? You are not going to send out the message you are responding to (the message may not even be a patch),

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote: > Samuel GROOT writes: >> +sub parse_email { >> + my %mail = (); >> + my $fh = shift; >> + my $last_header; > >> + # Unfold and parse multiline header fields >> + while

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

Michael Haggerty writes: > * It's a little less manual bookkeeping, and thus less error-prone, > than the current code. > > * If somebody decides to add another character to the line but > forgets to increase the allocation size, the code dies in testing > rather than

Re: [PATCH 1/4] bisect--helper: `bisect_clean_state` shell function in C

Hey Eric, On Wed, Jun 8, 2016 at 11:29 PM, Eric Sunshine wrote: > On Wed, Jun 8, 2016 at 5:41 AM, Christian Couder > wrote: >> On Wed, Jun 8, 2016 at 10:02 AM, Eric Sunshine >> wrote: >>> On Wed, Jun 8, 2016 at 3:46

Re: [PATCH v2 4/4] bundle v3: the beginning

Jeff King writes: > This interface comes from my earlier patches, so I'll try to shed a > little light on the decisions I made there. > > Because this "external odb" essentially acts as a git alternate, we > would hit it only when we couldn't find an object through regular means.

Re: [PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

Hey Eric, On Wed, Jun 8, 2016 at 11:23 PM, Eric Sunshine wrote: > On Wed, Jun 8, 2016 at 9:20 AM, Pranit Bauva wrote: >> On Wed, Jun 8, 2016 at 1:29 PM, Eric Sunshine >> wrote: >>> On Tue, Jun 7, 2016 at 4:54 PM, Pranit

Re: [PATCH 1/4] bisect--helper: `bisect_clean_state` shell function in C

On Wed, Jun 8, 2016 at 5:41 AM, Christian Couder wrote: > On Wed, Jun 8, 2016 at 10:02 AM, Eric Sunshine > wrote: >> On Wed, Jun 8, 2016 at 3:46 AM, Pranit Bauva wrote: >>> On Wed, Jun 8, 2016 at 4:01 AM, Eric

Re: [PATCH v4 4/6] send-email: create email parser subroutine

Samuel GROOT writes: > +sub parse_email { > + my %mail = (); > + my $fh = shift; > + my $last_header; > + # Unfold and parse multiline header fields > + while (<$fh>) { > + last if /^\s*$/; You stop at the end of fields before the

Re: [PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

On Wed, Jun 8, 2016 at 9:20 AM, Pranit Bauva wrote: > On Wed, Jun 8, 2016 at 1:29 PM, Eric Sunshine wrote: >> On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: >>> + if (!file_exists(git_path_bisect_head())) { >>>

Re: [PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

On Wed, Jun 8, 2016 at 5:51 AM, Christian Couder wrote: > On Wed, Jun 8, 2016 at 9:59 AM, Eric Sunshine wrote: >>> + if (file_size(git_path_bisect_start()) < 1) { >> >> This doesn't even care about the size of the file, only if it >>

Re: [PATCH v2 63/94] builtin/apply: make apply_all_patches() return -1 on error

On Wed, Jun 8, 2016 at 12:37 PM, Christian Couder wrote: > On Mon, May 16, 2016 at 5:44 AM, Eric Sunshine > wrote: >> On Wed, May 11, 2016 at 9:17 AM, Christian Couder >> wrote: >>> if

Re: [PATCH v4 3/6] send-email: shorten send-email's output

Samuel GROOT writes: > + printf("Adding cc: %s from From: header\n", > + $1) unless $quiet; > + printf("Adding to: %s from To: > header\n", > +

Re: [PATCH v4 2/6] t9001: check email address is in Cc: field

Samuel GROOT writes: > Check if the given utf-8 email address is in the Cc: field. > > Signed-off-by: Tom RUSSELLO > Signed-off-by: Samuel GROOT > Signed-off-by: Matthieu MOY

Re: [PATCH v4 3/3] doc: more consistency in environment variables format

On 06/08/16 08:26, Matthieu Moy wrote: > Did you drop the "configuration variables" patch on purpose? Or will you > resend it separately? I just resend it separately, thank you. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org

[PATCH v4 4/3] doc: change configuration variables format

This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\././' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

Samuel GROOT writes: > @@ -97,7 +104,7 @@ test_expect_success $PREREQ 'setup expect' ' > ' > > test_expect_success $PREREQ 'Verify commandline' ' > - test_cmp expected commandline1 > + test_cmp_noorder expected commandline1 > ' > >

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

Samuel GROOT writes: > @@ -117,7 +124,7 @@ test_expect_success $PREREQ 'setup expect' ' > ' > > test_expect_success $PREREQ 'Verify commandline' ' > - test_cmp expected commandline1 > + test_cmp_noorder expected commandline1 > ' > >

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

On 06/08/2016 06:09 PM, Junio C Hamano wrote: Samuel GROOT writes: Actually we had issues when trying to refactor send-email's email parsing loop [1]. Email addresses in output file `commandeline1` in tests weren't sorted the same way as the reference file it

Re: [PATCH v2 63/94] builtin/apply: make apply_all_patches() return -1 on error

On Mon, May 16, 2016 at 5:44 AM, Eric Sunshine wrote: > On Wed, May 11, 2016 at 9:17 AM, Christian Couder > wrote: >> To finish libifying the apply functionality, apply_all_patches() should not >> die() or exit() in case of error, but return

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

On 06/07/2016 11:06 AM, William Duclot wrote: > [...] > The "fixed" feature was aimed to allow the users to use strbuf with > strings that they doesn't own themselves (a function parameter for > example). From Michael example in the original mail: > > void f(char *path_buf, size_t path_buf_len) >

Re: [PATCH v2 4/4] bundle v3: the beginning

On Wed, Jun 08, 2016 at 05:44:06PM +0700, Duy Nguyen wrote: > On Wed, Jun 8, 2016 at 3:23 AM, Jeff King wrote: > > Because this "external odb" essentially acts as a git alternate, we > > would hit it only when we couldn't find an object through regular means. > > Git would then

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

Samuel GROOT writes: > Actually we had issues when trying to refactor send-email's email > parsing loop [1]. Email addresses in output file `commandeline1` in > tests weren't sorted the same way as the reference file it was > compared to. E.g.: > >

Re: [BUG] gitk

On Wed, Jun 8, 2016 at 8:31 AM, Eric Frederich wrote: > Thanks for confirming. I do a similar workaround too. > The issue is when new Git users don't even have a ~/.config/git/gitk to > modify. > They first have to run it natively where lime exists, then they can >

[PATCH 1/2] bisect--helper: `is_expected_rev` shell function in C

Reimplement `is_expected_rev` shell function in C. This will further be called from `check_expected_revs` function. This is a quite small function thus subcommand facility is redundant. Mentored-by: Lars Schneider Mentored-by: Christian Couder

[PATCH 2/2] bisect--helper: `check_expected_revs` shell function in C

Reimplement the `check_expected_revs` shell function in C and add a `--check-expected-revs` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--check-expected-revs` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more

Re: [PATCH v2 56/94] apply: move 'struct apply_state' to apply.h

On Mon, May 16, 2016 at 6:03 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >> On Wed, May 11, 2016 at 9:17 AM, Christian Couder >> wrote: >>> To libify `git apply` functionality we must make 'struct apply_state' >>>

Re: [PATCH v2 54/94] builtin/apply: make parse_chunk() return a negative integer on error

On Mon, May 16, 2016 at 5:04 AM, Eric Sunshine wrote: > On Wed, May 11, 2016 at 9:17 AM, Christian Couder > wrote: >> To libify `git apply` functionality we have to signal errors to the >> caller instead of die()ing or exit()ing. >> >> To do

[PATCH] refs: mark the file-local vtable symbols as static

Signed-off-by: Ramsay Jones --- Hi Michael, Junio, I would normally ask you to squash this into the relevant patch when you next re-roll your 'mh/ref-iterators' branch, but this has already been merged into next. (I normally have a bit more time ... sorry!).

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

On 06/08/2016 04:22 PM, Remi Galan Alfonso wrote: +test_cmp_noorder () { +sort "$1" >"$1_noorder" +sort "$2" >"$2_noorder" +test_cmp $1 $2 You meant `test_cmp "$1_noorder" "$2_noorder"`, I guess. Yes, thanks for pointing it out! -- To unsubscribe from this list: send

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 03:35:07PM -0700, Junio C Hamano wrote: > On Tue, Jun 7, 2016 at 3:29 PM, Jeff King wrote: > > or even: > > > > git tag --show-tag-name foo/v1.0 > > > > when refs/remotes/foo/v1.0 exists? > > > > The rule right now is generally that "git tag" takes actual

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

Hi Samuel, Samuel GROOT writes: > +test_cmp_noorder () { > +sort "$1" >"$1_noorder" > +sort "$2" >"$2_noorder" > +test_cmp $1 $2 You meant `test_cmp "$1_noorder" "$2_noorder"`, I guess. Thanks, Rémi -- To unsubscribe from this list: send

Re: [PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

Hey Eric, On Wed, Jun 8, 2016 at 1:29 PM, Eric Sunshine wrote: > On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: >> Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` >> subcommand to `git bisect--helper` to call it

Re: [PATCHv3] Documentation: triangular workflow

Junio C Hamano writes: > * Introduction. As a summary, here are the four configuration > variables you'll be using to make it easier to arrange. I'd actually skip this, and keep configuration variable names for later. The very point of these --set-upstream &

[PATCH v4 6/6] send-email: add option --cite to quote the message body

If used with `in-reply-to=`, cite the message body of the given email file. Otherwise, do nothing. If `--compose` is also set, quote the message body in the cover letter. Else, imply `--annotate` by default and quote the message body below the triple-dash section in the first patch only.

Re: [PATCH 3/4] dir: introduce file_size() to check the size of file

Hey Torsten, On Wed, Jun 8, 2016 at 1:47 PM, Torsten Bögershausen wrote: > On 06/08/2016 09:57 AM, Pranit Bauva wrote: >> >> Hey Eric, >> >> On Wed, Jun 8, 2016 at 1:07 PM, Eric Sunshine >> wrote: >>> >>> On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva

[PATCH v4 5/6] send-email: --in-reply-to= populate header fields

Take an email message file, parse it and fill the "From", "To", "Cc", "In-reply-to", "References" fields appropriately. If `--compose` option is set, it will also fill the subject field with `Re: ['s subject]` in the introductory message. Signed-off-by: Tom RUSSELLO

[PATCH v4 2/6] t9001: check email address is in Cc: field

Check if the given utf-8 email address is in the Cc: field. Signed-off-by: Tom RUSSELLO Signed-off-by: Samuel GROOT Signed-off-by: Matthieu MOY --- t/t9001-send-email.sh | 4 ++-- 1 file changed, 2

[PATCH v4 4/6] send-email: create email parser subroutine

We need a simple and generic way to parse an email file. Since it would be hard to include and maintain an external library, create an simple email parser subroutine to parse an email file. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO

[PATCH v4 3/6] send-email: shorten send-email's output

Messages displayed by `send-email` should be shortened to avoid displaying unnecessary information. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO Signed-off-by: Matthieu MOY ---

[PATCH v4 1/6] t9001: non order-sensitive file comparison

Tests might fail if lines compared in text files don't have the same order. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO Signed-off-by: Matthieu MOY --- t/t9001-send-email.sh | 13

[no subject]

The purpose of this series of patches is to implement a new "quote-email" feature integrated in the current `--in-reply-to` option. * The first 2 patches make the tests less dependent to `git send-email`'s exact output. * Third patch makes `git send-email` a bit less verbose. * Fourth

Re: `man 1 git`: Invalid link to online documentation

Jeff King venit, vidit, dixit 07.06.2016 01:25: > On Mon, Jun 06, 2016 at 07:19:36PM -0400, Jeff King wrote: > >> 2. Make git-htmldocs a real site on GitHub. I think this should be as >> simple as pushing to the `gh-pages` branch of the repository, which >> would make it available as

Re: [BUG] gitk

+cc: Paul Mackerras Am 08.06.2016 um 14:31 schrieb Eric Frederich: > Thanks for confirming. I do a similar workaround too. > The issue is when new Git users don't even have a ~/.config/git/gitk to > modify. > They first have to run it natively where lime exists, then they can > edit it and use

Re: [BUG] gitk

Thanks for confirming. I do a similar workaround too. The issue is when new Git users don't even have a ~/.config/git/gitk to modify. They first have to run it natively where lime exists, then they can edit it and use it over VNC. I cannot find any instructions for submitting patches to the gitk

Re: [PATCH v4 37/38] i18n: unmark die messages for translation

Hey Junio, On Wed, Jun 8, 2016 at 3:37 AM, Junio C Hamano wrote: > Vasco Almeida writes: > >> These messages are relevant for the programmer only, not for the end >> user. Thus, they can be unmarked for translation, saving translator >> some work. >>

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

On Wed, Jun 1, 2016 at 5:08 AM, Edward Thomson wrote: > @@ -263,6 +265,7 @@ static struct option builtin_add_options[] = { > OPT_BOOL( 0 , "refresh", _only, N_("don't add, only refresh > the index")), > OPT_BOOL( 0 , "ignore-errors", _add_errors,

Re: [PATCH v2 4/4] bundle v3: the beginning

On Wed, Jun 8, 2016 at 3:23 AM, Jeff King wrote: > Because this "external odb" essentially acts as a git alternate, we > would hit it only when we couldn't find an object through regular means. > Git would then make the object available in the usual on-disk format > (probably as a

Re: [PATCH 2/4] t6030: explicitly test for bisection cleanup

Hey Eric, On Wed, Jun 8, 2016 at 1:47 PM, Eric Sunshine wrote: > On Wed, Jun 8, 2016 at 4:07 AM, Pranit Bauva wrote: >> On Wed, Jun 8, 2016 at 4:51 AM, Eric Sunshine >> wrote: >>> On Tue, Jun 7, 2016 at 4:54 PM, Pranit

Re: [PATCH 3/4] dir: introduce file_size() to check the size of file

On Wed, Jun 8, 2016 at 10:13 AM, Eric Sunshine wrote: > > I think this would be clearer if you instead added a function to > bisect--helper.c which operates at a semantically higher level than > what you have here (and drop this file_size() function). Specifically, > add

Re: [BUG] gitk

Am 08.06.2016 um 11:40 schrieb stefan.na...@atlas-elektronik.com: > Am 07.06.2016 um 21:20 schrieb Eric Frederich: >> Hello, >> >> I couldn’t find any documentation on submitting patches for gitk. >> I saw in Documentation/SubmittingPatches that gitk is maintained in >> its own repo. >> I can’t

Re: [PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

On Wed, Jun 8, 2016 at 9:59 AM, Eric Sunshine wrote: > On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: >> Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` >> subcommand to `git bisect--helper` to call it from

Re: [PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

On Wed, Jun 8, 2016 at 11:51 AM, Christian Couder wrote: > On Wed, Jun 8, 2016 at 9:59 AM, Eric Sunshine wrote: >> On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: >>> Reimplement `bisect_reset` shell function in C

Re: [PATCH 1/4] bisect--helper: `bisect_clean_state` shell function in C

On Wed, Jun 8, 2016 at 10:02 AM, Eric Sunshine wrote: > On Wed, Jun 8, 2016 at 3:46 AM, Pranit Bauva wrote: >> On Wed, Jun 8, 2016 at 4:01 AM, Eric Sunshine >> wrote: >>> On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva

Re: [BUG] gitk

Am 07.06.2016 um 21:20 schrieb Eric Frederich: > Hello, > > I couldn’t find any documentation on submitting patches for gitk. > I saw in Documentation/SubmittingPatches that gitk is maintained in > its own repo. > I can’t clone repo’s unless they’re http while on my corporate proxy. > I’m hoping

Re: [PATCH v3 3/6] t9001: shorten send-email's output

On 06/08/2016 10:36 AM, Eric Wong wrote: Tom Russello wrote: Messages displayed by `send-email` should be shortened to avoid displaying unnecesseray informations. unnecessary information. In some of your other patches, the 'grep' can probably be better

Re: [PATCHv3] Documentation: triangular workflow

> Le 7 juin 2016 à 21:12, Junio C Hamano a écrit : > > Jordan DE GEA writes: > >> + >> +- Taking the last version of the project by fetching (e.g. >> + **UPSTREAM**) > > "by fetching (e.g. UPSTREAM)" does not finish the sentence nicely. > >

Re: [PATCH v3 3/6] t9001: shorten send-email's output

Tom Russello wrote: > Messages displayed by `send-email` should be shortened to avoid displaying > unnecesseray informations. unnecessary information. In some of your other patches, the 'grep' can probably be better replaced by 'fgrep' for fixed strings.

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

On 06/08/2016 03:07 AM, Junio C Hamano wrote: I am having a hard time guessing what prompted you to sort the output, i.e. what problem you were trying to solve. It cannot be because addresses on a list (e.g. Cc:) could come out in an indeterministic order, because the address that a test

Re: [PATCH 3/4] dir: introduce file_size() to check the size of file

On 06/08/2016 09:57 AM, Pranit Bauva wrote: Hey Eric, On Wed, Jun 8, 2016 at 1:07 PM, Eric Sunshine wrote: On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: dir: introduce file_size() to check the size of file At times we require to see if

  1   2   >