Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: finance.incapi...@hotmail.com

Re: git signed push server-side

Jonathan Nieder writes: > I think respecting gpg.program would be nicer. Is there a reason not > to do that? > > I suspect receive-pack just forgot to call git_gpg_config. That would be a good change. > How is the keyring configured for other commands that use GPG, like >

Re: git signed push server-side

Jonathan Nieder writes: > +Dave Borowitz, who implemented push cert handling in JGit and Gerrit > Hi Ian, > > Ian Jackson wrote[1]: > >> I have been investigating git signed pushes. I found a number of >> infelicities in the server side implementation which make using this

Re: cat-file timing window on Cygwin

On 25/08/17 16:08, Jeff King wrote: > On Fri, Aug 25, 2017 at 12:25:29PM +0100, Adam Dinwoodie wrote: > >> As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters >> in batch mode"), t8010-cat-file-filters.sh has been failing on Cygwin. >> Digging into this, the test looks to

Re: git signed push server-side

+Dave Borowitz, who implemented push cert handling in JGit and Gerrit Hi Ian, Ian Jackson wrote[1]: > I have been investigating git signed pushes. I found a number of > infelicities in the server side implementation which make using this > in practice rather difficult. I'm emailing here

Re: git signed push server-side

Ian Jackson writes: > I have been investigating git signed pushes. I found a number of > infelicities in the server side implementation which make using this > in practice rather difficult. I'm emailing here (before writing > patches) to see what people think

git signed push server-side

I have been investigating git signed pushes. I found a number of infelicities in the server side implementation which make using this in practice rather difficult. I'm emailing here (before writing patches) to see what people think of my proposed changes. 1. PUSH_CERT_KEY has truncated keyid

Re: [PATCH v5 35/40] Add Documentation/technical/external-odb.txt

On Fri, 25 Aug 2017 08:14:08 +0200 Christian Couder wrote: > As Git is used by more and more by people having different needs, I > think it is not realistic to expect that we can optimize its object > storage for all these different needs. So a better strategy is to

Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: finance.incapi...@hotmail.com

Re: [PATCH] usage_with_options: omit double new line on empty option list

Stefan Beller writes: > Upon closer inspection, I have the impression that f389c808b6 > (Rework make_usage to print the usage message immediately, > 2007-10-14) introduced the extra new line without giving a rationale. I do not think that is the case. The code before that

Re: [PATCH] usage_with_options: omit double new line on empty option list

On Fri, Aug 25, 2017 at 1:27 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Currently the worktree command gives its usage, when no subcommand is >> given. However there are no general options, all options are related to >> the subcommands itself,

Re: [PATCH 1/2] refs/files-backend: duplicate strings added to affected_refnames

Martin Ågren writes: > files_transaction_prepare() and the functions it calls add strings to a > string list without duplicating them, i.e., we keep the original raw > pointers we were given. That is "ok", since we keep them only for a > short-enough time, but we end up

Re: [GSoC][PATCH v3 0/4] Incremental rewrite of git-submodules

Stefan Beller writes: > On Fri, Aug 25, 2017 at 11:51 AM, Junio C Hamano wrote: >> Thanks. I'll try to queue these before I'll go offline. >> >> Mentors may want to help the student further in adjusting the patch >> series to the more recent codebase;

Re: [PATCH] usage_with_options: omit double new line on empty option list

Stefan Beller writes: > Currently the worktree command gives its usage, when no subcommand is > given. However there are no general options, all options are related to > the subcommands itself, such that: > > #$ git worktree > #usage: git worktree add [] [] > #

Re: [PATCH/RFC] push: anonymize URL in error output

