On Thu, Sep 28, 2017 at 8:51 PM, Junio C Hamano wrote:
> I think that your patch the last round that feeds fd#8 in the
> foreground (i.e. fully trusting that the caller is sensibly giving
> input that produces no output) is already a good place to stop.
>
> Your patch this
Dridi Boukelmoune writes:
> For end users making use of a custom exec path many commands will simply
> fail. Adding git's exec path to the PATH also allows overriding git-sh-*
> scripts, not just adding commands. One can then patch a script without
> tainting their
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes
On Thu, Sep 28, 2017 at 02:31:17PM +0200, Johannes Schindelin wrote:
>>> Max Kirillov writes:
Tilda-based path may confise some users. First, tilda is not known
for Window users, second, it may point to unexpected location
depending on various environment setup.
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> This has been broken for a while, but better late than never to
>> address it.
>
> I am not sure if this is broken in the first place. We do want to
> make sure that the scripted porcelains will source the shell helper
>
Jonathan Nieder writes:
> Separate from this example: yes, I think adopting Linux's Reviewed-by
> convention would be a good thing. When I see a positive reply to a
> patch, I often wonder whether an ack or a fuller reviewed-by is
> intended, and Linux's way of formalizing
Jonathan Nieder writes:
> This has been broken for a while, but better late than never to
> address it.
I am not sure if this is broken in the first place. We do want to
make sure that the scripted porcelains will source the shell helper
library from matching Git release.
"Eric Rannaud" writes:
> Junio, this last version addresses your last remark regarding the
> potential for the cat $input_file sequence to block when the FIFOs are
> unbuffered.
>
> The concern is mainly theoretical (*if* the shell function is used
> correctly):
Hi,
Dridi Boukelmoune wrote:
> For end users making use of a custom exec path many commands will simply
> fail. Adding git's exec path to the PATH also allows overriding git-sh-*
> scripts, not just adding commands. One can then patch a script without
> tainting their system installation of git
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Andreas Heiduk wrote:
>>> +1, Thanks for spotting.
>>
>> Thanks for looking it over. Can we add your Reviewed-by? (See [1]
>> for what this means.)
>
> I would just do "Acked-by: Andreas" after seeing such an obvious
>
The checkpoint command cycles packfiles if object_count != 0, a sensible
test or there would be no pack files to write. Since 820b931012, the
command also dumps branches, tags and marks, but still conditionally.
However, it is possible for a command stream to modify refs or create
marks without
Adam Dinwoodie writes:
>> Also adding the necessary PIPE prereq, as pointed out by Ramsay Jones.
>
> Cygwin doesn't have the PIPE prereq; I've just confirmed that the
> previous version of this patch has t9300 failing on Cygwin, but this
> version passes.
Thanks for a
Ben Peart writes:
> The only behavioral change from V7 is the removal of unnecessary uses of
> CE_MATCH_IGNORE_FSMONITOR. With a better understanding of *why* the
> CE_MATCH_IGNORE_* flags are used, it is now clear they are not required
> in most cases where
Jeff King writes:
> On Mon, Sep 25, 2017 at 09:59:57AM +0200, Michael Haggerty wrote:
>
>> This is v3 of a patch series that changes the reading and caching of
>> the `packed-refs` file to use `mmap()`. Thanks to Stefan, Peff, Dscho,
>> and Junio for their comments about v2. I
Jonathan Tan writes:
> I've pushed a new version:
>
> https://github.com/jonathantanmy/git/tree/partialclone3
Just FYI, the reason why I commented only on the first patch in your
previous series at GitHub wasn't because I found the others perfect
and nothing to comment
Jonathan Nieder writes:
> Andreas Heiduk wrote:
>
>> +1, Thanks for spotting.
>
> Thanks for looking it over. Can we add your Reviewed-by? (See [1]
> for what this means.)
I would just do "Acked-by: Andreas" after seeing such an obvious
admission of guilt & appreciation
On Fri, 15 Sep 2017 13:43:43 -0700
Jonathan Tan wrote:
> For those interested in partial clones and/or missing objects in repos,
> I've updated my original partialclone patches to not require an explicit
> list of promises. Fetch/clone still only permits exclusion of
[jch: a patch that hopefully is applicable is attached at the end;
I'd appreciate input from Paolo, the contributor of the original
upstream]
"Randall S. Becker" writes:
> After a whole lot of investigating, we (it is a large "we") have discovered
> the reason for the
On Thu, Sep 28, 2017 at 08:38:39AM +, Olga Telezhnaya wrote:
> diff --git a/packfile.c b/packfile.c
> index f69a5c8d607af..ae3b0b2e9c09a 100644
> --- a/packfile.c
> +++ b/packfile.c
> @@ -876,6 +876,7 @@ void prepare_packed_git(void)
> for (alt = alt_odb_list; alt; alt = alt->next)
>
For end users making use of a custom exec path many commands will simply
fail. Adding git's exec path to the PATH also allows overriding git-sh-*
scripts, not just adding commands. One can then patch a script without
tainting their system installation of git for example.
Signed-off-by: Dridi
Am 28.09.2017 um 21:34 schrieb Jonathan Nieder:
> Andreas Heiduk wrote:
>
>> +1, Thanks for spotting.
>
> Thanks for looking it over. Can we add your Reviewed-by? (See [1]
> for what this means.)
Well, I'd like to see the following occurrence of the same problem
solved in that patch, too.
On 09/27, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Teach the connection logic to tell a serve that it understands protocol
> > v1. This is done in 2 different ways for the built in protocols.
> >
> > 1. git://
> >A normal request is structured as "command
On Fri, Sep 29, 2017 at 06:56:28AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > But I also think this patch may be a stepping stone to dropping "struct
> > mru" entirely, and just pushing a "struct list_head mru" into the
> > packed_git object itself (or of course any
On 09/27, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > +/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise.
> > */
> > +static int process_protocol_version(void)
> > +{
> > + switch (determine_protocol_version_client(packet_buffer)) {
> > +
Johannes Schindelin writes:
>> > Max Kirillov writes:
>> >
>> >> Tilda-based path may confise some users. First, tilda is not known
>> >> for Window users, second, it may point to unexpected location
>> >> depending on various environment setup.
>
On 09/27, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > +`GIT_PROTOCOL`::
> > + For internal use only. Used in handshaking the wire protocol.
> > + Contains a colon ':' separated list of keys with optional values
> > + 'key[=value]'. Presence of unknown keys
Jeff King writes:
> But I also think this patch may be a stepping stone to dropping "struct
> mru" entirely, and just pushing a "struct list_head mru" into the
> packed_git object itself (or of course any object you like). At which
> point we'd just directly use the list iterators
--
Hello,
I bid you greetings, I have an important overture for you. Details shall be
given when you confirm the receipt of this email.
Regards,
Sgt Monica Brown
Hi Team,
After a whole lot of investigating, we (it is a large "we") have discovered
the reason for the hang we occasionally get in git-upload-pack on HPE
NonStop servers - reported here well over a year ago. This resulted from a
subtle check that the operating system does on file descriptors.
On Wed, Sep 27, 2017 at 11:05:49PM +0100, pedro rijo wrote:
> While the git repository itself is not hosted under GitHub, the Pro
> Git book, git for Windows, and git-scm website (at least) projects
> are, and could use this movement to get some more contributions, and
> eventually more
On 09/26, Stefan Beller wrote:
> > +extern enum protocol_version get_protocol_version_config(void);
> > +extern enum protocol_version determine_protocol_version_server(void);
> > +extern enum protocol_version determine_protocol_version_client(const char
> > *server_response);
>
> It would be
On Thu, Sep 28, 2017 at 08:38:39AM +, Olga Telezhnaya wrote:
> Simplify mru.c, mru.h and related code by reusing the double-linked
> list implementation from list.h instead of a custom one.
The commit message is a good reason to talk about why we want to do
this. In this case, the answer may
On Thu, Sep 28, 2017 at 5:59 AM, Adam Dinwoodie wrote:
> On Wed, Sep 27, 2017 at 10:07:41PM -0700, Eric Rannaud wrote:
>>
>> Also adding the necessary PIPE prereq, as pointed out by Ramsay Jones.
>
> Cygwin doesn't have the PIPE prereq; I've just confirmed that the
> previous
On Thu, Sep 28, 2017 at 08:03:00PM +0900, Junio C Hamano wrote:
> > - for (entry = packed_git_mru.head; entry; entry = entry->next) {
> > + list_for_each(pos, _git_mru.list) {
> > + struct mru *entry = list_entry(pos, struct mru, list);
> > struct packed_git *p =
On Thu, Sep 28, 2017 at 3:35 AM, Junio C Hamano wrote:
> "Eric Rannaud" writes:
>
>> +# The commands in input_file should not produce any output on the file
>> +# descriptor set with --cat-blob-fd (or stdout if unspecified).
>
> Thanks for documenting
On Thu, Sep 28, 2017 at 10:46:16AM -0700, Jonathan Tan wrote:
> > To me it seems like a much simpler API for a map would be to just allow
> > callers to store a 'void *' as the value.
>
> I agree that the API would be simpler.
>
> My main motivation with this design is indeed to save memory,
Hi,
Andreas Heiduk wrote:
> +1, Thanks for spotting.
Thanks for looking it over. Can we add your Reviewed-by? (See [1]
for what this means.)
> I did a quick
>
> grep -r " ` "
>
> which came up with with another relevant place:
>
> Documentation/git-format-patch.txt:
--
Hello
I am Khadov Amir Moh., a former resident of Birmingham UK.
Please reach me for the details of an extremely important business
proposition.
Have a nice day.
Khadov Amir Moh.
Adam Dinwoodie wrote:
> Leaving spaces around the `-delimeters for commands means asciidoc fails
> to parse them as the start of a literal string. Remove an extraneous
> space that is causing a literal to not be formatted as such.
>
> Signed-off-by: Adam Dinwoodie
> ---
>
On Wed, 27 Sep 2017 17:41:37 -0700
Brandon Williams wrote:
> On 09/27, Jonathan Tan wrote:
> > This is similar to using the hashmap in hashmap.c, but with an
> > easier-to-use API. In particular, custom entry comparisons no longer
> > need to be written, and lookups can be
On Thu, 28 Sep 2017 12:13:00 +0900
Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > This is similar to using the hashmap in hashmap.c, but with an
> > easier-to-use API. In particular, custom entry comparisons no longer
> > need to be written, and
Am 28.09.2017 um 16:06 schrieb Adam Dinwoodie:
> Leaving spaces around the `-delimeters for commands means asciidoc fails
> to parse them as the start of a literal string. Remove an extraneous
> space that is causing a literal to not be formatted as such.
>
> Signed-off-by: Adam Dinwoodie
On 09/28, Johannes Schindelin wrote:
> Hi all,
>
> On Thu, 10 Aug 2017, Johannes Schindelin wrote:
>
> > On Tue, 8 Aug 2017, Brandon Williams wrote:
> >
> > > On 08/08, Stefan Beller wrote:
> > > > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > > > wrote:
> >
On 09/27, Brandon Williams wrote:
> On 09/27, Junio C Hamano wrote:
> > Brandon Williams writes:
> >
> > > A normal request to git-daemon is structured as
> > > "command path/to/repo\0host=..\0" and due to a bug in an old version of
> > > git-daemon 73bb33a94 (daemon: Strictly
Hi Peff,
On Wed, 27 Sep 2017, Jeff King wrote:
> For the other comments on v1, I decided not to make any changes:
>
> - JSixt suggested marking this as a local-repo variable. I think we
> really do want it to cross repo boundaries to handle submodules (and
> the GfW version does the
On 9/27/2017 8:05 PM, Jonathan Tan wrote:
On Wed, 27 Sep 2017 13:09:42 -0400
Jeff Hostetler wrote:
On 9/26/2017 6:39 PM, Jonathan Tan wrote:
On Fri, 22 Sep 2017 20:30:11 +
Jeff Hostetler wrote:
Makefile| 1 +
Leaving spaces around the `-delimeters for commands means asciidoc fails
to parse them as the start of a literal string. Remove an extraneous
space that is causing a literal to not be formatted as such.
Signed-off-by: Adam Dinwoodie
---
Documentation/git.txt | 2 +-
1 file
On Wed, Sep 27, 2017 at 10:07:41PM -0700, Eric Rannaud wrote:
> The checkpoint command cycles packfiles if object_count != 0, a sensible
> test or there would be no pack files to write. Since 820b931012, the
> command also dumps branches, tags and marks, but still conditionally.
> However, it is
Hi Junio,
On Thu, 28 Sep 2017, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Max Kirillov writes:
> >
> >> Tilda-based path may confise some users. First, tilda is not known
> >> for Window users, second, it may point to unexpected location
> >>
Hi all,
On Thu, 10 Aug 2017, Johannes Schindelin wrote:
> On Tue, 8 Aug 2017, Brandon Williams wrote:
>
> > On 08/08, Stefan Beller wrote:
> > > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > > wrote:
> > > >
> > > > On Mon, 7 Aug 2017, Brandon Williams
Olga Telezhnaya writes:
> Simplify mru.c, mru.h and related code by reusing the double-linked list
> implementation from list.h instead of a custom one.
An overlong line (I can locally wrap it, so the patch does not have
to be re-sent only to fix this alone).
>
"Eric Rannaud" writes:
> +# The commands in input_file should not produce any output on the file
> +# descriptor set with --cat-blob-fd (or stdout if unspecified).
Thanks for documenting this. Swapping the order of starting
fast-import and feeding its input (which is one
Simplify mru.c, mru.h and related code by reusing the double-linked list
implementation from list.h instead of a custom one.
Signed-off-by: Olga Telezhnaia
Mentored-by: Christian Couder
Mentored by: Jeff King
---
From: Cooper, Kathy
Sent: Thursday, September 28, 2017 3:14 AM
Subject: Business Opportunity
Hello friend,
I have a business opportunity that will benefit us millions of United State
Dollars. If you are interested, Please reply-to my personal email:
On Wed, Sep 27, 2017 at 11:02 PM, Junio C Hamano wrote:
> Eric Rannaud writes:
>
>> Doesn't fast-import get a copy of 8 (open for both reading and
>> writing), as a child process, and exec 8>&- only closes the copy of
>> the file descriptor in the parent
Eric Rannaud writes:
> Doesn't fast-import get a copy of 8 (open for both reading and
> writing), as a child process, and exec 8>&- only closes the copy of
> the file descriptor in the parent shell, so the named pipe remains
> open for writing somewhere (in the fast-import
56 matches
Mail list logo