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, t
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 expected. So I would be perfe
Brandon Williams writes:
> ...
> [--full-name] [--recurse-submodules]
> - [--output-path-prefix=]
> + [--submodule-prefix=]
> [--abbrev] [--] [...]
>
> ---output-path-prefix=::
> +--submodule-prefix=::
> Prepend the provided path to the
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
---
Documentation/git-ls-files.txt |
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
> --subject-prefix='RF
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 out
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 should refactor check_header
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, et al.
> transport_downlo
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 explicitly itself?
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) &&
>> !(mi->use_scissors && is_sciss
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, const
>> char *set, const char *res
>>
>>
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
>>> intervening blank line).
>>
>> This comes from d25e51
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)) {
> + fprintf(stderr,
> +
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 am/mailinfo: Don't look at in-body
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 obj
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: th
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.
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 a
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))
> return
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 v
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};
> > + r
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 charact
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:
>
> From: Me
> -- 8
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:
> upload-pack and receive-pac
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 in
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 thing would be the best
>
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 we detect the start of a new
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 rebasing", 2009-11-20), where
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 patchbreak line to be misi
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 it".
>
Yes, we woul
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 set on that command.
Than
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 submodule to "git submodul
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 into these and the reas
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, sha1_to_hex(sha1));
> +}
Hmph,
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);
> }
>
> -int find_unpushed
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):
> https://github.com/autodesk-forks/git/commit/fcfc96a7814935ee6cefb9d69e44def30a90eabb
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 long
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 l
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
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
On Fri, Sep 16, 2016 at 10:27 AM, Josh Triplett wrote:
> 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 PA
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);
> + if (item->util)
>
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 optimizing for
the commo
> 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
> conditions like network unreliabi
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 it
> 3. git commit ev
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
> > $ git -C sub
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 pu
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", NULL, "--not", "--remote
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 what I did with a first patch to ls-files
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 indir
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 used only when the output i
--
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.
W
52 matches
Mail list logo