On 08/24, Ivan Vyshnevskyi wrote: > On 23/08/17 18:58, Jeff King wrote: > > On Wed, Aug 23, 2017 at 12:49:29PM +0300, Ivan Vyshnevskyi wrote: > > > >> Commits 47abd85 (fetch: Strip usernames from url's before storing them, > >> 2009-04-17) and later 882d49c (push: anonymize URL in status output,

[PATCH] usage_with_options: omit double new line on empty option list

Currently the worktree command gives its usage, when no subcommand is given. However there are no general options, all options are related to the subcommands itself, such that: #$ git worktree #usage: git worktree add [] [] # or: git worktree list [] # or: git worktree

Re: [GSoC][PATCH v3 0/4] Incremental rewrite of git-submodules

On Fri, Aug 25, 2017 at 11:51 AM, Junio C Hamano wrote: > Thanks. I'll try to queue these before I'll go offline. > > Mentors may want to help the student further in adjusting the patch > series to the more recent codebase; unfortunately the area the GSoC > project touches is

[PATCH 2/2] apply: remove epoch date from regex

We check the date of epoch timestamp candidates already with starts_with(). Move beyond that part using skip_prefix() instead of checking it again using a regular expression. Also group the minutes part, so that we can access them using a substring match instead of using a magic number.

[PATCH 1/2] apply: check date of potential epoch timestamps first

has_epoch_timestamp() looks for time stamps that amount to either 1969-12-31 24:00 or 1970-01-01 00:00 after applying the time zone offset. Move the check for these two dates up, set the expected hour based on which one is found, or exit early if none of them are present, thus avoiding to engage

Re: [RFC 3/7] protocol: tell server that the client understands v2

On 08/25, Brandon Williams wrote: > On 08/25, Junio C Hamano wrote: > > Brandon Williams writes: > > > > > + /* If using a new version put that stuff here after a second > > > null byte */ > > > + strbuf_addch(, '\0'); > > > + strbuf_addf(,

Re: [RFC 3/7] protocol: tell server that the client understands v2

On 08/25, Junio C Hamano wrote: > Brandon Williams writes: > > > + /* If using a new version put that stuff here after a second > > null byte */ > > + strbuf_addch(, '\0'); > > + strbuf_addf(, "version=%d%c", 2, '\0'); > > + /*

Re: [GSoC][PATCH v3 0/4] Incremental rewrite of git-submodules

Thanks. I'll try to queue these before I'll go offline. Mentors may want to help the student further in adjusting the patch series to the more recent codebase; unfortunately the area the GSoC project touches is a bit fluid these days. I resolved the conflicts with nd/pune-in-worktree and

Re: [RFC 0/7] transitioning to protocol v2

On 08/25, Jeff King wrote: > On Fri, Aug 25, 2017 at 10:35:50AM -0700, Jonathan Nieder wrote: > > > > Sadly, while splitting these things apart makes the protocol > > > conceptually cleaner, I'm not sure if we can consider them separately > > > and avoid adding an extra round-trip to the

[PATCH 2/2] refs/files-backend: fix memory leak in lock_ref_for_update

We hand over the "referent" string (buffer) to several different functions, one of which would sometimes keep the raw pointer, referent.buf. (When split_symref_update calls string_list_insert.) The previous patch removed that behavior, so we can now safely release the string buffer before

[PATCH 1/2] refs/files-backend: duplicate strings added to affected_refnames

files_transaction_prepare() and the functions it calls add strings to a string list without duplicating them, i.e., we keep the original raw pointers we were given. That is "ok", since we keep them only for a short-enough time, but we end up leaking some of them. Switch to duplicating the

Re: [RFC 0/7] transitioning to protocol v2

Jeff King writes: > But what if we instead think of it not as "protocol v2" but as "can I > give the server some hints that it may end up ignoring", then we end up > with something more like: > > C: please run upload-pack (btw, I'm only interested in refs/heads/foo) > S:

Re: [RFC 3/7] protocol: tell server that the client understands v2

Brandon Williams writes: > + /* If using a new version put that stuff here after a second > null byte */ > + strbuf_addch(, '\0'); > + strbuf_addf(, "version=%d%c", 2, '\0'); > + /* subsequent supported versions can also be

Re: [RFC 0/7] transitioning to protocol v2

On Fri, Aug 25, 2017 at 10:35:50AM -0700, Jonathan Nieder wrote: > > Sadly, while splitting these things apart makes the protocol > > conceptually cleaner, I'm not sure if we can consider them separately > > and avoid adding an extra round-trip to the protocol. > > How about the idea of using

Re: [RFC 0/7] transitioning to protocol v2

On Fri, Aug 25, 2017 at 10:14:13AM -0700, Junio C Hamano wrote: > Stefan Beller writes: > > > For now I would suggest we put a protocol v2 in place that is > > the current protocol + a version number coming through the > > poked hole at the beginning; the goal and review of

Re: [RFC 0/7] transitioning to protocol v2

Hi, Jeff King wrote: > On Thu, Aug 24, 2017 at 03:53:21PM -0700, Brandon Williams wrote: >> Another version of Git's wire protocol is a topic that has been discussed and >> attempted by many in the community over the years. The biggest challenge, as >> far as I understand, has been coming up

Re: [PATCH] usage_with_options: omit double new line on empty option list

Stefan Beller writes: > Currently the worktree command gives its usage, when no subcommand is > given. However there are no general options, all options are related to > the subcommands itself, such that: > > $ git worktree > usage: git worktree add [] [] >

Re: [RFC 0/7] transitioning to protocol v2

On Thu, Aug 24, 2017 at 03:53:21PM -0700, Brandon Williams wrote: > Another version of Git's wire protocol is a topic that has been discussed and > attempted by many in the community over the years. The biggest challenge, as > far as I understand, has been coming up with a transition plan to

Re: [PATCH] usage_with_options: omit double new line on empty option list

Junio C Hamano writes: > Stefan Beller writes: > >> Currently the worktree command gives its usage, when no subcommand is >> given. However there are no general options, all options are related to >> the subcommands itself, such that: >> >> $ git

Re: [PATCH] usage_with_options: omit double new line on empty option list

On Fri, Aug 25, 2017 at 10:18 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> Currently the worktree command gives its usage, when no subcommand is >> given. However there are no general options, all options are related to >> the subcommands itself,

Re: [PATCH] usage_with_options: omit double new line on empty option list

Stefan Beller writes: > Currently the worktree command gives its usage, when no subcommand is > given. However there are no general options, all options are related to > the subcommands itself, such that: > > $ git worktree > usage: git worktree add [] [] >

Re: [RFC 0/7] transitioning to protocol v2

Stefan Beller writes: > For now I would suggest we put a protocol v2 in place that is > the current protocol + a version number coming through the > poked hole at the beginning; the goal and review of this series > ought to focus on getting the version handshake right... Oh,

Re: Should rerere auto-update a merge resolution?

Junio C Hamano writes: > Junio C Hamano writes: > >> Martin Langhoff writes: >> >>> - when I tell it to forget, won't it forget the pre-resolution state? >> >> I do not recall the details of what I did ;-) so I played around a

Re: [RFC 0/7] transitioning to protocol v2

On Thu, Aug 24, 2017 at 6:19 PM, Junio C Hamano wrote: > Brandon Williams writes: > >> The best way to preserve functionality with old servers and clients would be >> to >> communicate using the same end point but have the client send a bit of extra >>

Re: [PATCH v2 4/4] ThreadSanitizer: add suppressions

On Mon, Aug 21, 2017 at 07:43:48PM +0200, Martin Ågren wrote: > Add a file .tsan-suppressions and list two functions in it: want_color() > and transfer_debug(). Both of these use the pattern > > static int foo = -1; > if (foo < 0) > foo = bar(); > > where bar always

Re: Submodule regression in 2.14?

Heiko Voigt writes: > On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote: >> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote: >> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote: >> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko

[PATCH] usage_with_options: omit double new line on empty option list

Currently the worktree command gives its usage, when no subcommand is given. However there are no general options, all options are related to the subcommands itself, such that: $ git worktree usage: git worktree add [] [] or: git worktree list [] or: git worktree lock []

Re: Submodule regression in 2.14?

On Fri, Aug 25, 2017 at 2:10 AM, Heiko Voigt wrote: > On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote: >> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote: >> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote: >> >> On Mon, Aug

Re: Should rerere auto-update a merge resolution?

Johannes Schindelin writes: > In my hands, I need to tell rerere to forget, *and then recreate the merge > conflict* before I can resolve it again and let rerere learn the new > resolution. I can believe that---that is how I originally desiged "forget" to behave.

Re: Should rerere auto-update a merge resolution?

Junio C Hamano writes: > Martin Langhoff writes: > >> - when I tell it to forget, won't it forget the pre-resolution state? > > I do not recall the details of what I did ;-) so I played around a > bit. Here is what I did: > ... > After git rerere

Re: Should rerere auto-update a merge resolution?

Martin Langhoff writes: > - when I tell it to forget, won't it forget the pre-resolution state? I do not recall the details of what I did ;-) so I played around a bit. Here is what I did: git checkout master^0 git merge --no-ff --no-edit

Re: cat-file timing window on Cygwin

On Fri, Aug 25, 2017 at 12:25:29PM +0100, Adam Dinwoodie wrote: > As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters > in batch mode"), t8010-cat-file-filters.sh has been failing on Cygwin. > Digging into this, the test looks to expose a timing window: it appears > that if

Re: [PATCH] sha1-lookup: remove sha1_entry_pos() from header file

On Fri, Aug 25, 2017 at 09:36:13AM +0200, Christian Couder wrote: > Since f1068efefe (sha1_file: drop experimental GIT_USE_LOOKUP search, > 2017-08-09) > the definition of sha1_entry_pos() has been removed from "sha1-lookup.c", so > there is no need anymore for its declaration in

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote: > Hi Mike, > > On Thu, 24 Aug 2017, Mike Hommey wrote: > > > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > > > > > > On Fri, 18 Aug 2017, Jonathan Nieder wrote: > > > > > > > Mike Hommey wrote[1]: > >

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

On 24/08/17 17:46, Junio C Hamano wrote: > Phillip Wood writes: > >> It could be expensive to check that the local modifications will not >> interfere with the rebase - wouldn't it have to look at all the files >> touched by each commit before starting? What do

cat-file timing window on Cygwin

As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters in batch mode"), t8010-cat-file-filters.sh has been failing on Cygwin. Digging into this, the test looks to expose a timing window: it appears that if `git cat-file --textconv --batch` receives input on stdin too quickly, it

Re: [PATCH v4 00/16] Fix git-gc losing objects in multi worktree

Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.08.2017 14:36: > "git gc" when used in multiple worktrees ignore some per-worktree > references: object references in the index, HEAD and reflog. This > series fixes it by making the revision walker include these from all > worktrees by default (and the

Hallo lieve

Hallo lieve, mijn naam is Vivian Potter de enige dochter van Dr. Johnson Potter, ik ben 21 jaar oud, kunnen we spreken beter alstublieft. Ik heb iets te bespreken. Merci vervroegd. Miss Vivian

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

Hi Mike, On Thu, 24 Aug 2017, Mike Hommey wrote: > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > > > > On Fri, 18 Aug 2017, Jonathan Nieder wrote: > > > > > Mike Hommey wrote[1]: > > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > > > >> Mike

2

Did you get my last message? reply me through: lilianbt...@gmail.com

Re: Should rerere auto-update a merge resolution?

Hi Martin, On Wed, 23 Aug 2017, Martin Langhoff wrote: > On Wed, Aug 23, 2017 at 4:34 PM, Junio C Hamano wrote: > > Between these two steps: > > > >> - I reset hard, retry the merge, using --no-commit, rerere applies what > >> it knows > >> - I fix things up, then commit >

[PATCH v2 2/2] send-email: don't use Mail::Address, even if available

Using Mail::Address made sense when we didn't have a proper parser. We now have a reasonable address parser, and using Mail::Address _if available_ causes much more trouble than it gives benefits: * Developers typically test one version, not both. * Users may not be aware that installing

[PATCH v2 1/2] send-email: fix garbage removal after address

This is a followup over 9d33439 (send-email: only allow one address per body tag, 2017-02-20). The first iteration did allow writting Cc: # garbage but did so by matching the regex ([^>]*>?), i.e. stop after the first instance of '>'. However, it did not properly deal with

Re: Submodule regression in 2.14?

On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote: > On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote: > > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote: > >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote: > >> > On Fri,

Re: [RFC PATCH 1/2] send-email: fix garbage removal after address

Junio C Hamano writes: > Matthieu Moy writes: > >> +sub strip_garbage_one_address { >> +my ($addr) = @_; >> +chomp $addr; >> +if ($addr =~ /^(("[^"]*"|[^"<]*)? *<[^>]*>).*/) { >> +# "Foo Bar" [possibly garbage

Re: [PATCH] gitk: different color for boundary commits

Stefan Dotterweich wrote: > When using filters, the commit list shows not only commits matching > the filter criteria, but also boundary commits. When going through a > list of say, all commits changing the variable `foo`, often half of > the displayed commits are

[PATCH] sha1-lookup: remove sha1_entry_pos() from header file

Since f1068efefe (sha1_file: drop experimental GIT_USE_LOOKUP search, 2017-08-09) the definition of sha1_entry_pos() has been removed from "sha1-lookup.c", so there is no need anymore for its declaration in "sha1-lookup.h". Signed-off-by: Christian Couder ---

Re: [PATCH v5 35/40] Add Documentation/technical/external-odb.txt

On Thu, Aug 3, 2017 at 8:38 PM, Stefan Beller wrote: > On Thu, Aug 3, 2017 at 2:19 AM, Christian Couder > wrote: >> This describes the external odb mechanism's purpose and >> how it works. > > Thanks for providing this documentation patch! > > I