Re: [PATCH] format-patch: Add --rfc for the common case of [RFC PATCH]

On Fri, Sep 16, 2016 at 05:49:22PM -0700, Jeff King wrote: > On Fri, Sep 16, 2016 at 10:27:45AM -0700, Josh Triplett wrote: > > > By far, the most common subject-prefix I've seen other than "PATCH" is > > "RFC PATCH" (or occasionally "PATCH RFC"). Seems worth optimizing for > > the common case,

Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example

Jonathan Tan writes: > From: bogosity > - a list > - of stuff > > Unchanged, the subsequent patch would break this test because it would > interpret that as a multi-line "From" in-body header when in-body > headers are *not* disabled. Yes, that is totally

Re: [PATCH] ls-files: add pathspec matching for submodules

Brandon Williams writes: > ... > [--full-name] [--recurse-submodules] > - [--output-path-prefix=] > + [--submodule-prefix=] > [--abbrev] [--] [...] > > ---output-path-prefix=:: > +--submodule-prefix=:: > Prepend the

[PATCH] ls-files: add pathspec matching for submodules

Pathspecs can be a bit tricky when trying to apply them to submodules. This change permits the pathspec logic to perform a prefix match against submodules since a pathspec could refer to a file inside of a submodule. Signed-off-by: Brandon Williams ---

Re: [PATCH] format-patch: Add --rfc for the common case of [RFC PATCH]

On Fri, Sep 16, 2016 at 10:27:45AM -0700, Josh Triplett wrote: > By far, the most common subject-prefix I've seen other than "PATCH" is > "RFC PATCH" (or occasionally "PATCH RFC"). Seems worth optimizing for > the common case, to avoid having to spell it out the long way as >

Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example

On 09/16/2016 03:55 PM, Junio C Hamano wrote: Hmph, these: t/t5100/info0008--no-inbody-headers | 5 + t/t5100/msg0008--no-inbody-headers | 6 ++ t/t5100/msg0015--no-inbody-headers | 1 + have --no-inbody-headers in their names; wouldn't that an indication that they are expected

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

On 09/16/2016 04:04 PM, Junio C Hamano wrote: Jonathan Tan writes: I'm concerned about what happens if check_header fails - we would then have some lines which need to be treated as log messages. (At least, they are currently treated that way.) I actually think we

Re: [PATCH 11/11] Resumable clone: implement primer logic in git-clone

Kevin Wern writes: > Use transport_download_primer and transport_prime_clone in git clone. > This only supports a fully connected packfile. > > transport_prime_clone and transport_download_primer are executed > completely independent of transport_(get|fetch)_remote_refs,

Re: [PATCH 10/11] run command: add RUN_COMMAND_NO_STDOUT

Kevin Wern writes: > Add option RUN_COMMAND_NO_STDOUT, which sets no_stdout on a child > process. > > This will be used by git clone when calling index-pack on a downloaded > packfile. If it is just one caller, would't it make more sense for that caller set no_stdout

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

