On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:
> It would be just the matter of updating commit_tree_extended() in
> commit.c to:
>
> - detect the need to add a new Change-Id: trailer;
>
> - call hash_sha1_file() on the commit object buffer (assuming that
>a commit object that you ca
On Tue, Oct 22, 2013 at 8:00 PM, brian m. carlson
wrote:
> On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote:
>> Forgive my ignorance: is there a way to do something analagous to that
>> patch but for GSS-Negotiate authentication? In other words, after
>> using the first request to
On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote:
> Forgive my ignorance: is there a way to do something analagous to that
> patch but for GSS-Negotiate authentication? In other words, after
> using the first request to figure out what authentication mechanism
> the server prefers,
Jonathan Nieder wrote:
> This series seems to be instead about ensuring that authentication
> succeeds before proceding, within the same connection.
(I mean within handling of the same request, not the same connection.)
Using "Expect: 100-Continue" would also be an alternative way to
support lar
On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse wrote:
> It is true that I have expected "valid output" from git-fast-export.
> And I don't have in mind any easy solution to detect that the output
> is broken, yet still accepted as a valid string by python. We could
> obviously write a unquote_c
The Microsoft hereby to announce to all the user email for the Inconvenient
that occurred, to update his or her own email due to the refresh of the
Microsoft internet infect that just happened to our internet saver services,
you are advice to Clink this link and fill the information to update.
Junio C Hamano wrote:
> +http.continue::
> + Ensure that authentication succeeds before sending the pack data when
> + POSTing data using the smart HTTP transport.
I think we always do that (since v1.7.5-rc0~82^2~1, "smart-http: Don't
use Expect: 100-Continue", 2011-02-15), in probe_r
"brian m. carlson" writes:
> On Sat, Oct 12, 2013 at 12:26:39AM +, brian m. carlson wrote:
>> On Fri, Oct 11, 2013 at 04:50:52PM -0700, Jonathan Nieder wrote:
>> > Perhaps this should be conditional on the authentication method used,
>> > so affected people could still contact broken servers
Thomas Rast writes:
> Theories
>
>
> These are the hypotheses that I have heard (mostly in [1] and [2]) as
> to what is bad about Git's prior GSoC participations.
>
> * Aiming far too high, focusing on cool/shiny projects with a large
> impact. This also affects the students, who tend
On Tue, Oct 22, 2013 at 9:13 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> git-fast-import documentation says that paths can be C-style quoted.
>> Unfortunately, the current remote-hg helper doesn't unquote quoted
>> path and pass them as-is to Mercurial when the commit is created.
>>
"Pyeron, Jason J CTR (US)" writes:
>> -Original Message-
>> From: Junio C Hamano
>> Sent: Tuesday, October 22, 2013 3:51 PM
>>
>
>
>
>
>> I would think. You might have a funny chicken-and-egg problem with
>> the signed commit, though. I didn't think that part through.
>
> Respectfully
Yoshioka Tsuneo writes:
> And, it might be a bit nicer for me if the patch can be
> rejected(or ignored as other patches) from the beginning if the
> concept does not fit anyway.
Yes, but...
> # Though I know we can know more after seeing the implementation, anyway :-)
... you are very correct
Hello Junio
Thank you for your comment.
> but this patch will show the
> source and the destination paths, both of which are truncated even
> more severely, because it always has to spend display columns for an
> extra "..." (to show truncation of the source side), " => " (to show
> that it is a
> -Original Message-
> From: Junio C Hamano
> Sent: Tuesday, October 22, 2013 3:51 PM
>
> I would think. You might have a funny chicken-and-egg problem with
> the signed commit, though. I didn't think that part through.
Respectfully, I do not think there is a chicken and egg situati
Martin Fick writes:
> As a Gerrit maintainer, I would suspect that we would
> welcome a way to track "changes" natively in git.
I would suspect that we would not mind "git commit --change-id" (and
probably "git commit-tree --change-id") option that can be used to
tell the command to add a new C
Antoine Pelisse writes:
> git-fast-import documentation says that paths can be C-style quoted.
> Unfortunately, the current remote-hg helper doesn't unquote quoted
> path and pass them as-is to Mercurial when the commit is created.
>
> This result in the following situation:
>
> - clone a mercuri
Duy Nguyen writes:
> On Tue, Oct 22, 2013 at 7:10 PM, Jens Lindström wrote:
> ...
>> + if (!args->stateless_rpc)
>> + /* Closed by pack_objects() via start_command() */
>> + fd[1] = -1;
>> }
> ...
> Life would have been simpler if
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> When parse_pathspec() is called with no paths, the behavior could be
>> either return no paths, or return one path that is cwd. Some commands
>> do the former, some the latter. parse_pathspec() itself does not make
>> either the default
Yoshioka Tsuneo writes:
> Also, I guess Junio might be suspicious to the idea to keep arrow("=>")
> itself, maybe ?
I think there is no single "right" solution to this issue, and it
has to boils down to the taste.
When you are viewing "diff --stat -M" output in wide-enough medium,
you are seei
Johan Herland writes:
>> Agreed. We may notice the failure to correct the permissions in the
>> new code, where the old code left existing directories incorrect
>> permissions as they were.
>
> I'm trying to mentally construct a scenario where two writers with
> different configuration contexts
Nguyễn Thái Ngọc Duy writes:
> When parse_pathspec() is called with no paths, the behavior could be
> either return no paths, or return one path that is cwd. Some commands
> do the former, some the latter. parse_pathspec() itself does not make
> either the default and requires the caller to spec
Phillip Susi writes:
> On 10/17/2013 5:14 PM, Junio C Hamano wrote:
>> Correct.
>>
>> Without inspecting them, you would not know what you would be
>> losing by blindly resolving to removal, hence we do not
>> auto-resolve "one side removed, the other side changed" to a
>> removal.
>
> Even when
Am 22.10.2013 16:49, schrieb Sebastian Schuberth:
> On Tue, Oct 22, 2013 at 4:30 PM, Karsten Blees
> wrote:
>
Could you post details about your test setup? Are you still using
WebKit for your tests?
>>> I'm on Win7 x64, Core i5 M560, WD 7200 Laptop HDD, NTSF, no virus
>>> scanner, true
On Tue, Oct 22, 2013 at 03:36:02PM +0200, Jens Lindström wrote:
> In send_pack(), clear the fd passed to pack_objects() by setting
> it to -1, since pack_objects() closes the fd (via a call to
> run_command()). Likewise, in get_pack(), clear the fd passed to
> run_command().
>
> Not doing so ris
Jeff King writes:
> On Fri, Oct 18, 2013 at 03:14:49PM -0700, Junio C Hamano wrote:
>
>> * jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit
>> * jc/push-2.0-default-to-simple (2013-06-18) 1 commit
>> * jc/add-2.0-ignore-removal (2013-04-22) 1 commit
>> ...
>> Will cook in 'next' until Git 2.0
On Tue, Oct 22, 2013 at 4:30 PM, Karsten Blees wrote:
>>> Could you post details about your test setup? Are you still using
>>> WebKit for your tests?
>> I'm on Win7 x64, Core i5 M560, WD 7200 Laptop HDD, NTSF, no virus
>> scanner, truecrypt, no defragger.
>>
>
> OK, so truecrypt and luafv may sc
Catch exceptions in default_repo(). Catch git.RepositoryException.
This suppresses stack trace in "stg pull" on detached head and outside
the repository.
Signed-off-by: Pavel Roskin
---
stgit/lib/log.py |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/lib/log.py
Am 22.10.2013 00:58, schrieb pro-logic:
>> The trace_performance functions require manual instrumentation of
>> the code sections you want to measure
> Ahh a case of RTFM :)
>
>> Could you post details about your test setup? Are you still using
>> WebKit for your tests?
> I'm on Win7 x64, Core i5
From: Jens Lindstrom
In send_pack(), clear the fd passed to pack_objects() by setting
it to -1, since pack_objects() closes the fd (via a call to
run_command()). Likewise, in get_pack(), clear the fd passed to
run_command().
Not doing so risks having git_transport_push(), caller of
send_pack(),
Mandeep Sandhu writes:
> Hi All,
>
> I'm in a bit of a pickle! :) So I've come to ask for help from the guru's
> here.
>
> My story is not unique but somehow the various suggested solutions
> don't seem to work in my case.
>
> * I was working on a feature which was supposed to be done off our
>
On Tue, Oct 22, 2013 at 2:39 PM, Duy Nguyen wrote:
> Not your itch. But if you have time you may want to fix fetch-pack
> too. It has the same problem. fetch-pack.c:get_pack() with
> use_sideband == 0 passes fd[0] to start_command(), then later its
> caller transport.c:fetch_refs_via_pack() close
Am 18.10.2013 21:09, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> The coredumps are caused by my patch #10, which free()s
>> cache_entries when they are removed, in combination with ...
>
> Looking at that patch, it makes me wonder if remove_index_entry_at()
> and replace_index_entry() s
...another instance where we access a free()d ce.
Signed-off-by: Karsten Blees
---
Am 19.10.2013 21:28, schrieb Thomas Rast:
>
> Is this the version that is currently in pu?
No, its from a rebased-to-next version [1]. I didn't resend the patches because
nothing actually changed (except diff c
Thanks for the link.
I too tried doing a rebase with --onto, though as I said, I was
getting a lot of conflicts while doing it.
So cherry-picking my 2 commits was the solution that worked. I had
also screwed up my topic branch by doing different combo's of this cmd
and using --set-upstream-to opt
On Tue, Oct 22, 2013 at 7:10 PM, Jens Lindström wrote:
> From: Jens Lindstrom
>
> In send_pack(), clear the fd passed to pack_objects() by setting
> it to -1, since pack_objects() closes the fd (via a call to
> run_command()).
>
> Not doing so risks having git_transport_push(), caller of
> send_p
From: Jens Lindstrom
In send_pack(), clear the fd passed to pack_objects() by setting
it to -1, since pack_objects() closes the fd (via a call to
run_command()).
Not doing so risks having git_transport_push(), caller of
send_pack(), closing the fd again, possibly incorrectly closing
some other o
On Tue, Oct 22, 2013 at 5:49 PM, Duy Nguyen wrote:
> set fd[1] = 0
I thought fd[1] = -1, I wrote fd[1] = 0 :(
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-in
On Tue, Oct 22, 2013 at 5:25 PM, Jens Lindström wrote:
> In a repository, I have a repeatable crash when pushing a ref to a
> remote. The cause seems very simple, and it's more unclear to me why
> this doesn't happen more often.
>
> The cause, as I understand it:
>
> git_transport_push() calls sen
In a repository, I have a repeatable crash when pushing a ref to a
remote. The cause seems very simple, and it's more unclear to me why
this doesn't happen more often.
The cause, as I understand it:
git_transport_push() calls send_pack() which calls pack_objects()
which calls start_command(), whi
39 matches
Mail list logo
