Re: [PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

Jeff King writes: >> atom->u.contents.option = C_SUB; >> -else if (!strcmp(arg, "trailers")) >> -atom->u.contents.option = C_TRAILERS; >> -else if (skip_prefix(arg, "lines=", )) { >> +else if (skip_prefix(arg, "trailers", )) { >> +

Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h

>> Simplify mru.[ch] and related code by reusing the double-linked list >> implementation from list.h instead of a custom one. >> This commit is an intermediate step. Our final goal is to get rid of >> mru.[ch] at all and inline all logic. > > Thanks, this version looks correct to me. Great! What

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Jonathan Nieder writes: > +Reading an object's sha1-content > + > +The sha1-content of an object can be read by converting all newhash-names > +its newhash-content references to sha1-names using the translation table. Sure. > +Fetch > +~

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Jonathan Nieder writes: >>> +6. Skip fetching some submodules of a project into a NewHash >>> + repository. (This also depends on NewHash support in Git >>> + protocol.) >> >> It is unclear what this means. Around submodule support, one thing >> I can think of is that a

Purchase Order Copy

Dear Sir Please find the attached copy of Purchase order with the item details and confirm with us immediately Thank you Aldaz <>

Re: [PATCH Outreachy] mru: use double-linked list from list.h

On Sat, Sep 30, 2017 at 09:09:11PM +0300, Оля Тележная wrote: > I added "v2" after "PATCH", but it does not appeared. Actually it was > written automatically and it was "PATCH Outreachy v2". I rearranged it > in the middle of the phrase. That looks fine. > > I'm not sure what you mean about

Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h

On Sat, Sep 30, 2017 at 05:51:01PM +, Olga Telezhnaya wrote: > Simplify mru.[ch] and related code by reusing the double-linked list > implementation from list.h instead of a custom one. > This commit is an intermediate step. Our final goal is to get rid of > mru.[ch] at all and inline all

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

Taylor Blau writes: > Attached is the sixth revision of my patch-set "Support %(trailers) > arguments in for-each-ref(1)". > > In includes the following changes since v5: > > * Added an additional patch to change t4205 to harden `unfold()` > against multi-line trailer

cmd.exe Terminal is closing when cloning a repository on windows 10 (64.bit)

Hi, I installed git for windows 2.14.2 (64bit) and was trying to clone a repository from a command terminal (cmd.exe): git clone https://netzeb...@bitbucket.org/Netzeband/deep-speeddreams.git First everything went well, but after the repository was downloaded the LFS download started. At

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

On Sun, Oct 01, 2017 at 10:23:26PM -0700, Taylor Blau wrote: > Attached is the sixth revision of my patch-set "Support %(trailers) > arguments in for-each-ref(1)". > > In includes the following changes since v5: > > * Added an additional patch to change t4205 to harden `unfold()` >

Re: [PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

On Sun, Oct 01, 2017 at 10:25:24PM -0700, Taylor Blau wrote: > The %(contents) atom takes a contents "field" as its argument. Since > "trailers" is one of those fields, extend contents_atom_parser to parse > "trailers"'s arguments when used through "%(contents)", like: > >

Re: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers

On Sun, Oct 01, 2017 at 10:53:11PM -0700, Taylor Blau wrote: > Peff points out that different atom parsers handle the empty > "sub-argument" list differently. An example of this is the format > "%(refname:)". > > Since callers often use `string_list_split` (which splits the empty > string with

Re: [PATCH 00/11] various lockfile-leaks and -fixes

Jeff King writes: > I've read through each and with the exception of patches 10 and 11, they > all look good to me. > > For 10 and 11, I think you've convinced me that the current behavior is > buggy. I do wonder if the subtleties might be easier to understand as a > single patch,

Re: [PATCH] builtin/: add UNLEAKs

On Sun, Oct 01, 2017 at 07:42:08PM +0200, Martin Ågren wrote: > Add some UNLEAKs where we are about to return from `cmd_*`. UNLEAK the > variables in the same order as we've declared them. While addressing > `msg` in builtin/tag.c, convert the existing `strbuf_release()` calls as > well. It

Re: [PATCH 00/11] various lockfile-leaks and -fixes

On Sun, Oct 01, 2017 at 04:56:01PM +0200, Martin Ågren wrote: > A recent series allowed `struct lock_file`s to be freed [1], so I wanted > to get rid of the "simple" leaks of this kind. I found a couple of > lock-related cleanups along the way and it resulted in this series. It > feels a bit

Re: [PATCH 10/11] read-cache: don't leave dangling pointer in `do_write_index()`

On Mon, Oct 02, 2017 at 02:15:30AM -0400, Jeff King wrote: > I'm not sure I follow here. It seems like write_locked_index() has three > outcomes: > > - if there was an error, the lock is rolled back > > - if we were successful and the caller asked for CLOSE_LOCK, we remain > locked > >

Re: [PATCH 10/11] read-cache: don't leave dangling pointer in `do_write_index()`

On Sun, Oct 01, 2017 at 04:56:11PM +0200, Martin Ågren wrote: > If `do_write_index(..., struct tempfile *, ...)` fails to close the > temporary file, it deletes it. This resets the pointer to NULL, but only > the pointer which is local to `do_write_index()`, not the pointer that > the caller

Re: [PATCH 09/11] read-cache: require flags for `write_locked_index()`

On Sun, Oct 01, 2017 at 04:56:10PM +0200, Martin Ågren wrote: > `write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`. > At most one is allowed. But it is also possible to use no flag, i.e., > `0`. But when `write_locked_index()` calls `do_write_index()`, the > temporary file,

<    1   2