Jonathan Tan writes: > On 09/16/2016 01:59 PM, Junio C Hamano wrote: >> if (mi->in_line_header->len) { >> /* we have read the beginning of one in-line header */ >> if (line->len && isspace(*line->buf) && >>

Re: [PATCH 03/10] diff.c: drop tautologous condition in emit_line_0

On Mon, Sep 12, 2016 at 4:53 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> diff --git a/diff.c b/diff.c >> index 156c2aa..9d2e704 100644 >> --- a/diff.c >> +++ b/diff.c >> @@ -460,8 +460,7 @@ static void emit_line_0(struct diff_options *o,

Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example

Jonathan Tan writes: > On 09/16/2016 12:19 PM, Junio C Hamano wrote: >> Jonathan Tan writes: >> >>> An existing sample message (0015) in the tests for mailinfo contains an >>> indented line immediately after an in-body header (without any >>>

Re: [PATCH 07/11] Resumable clone: add resumable download to http/curl

Kevin Wern writes: > +int http_download_primer(const char *url, const char *out_file) > +{ > + int ret = 0, try_count = HTTP_TRY_COUNT; > + struct http_get_options options = {0}; > + options.progress = 1; > + > + if (file_exists(out_file)) { > +

Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example

On 09/16/2016 12:19 PM, Junio C Hamano wrote: Jonathan Tan writes: An existing sample message (0015) in the tests for mailinfo contains an indented line immediately after an in-body header (without any intervening blank line). This comes from d25e5159 ("git

git-subtree pull issue

When git-subtree is pulling data using the tag reference, it writes the tag's sha1 into a metadata. It could be a problem next time, since this commit object is not a part of main tree, and could be lost. Steps to reproduce: # add some stuff to a existing tree # history will refer to v0.1 tag

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

On 09/16/2016 01:59 PM, Junio C Hamano wrote: if (mi->in_line_header->len) { /* we have read the beginning of one in-line header */ if (line->len && isspace(*line->buf) && !(mi->use_scissors && is_scissors_line(line))) { Minor note:

[wishlist] disable boring messages

Hi, is it possible to make git silent, when nothing interesting is happening? I have a lot of repos and a batch script to update them all, and I want to get rid of 'Fetching origin' and 'Already up-to-date.' messages leaving only new refs and tags.

Re: [PATCH] mailinfo: unescape quoted-pair in header fields

On Fri, Sep 16, 2016 at 11:02:04PM +0200, Kevin Daudt wrote: > rfc2822 has provisions for quoted strings in structured header fields, > but also allows for escaping these with so-called quoted-pairs. > > The only thing git currently does is removing exterior quotes, but > quotes within are left

Re: [PATCH 03/11] pkt-line: create gentle packet_read_line functions

Kevin Wern writes: > /* And complain if we didn't get enough bytes to satisfy the read. */ > if (ret < size) { > - if (options & PACKET_READ_GENTLE_ON_EOF) > + if (options & (PACKET_READ_GENTLE_ON_EOF | > PACKET_READ_GENTLE_ALL)) >

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

On Fri, Sep 16, 2016 at 10:37:24AM -0700, Jonathan Tan wrote: > Mailinfo currently handles multi-line headers, but it does not handle > multi-line in-body headers. Teach it to handle such headers, for > example, for this input: > > Subject: a very long >broken line > > Subject: another

Re: [RFC/PATCH 1/3] mailinfo: refactor commit message processing

On Fri, Sep 16, 2016 at 12:12:50PM -0700, Junio C Hamano wrote: > > +static int check_header_raw(struct mailinfo *mi, > > + char *buf, size_t len, > > + struct strbuf *hdr_data[], int overwrite) { > > + const struct strbuf sb = {0, len, buf}; > > +

[PATCH] mailinfo: unescape quoted-pair in header fields

rfc2822 has provisions for quoted strings in structured header fields, but also allows for escaping these with so-called quoted-pairs. The only thing git currently does is removing exterior quotes, but quotes within are left alone. Tell mailinfo to remove exterior quotes and remove escape

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

Jonathan Tan writes: >> handle_commit_msg(...) >> { >> if (mi->in_line_header->len) { >> /* we have read the beginning of one in-line header */ >> if (line->len && isspace(*line->buf)) > > This would mean that a message like the following:

Re: [PATCH 01/11] Resumable clone: create service git-prime-clone

Kevin Wern writes: > Create git-prime-clone, a program to be executed on the server that > returns the location and type of static resource to download before > performing the rest of a clone. > > Additionally, as this executable's location will be configurable (see: >

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

On 09/16/2016 01:17 PM, Junio C Hamano wrote: In other words, wouldn't something like the illustration at the end of this message sufficient? If the body consists solely of in-body header without any patch or patchbreak, we may reach EOF with something in mi->in_line_header buffer and nothing

Re: [PATCH 00/11] Resumable clone

Kevin Wern writes: > It's been a while (sent a very short patch in May), but I've > still been working on the resumable clone feature and checking up on > the mailing list for any updates. After submitting the prime-clone > service alone, I figured implementing the whole

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

Jonathan Tan writes: > Instead of repeatedly calling "check_header" (as in this patch), one > alternate method to accomplish this would be to have a buffer of > potential header text in struct mailinfo to be flushed whenever a header > is known to end (for example, if

Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example

Jonathan Tan writes: > An existing sample message (0015) in the tests for mailinfo contains an > indented line immediately after an in-body header (without any > intervening blank line). This comes from d25e5159 ("git am/mailinfo: Don't look at in-body headers when

Re: [RFC/PATCH 1/3] mailinfo: refactor commit message processing

Jonathan Tan writes: > Within the processing of the commit message, check for a scissors line > or a patchbreak line first (before checking for in-body headers) so that > a subsequent patch modifying the processing of in-body headers would not > cause a scissors line or

Re: [RFC] extending pathspec support to submodules

On Thu, Sep 15, 2016 at 3:08 PM, Junio C Hamano wrote: > > * Your program that runs in the top-level superproject still needs >to be able to say "this pathspec from the top cannot possibly >match anything in the submodule, so let's not even bother >descending into

Re: [RFC/PATCH 0/3] handle multiline in-body headers

Jonathan Tan writes: > Thanks, Peff, for the explanation and the method to reproduce the issue. > > The issue seems to be in mailinfo.c - this patch set addresses that, and I > have > also included a test for "git am" in t/t4150-am.sh to show the effect of this > patch

Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

Heiko Voigt writes: > On Thu, Sep 15, 2016 at 11:27:54AM -0700, Junio C Hamano wrote: > >> If the trend in Git community collectively these days is to make >> usage of submodules easier and smoother, I'd imagine that you would >> want to teach "git add" that was given a

Re: [PATCH 3/2] batch check whether submodule needs pushing into one call

Heiko Voigt writes: > On Fri, Sep 16, 2016 at 11:40:19AM +0200, Heiko Voigt wrote: >> > By the way, with the two new patches, 'pu' seems to start failing >> > some tests, e.g. 5533 5404 5405. >> >> Ah ok I did only test on master, will look into those. > > Ok I had a look

Re: [PATCH 3/2] batch check whether submodule needs pushing into one call

Heiko Voigt writes: > +static void append_hash_to_argv(const unsigned char sha1[20], void *data) > { > - if (add_submodule_odb(path) || !lookup_commit_reference(sha1)) > + struct argv_array *argv = (struct argv_array *) data; > + argv_array_push(argv,

Re: [PATCH 2/2] serialize collection of refs that contain submodule changes

Heiko Voigt writes: > diff --git a/submodule.c b/submodule.c > index b04c066..a15e346 100644 > --- a/submodule.c > +++ b/submodule.c > @@ -627,24 +627,31 @@ static void free_submodules_sha1s(struct string_list > *submodules) > string_list_clear(submodules, 1); > } >

Re: [PATCH v2 1/1] git-p4: Add --checkpoint-period option to sync/clone

On Fri, Sep 16, 2016 at 11:19 AM, Lars Schneider wrote: > > > This looks interesting! I ran into the same issue and added a parameter to > the p4 commands to retry (patch not yet proposed to the mailing list): >

[RFC/PATCH 3/3] mailinfo: handle in-body header continuations

Mailinfo currently handles multi-line headers, but it does not handle multi-line in-body headers. Teach it to handle such headers, for example, for this input: Subject: a very long broken line Subject: another very long broken line interpret the in-body subject to be "another very

[RFC/PATCH 2/3] mailinfo: correct malformed test example

An existing sample message (0015) in the tests for mailinfo contains an indented line immediately after an in-body header (without any intervening blank line). Correct this by adding the blank line, in preparation for a subsequent patch that will treat such indented lines as RFC 2822 continuation

[RFC/PATCH 1/3] mailinfo: refactor commit message processing

Within the processing of the commit message, check for a scissors line or a patchbreak line first (before checking for in-body headers) so that a subsequent patch modifying the processing of in-body headers would not cause a scissors line or patchbreak line to be misidentified. If a line could be

[RFC/PATCH 0/3] handle multiline in-body headers

Thanks, Peff, for the explanation and the method to reproduce the issue. The issue seems to be in mailinfo.c - this patch set addresses that, and I have also included a test for "git am" in t/t4150-am.sh to show the effect of this patch set on that command. Jonathan Tan (3): mailinfo: refactor

Re: [PATCH 1/2] serialize collection of changed submodules

Heiko Voigt writes: > +static struct sha1_array *get_sha1s_from_list(struct string_list *submodules, > + const char *path) > +{ > + struct string_list_item *item; > + struct sha1_array *hashes; > + > + item = string_list_insert(submodules, path); > +

[PATCH] format-patch: Add --rfc for the common case of [RFC PATCH]

This provides a shorter and more convenient alias for --subject-prefix='RFC PATCH'. Add a test covering --rfc. Signed-off-by: Josh Triplett --- By far, the most common subject-prefix I've seen other than "PATCH" is "RFC PATCH" (or occasionally "PATCH RFC"). Seems worth

Re: [PATCH v2 1/1] git-p4: Add --checkpoint-period option to sync/clone

> On 15 Sep 2016, at 23:17, Ori Rawlings wrote: > > Importing a long history from Perforce into git using the git-p4 tool > can be especially challenging. The `git p4 clone` operation is based > on an all-or-nothing transactionality guarantee. Under real-world >

Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

On Fri, Sep 16, 2016 at 7:11 AM, Heiko Voigt wrote: > How about just > >git submodule add > > ? I remember back in the days when I started with submodules thats the > way I imagined submodules would work: > > 1. clone the submodule into a directory > 2. git submodule add

Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

On Thu, Sep 15, 2016 at 11:27:54AM -0700, Junio C Hamano wrote: > Stefan Beller writes: > > So how about this fictional work flow: > > > > $ git init top > > $ cd top > > $ git commit --allow-empty -m 'initial in top' > > $ git init sub > >

Re: [PATCH 3/2] batch check whether submodule needs pushing into one call

On Fri, Sep 16, 2016 at 11:40:19AM +0200, Heiko Voigt wrote: > > By the way, with the two new patches, 'pu' seems to start failing > > some tests, e.g. 5533 5404 5405. > > Ah ok I did only test on master, will look into those. Ok I had a look into these and the reason t5533 fails is because on

Re: [PATCH 3/2] batch check whether submodule needs pushing into one call

On Thu, Sep 15, 2016 at 02:08:58PM -0700, Junio C Hamano wrote: > Heiko Voigt writes: > > > if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) { > > struct child_process cp = CHILD_PROCESS_INIT; > > - const char *argv[] = {"rev-list",

Re: [RFC] extending pathspec support to submodules

Hi, On Thu, Sep 15, 2016 at 03:28:21PM -0700, Stefan Beller wrote: > On Thu, Sep 15, 2016 at 3:08 PM, Junio C Hamano wrote: > > Brandon Williams writes: > > > >> You're right that seems like the best course of action and it already falls > >> inline with

[PATCH] Documentation/config: default for color.* is color.ui

Since 4c7f181 (make color.ui default to 'auto', 2013-06-10), the default for color.* when nothing is set is 'auto' and we still claimed that the default was 'false'. Be more precise by saying explicitly that the default is to follow color.ui, and recall that the default is 'auto' to avoid one

Re: Potentially misleading color.* defaults explanation in git-config(1)

Anatoly Borodin writes: > Hi All! > > git-config(1) says: > >color.branch >A boolean to enable/disable color in the output of git-branch(1). >May be set to always, false (or never) or auto (or true), in which >case colors are

Ich werde warten, von Ihnen zu hören.

-- Lieber Freund, Wie geht es Ihnen heute? Ich habe eine Investitionsmöglichkeit mit Ihnen zu teilen, die die Übertragung einer großen Geldsumme zum gegenseitigen Nutzen für beide von uns betreffen. Mein Name ist Andrew Hau Chung, ich in einem Finanzinstitut arbeiten hier in Hong Kong.

Re: Gitattributes file is not respected when switching between branches

Sorry for delay. ".gitattributes" indeed is not present in "master", but this is intentionally It is placed only in following 2 branches: feature-branch unix-feature-branch This is how flow looks on windows $ git --version git version 2.9.3.windows.1 vitalii.ishchenko@DESKTOP-9TC9UPB MINGW64