On Mon, Apr 22, 2019 at 7:53 PM Jonathan Tan wrote:
>
> > * jt/fetch-cdn-offload (2019-03-12) 9 commits
> > - SQUASH???
> > - upload-pack: send part of packfile response as uri
> > - fetch-pack: support more than one pack lockfile
> > - upload-pack: refactor reading of pack-objects out
> > -
On Mon, Apr 22, 2019 at 10:51:04AM -0700, Jonathan Tan wrote:
> > * jt/fetch-cdn-offload (2019-03-12) 9 commits
> [...]
>
> Sorry for getting back to you late on this. The current status is that
> v2 (this version) looks good to me, except that not many people seems to
> be interested in this - I
On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
> +If the 'packfile-uris' feature is advertised, the following argument
> +can be included in the client's request as well as the potential
> +addition of the 'packfile-uris' section in the server's response as
> +explained below.
> +
>
On Fri, Mar 08, 2019 at 01:55:12PM -0800, Jonathan Tan wrote:
> Here's my current progress - the only thing that is lacking is more
> tests, maybe, so I think it's ready for review.
A bit belated, but here are some overall thoughts. A lot of my thinking
comes from comparing this to previous work
Commit 05eb1c37ed (perf/aggregate: implement codespeed JSON output,
2018-01-05) added a dependency on the perl JSON module to show output
from aggregate.perl, but we only need it when the user asks for
--codespeed output. While the module is pretty common, it's not part of
the base system, and this
On Mon, Apr 22, 2019 at 09:55:38PM -0400, Jeff King wrote:
> Here are my p5302 numbers on linux.git, by the way.
>
> Test jk/p5302-repeat-fix
> --
> 5302.2: index-pack 0 threads
On Tue, Apr 23, 2019 at 12:45:17PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... I don't think it would be
> > too big a problem for format-patch to learn some options to configure
> > its diffs. We already have some options in format.* for various things.
>
> I am not sure; diff.c
Jeff King writes:
> ... I don't think it would be
> too big a problem for format-patch to learn some options to configure
> its diffs. We already have some options in format.* for various things.
I am not sure; diff.context is rather special in that the variable
behind it belongs to the diff lay
On Sat, Feb 02, 2019 at 01:33:22PM +0100, Jakub Narebski wrote:
> I have noticed a little 'recording' indicator; would recorded session
> (video or audio only) be made available at some point in time? Did
> anyone take minutes, or take notes (for example of the Summit agenda
> created at the star
On Sun, Apr 14, 2019 at 04:48:53PM -0500, Shawn Landden wrote:
> When I send patches I want them to have lots of context, but when just
> looking at a diff, I can always open the file for context.
Seems like a reasonable thing to want. You can already use "git
format-patch -U20 ...". The usual ad
On Tue, Apr 23, 2019 at 11:45:17AM +0900, Junio C Hamano wrote:
> I have been seeing occasional failures of t5504-fetch-receive-strict
> test on the cc/replace-graft-peel-tags topic, but it seems that the
> fork point of that topic from the mainline already fails the same
> step #8, only less freq
I have been seeing occasional failures of t5504-fetch-receive-strict
test on the cc/replace-graft-peel-tags topic, but it seems that the
fork point of that topic from the mainline already fails the same
step #8, only less frequently.
The push is rejected as expected, but the remote side that recei
Jeff King writes:
> Is it? I thought the issue was specifically when there were spaces. I
> get:
>
> $ bash
> $ file=ok
> $ echo foo >$file
> $ file='not ok'
> $ echo foo >$file
> bash: $file: ambiguous redirect
OK, so I misremembered. Then we are good. Thanks.
On Tue, Apr 23, 2019 at 11:27:02AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> This is obviously inherited from the original, but do we get scolded
> >> by some versions of bash for this line, without quoting the source path
> >> of the redirection, i.e.
> >>
> >>... --stdin <"$
Jeff King writes:
>> This is obviously inherited from the original, but do we get scolded
>> by some versions of bash for this line, without quoting the source path
>> of the redirection, i.e.
>>
>> ... --stdin <"$PACK"
>
> In general, yes, but I think we are OK in this instance because we
On Mon, Apr 22, 2019 at 6:21 PM Junio C Hamano wrote:
>
> Phillip Wood writes:
>
> > Doing "git rebase -i master" and then editing the todo list has the
> > side effect of rebasing the branch. Often I find I want to amend or
> > reword a commit without rebasing (for instance when preparing a
> >
On Mon, Apr 22, 2019 at 11:07:01PM +, brian m. carlson wrote:
> On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:
> > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:
> >
> > > > In some ways I'm less concerned about verify-tag, though, because the
> > > > point
On Tue, Apr 23, 2019 at 10:09:54AM +0900, Junio C Hamano wrote:
> The above is very cleanly written to convince anybody that what the
> current test does contradicts with wish #2 above, and that the two
> wishes #1 and #2 are probably mutually incompatible.
>
> But isn't the collision check a par
On Mon, Apr 22, 2019 at 04:32:16PM -0600, Martin Fick wrote:
> > Hours? I think something might be wrong. It takes 20s to run on
> > linux.git.
>
> OK, yes I was running this on a "bad" copy of the repo, see below because I
> think it might be of some interest also...
>
> On the better copy, th
Jeff King writes:
> We could fix it by adding a "+" before the sub-list to connect it to the
> rest of the "-t" text. But using a pair of "--" to delimit the block is
> perhaps more readable, and may have better compatibility with
> asciidoctor, as in 39a869b2f2 (Documentation/rev-list-options: w
Phillip Wood writes:
> Doing "git rebase -i master" and then editing the todo list has the
> side effect of rebasing the branch. Often I find I want to amend or
> reword a commit without rebasing (for instance when preparing a
> re-roll).
I am not sure what you mean by "not rebasing". Are you t
Ramsay Jones writes:
>> FWIW, after reading your commit message my thoughts immediately turned
>> to "why can't ls-files have a mode that outputs each just once", but
>> then ended up at the same place as your patch: it's not that hard to
>> just de-dup the output.
>
> My immediate thought was "t
Jeff King writes:
> Subject: [PATCH] p5302: create the repo in each index-pack test
>
> The p5302 script runs "index-pack --stdin" in each timing test. It does
> two things to try to get good timings:
>
> 1. we do the repo creation in a separate (non-timed) setup test, so
> that our timing
On Mon, Apr 22, 2019 at 07:26:29PM -0400, Santiago Torres Arias wrote:
> On Mon, Apr 22, 2019 at 11:07:01PM +, brian m. carlson wrote:
> > On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:
> > > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:
> > >
> > > > I thi
On Mon, Apr 22, 2019 at 11:07:01PM +, brian m. carlson wrote:
> On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:
> > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:
> >
> > > I think that would be great, as we could make it simpler for verifiers
> > > to parse
On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:
> On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:
>
> > > In some ways I'm less concerned about verify-tag, though, because the
> > > point is that it should be scriptable. And scraping gpg's stderr is not
> > > idea
On Monday, April 22, 2019 4:56:54 PM MDT Jeff King wrote:
> On Mon, Apr 22, 2019 at 02:21:40PM -0600, Martin Fick wrote:
> > > Try this (with a recent version of git; your v1.8.2.1 won't have
> > >
> > > --batch-all-objects):
> > > # count the on-disk size of all objects
> > > git cat-file --b
From: Michael Platings
Hi Barret,
This patch is on top of your patch v6 4/6.
Previously I pointed out that my code couldn't handle this case correctly:
Before:
commit-a 11) Position MyClass::location(Offset O) {
commit-b 12)return P + O;
commit-c 13) }
After:
On Sun, Apr 21, 2019 at 3:52 AM Junio C Hamano wrote:
>
> Emily Shaffer writes:
>
> > This tutorial covers how to add a new command to Git and, in the
> > process, everything from cloning git/git to getting reviewed on the
> > mailing list. It's meant for new contributors to go through
> > intera
On Wed, Apr 17, 2019 at 12:58:31AM -0700, Denton Liu wrote:
> Thanks for the feedback. I couldn't find a tool that could selectively
> fix indentation on patches so I went through and manually realigned the
> parameter lists wherever the tools mangled the alignment. I guess this
> also implies th
On Fri, Apr 19, 2019 at 02:00:13PM -0700, Josh Steadmon wrote:
> For partial clones, doing a full connectivity check is wasteful; we skip
> promisor objects (which, for a partial clone, is all known objects), and
> enumerating them all to exclude them from the connectivity check can
> take a signi
On Mon, Apr 22, 2019 at 04:56:53PM -0400, Jeff King wrote:
> > I am running some index packs to test the theory, I can tell you already
> > that
> > the 56 thread versions was much slower, it took 397m25.622s. I am running a
> > few other tests also, but it will take a while to get an answer. S
On Mon, Apr 22, 2019 at 04:56:54PM -0400, Jeff King wrote:
> > I suspect at 3 threads, seems like the default?
>
> Ah, right, I forgot we cap it at 3 (which was determined experimentally,
> and which we more or less attributed to lock contention as the
> bottleneck). I think you need to use $GIT_
On Mon, Apr 22, 2019 at 02:21:40PM -0600, Martin Fick wrote:
> > Try this (with a recent version of git; your v1.8.2.1 won't have
> > --batch-all-objects):
> >
> > # count the on-disk size of all objects
> > git cat-file --batch-all-objects --batch-check='%(objectsize)
> > %(objectsize:disk)'
On Friday, April 19, 2019 11:58:25 PM MDT Jeff King wrote:
> On Fri, Apr 19, 2019 at 03:47:22PM -0600, Martin Fick wrote:
> > I have been thinking about this problem, and I suspect that this compute
> > time is actually spent doing SHA1 calculations, is that possible? Some
> > basic back of the env
Hi Phil,
On Mon, Apr 22, 2019 at 12:20:29PM -0700, Phil Hord wrote:
> On Mon, Apr 22, 2019 at 12:16 PM Phil Hord wrote:
> >
> > I have the same need. I plan to have some switch that invokes this
> > "in-place rebase" behavior so that git can choose the upstream for me
> > as `mergebase $sequence
On Tue, Mar 19, 2019 at 09:05:49AM +, REIX, Tony wrote:
> When testing version 2.21.0 of git on AIX (6.1 & 7.2), I have found an
> issue with daemon.c and test t5570-git-daemon.sh : within test 4, the
> child_handler() code gets crazy and calls itself recursively till the
> process crashes. We
On Wed, Jan 16, 2019 at 01:09:03PM -0600, Cameron Steffen wrote:
> I have this feature idea for git. There should be a command that
> effectively combines git add -p and git checkout -p so that I can
> navigate changed hunks and either stage or discard them.
>
> There is already a SO question ask
On Mon, Apr 22, 2019 at 12:16 PM Phil Hord wrote:
>
> I have the same need. I plan to have some switch that invokes this
> "in-place rebase" behavior so that git can choose the upstream for me
> as `mergebase $sequence-edits`. In fact, I want to make that the
> default for these switches, but th
On Mon, Apr 22, 2019 at 7:44 AM Phillip Wood wrote:
> Doing "git rebase -i master" and then editing the todo list has the side
> effect of rebasing the branch. Often I find I want to amend or reword a
> commit without rebasing (for instance when preparing a re-roll). To do
> this I use a script th
On Mon, Apr 22, 2019 at 08:01:15PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Your patch is optionally removing the "woah, we got an object with a
> > duplicate sha1, let's check that the bytes are the same in both copies"
> > check. But Martin's problem is a clone, so we wouldn't have any existing
Hi Jeff,
On Mon, Apr 22, 2019 at 02:18:36PM -0400, Jeff Hostetler wrote:
>
>
> On 4/22/2019 1:07 AM, Denton Liu wrote:
> >In git-difftool.txt, it says
> >
> > 'git difftool' falls back to 'git mergetool' config variables when the
> > difftool equivalents have not been defined.
> >
> >How
On 22/04/2019 18:51, Jonathan Tan wrote:
>> * jt/fetch-cdn-offload (2019-03-12) 9 commits
>> - SQUASH???
>> - upload-pack: send part of packfile response as uri
>> - fetch-pack: support more than one pack lockfile
>> - upload-pack: refactor reading of pack-objects out
>> - Documentation: ad
On 4/22/2019 1:07 AM, Denton Liu wrote:
In git-difftool.txt, it says
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
However, when `diff.guitool` is missing, it doesn't fallback to
anything. Make git-difftool
On Mon, Apr 22 2019, Jeff King wrote:
> On Sat, Apr 20, 2019 at 09:59:12AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > If you don't mind losing the collision-detection, using openssl's sha1
>> > might help. The delta resolution should be threaded, too. So in _theory_
>> > you're using 66 minute
On Sun, Apr 21, 2019 at 6:13 PM Junio C Hamano wrote:
>
> Phil Hord writes:
>
> > Currently it supports these switches:
> >
> > usage: git rebase [-i] [options] [--exec ] ...
> >:
> > --break stop before the mentioned ref
> > --drop drop the mentioned ref from the tod
> * jt/fetch-cdn-offload (2019-03-12) 9 commits
> - SQUASH???
> - upload-pack: send part of packfile response as uri
> - fetch-pack: support more than one pack lockfile
> - upload-pack: refactor reading of pack-objects out
> - Documentation: add Packfile URIs design doc
> - Documentation: ord
On Mon, Apr 22 2019, Andrew Janke wrote:
> On 4/21/19 8:35 PM, Duy Nguyen wrote:
>> On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke wrote:
>>>
>>> Hi, Git folks,
>>>
>>> This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.
>>
>> This says the problem with "en" detection has been
On 22/04/2019 15:49, Jeff King wrote:
> On Sun, Apr 21, 2019 at 10:19:04PM +0900, Junio C Hamano wrote:
>
>>I am not fan of adding the "| sort -u" of the whole thing,
>>because there is no need to dedup the output of the $(FIND) side
>>of the alternative, but "(ls-files | sort -u) |
On Sat, Apr 13, 2019 at 10:21:36AM +0100, Klaus Ethgen wrote:
> Finally, the error was a combination of 4 tools, git, vim, the mentioned
> vim-addon and task with a task-hook for committing pending.data.
>
> When I do a git commit which invokes vim, then the following variables
> are set:
> - GIT
https://twitter.com/account/send_password_reset?sfns=mo
“< asawaqoh...@icloud.com >”
“ tonyomont...@gmail.com.org “
“ reyesapriljo...@gmail.com.org “
“ gabriel...@gmail.com.org “
On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:
> > In some ways I'm less concerned about verify-tag, though, because the
> > point is that it should be scriptable. And scraping gpg's stderr is not
> > ideal there. We should be parsing --status-fd ourselves and making the
>
On Sat, Apr 20, 2019 at 09:59:12AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > If you don't mind losing the collision-detection, using openssl's sha1
> > might help. The delta resolution should be threaded, too. So in _theory_
> > you're using 66 minutes of CPU time, but that should only take 1-2
>
On Mon, Apr 22, 2019 at 11:28:42AM -0400, Jeff King wrote:
> On Mon, Apr 22, 2019 at 10:52:38AM -0400, Santiago Torres Arias wrote:
> > Hi,
> >
> > This is the second what's cooking that's gone by without mention of the
> > RFC patch regarding verify_tag[1]. Is this due to lack of interest or is
>
> However, I don't think this patch is quite right, as it causes us to
> dump the whole tag contents to stdout, as well. E.g.:
>
> [before]
> $ git tag -v --format='foo %(tag)' v2.21.0
> foo v2.21.0
>
> [after]
> $ git tag -v --format='foo %(tag)' v2.21.0
> object 8104ec994ea3849a968b
On Mon, Apr 22, 2019 at 10:52:38AM -0400, Santiago Torres Arias wrote:
> On Mon, Apr 22, 2019 at 03:10:30PM +0900, Junio C Hamano wrote:
> > Here are the topics that have been cooking. Commits prefixed with
> > '-' are only in 'pu' (proposed updates) while commits prefixed with
> > '+' are in 'ne
On Fri, Apr 12, 2019 at 04:14:32PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> On the git tag -v code, there is a guard to suppress gpg output if a
> pretty format is provided. The rationale for this is that the gpg output
> *and* the pretty formats together may conflict with each
The description for the "-t" option contains a sub-list of all of the
possible file status outputs. But because of the newline separating that
list from the description paragraph, asciidoc treats the sub-list
entries as a continuation of the overall options list, rather than as
children of the "-t"
On 22/04/2019 00:38, Junio C Hamano wrote:
"brian m. carlson" writes:
It may be helpful to point out that this is essentially the workflow I
had ...
I'm not sure if this email is an argument for or against this option,
but maybe it provides some helpful perspective.
I think you and Philli
On Mon, Apr 22, 2019 at 03:10:30PM +0900, Junio C Hamano wrote:
> 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 branche
On Sun, Apr 21, 2019 at 10:19:04PM +0900, Junio C Hamano wrote:
>I am not fan of adding the "| sort -u" of the whole thing,
>because there is no need to dedup the output of the $(FIND) side
>of the alternative, but "(ls-files | sort -u) || (find)" would
>obviously not work. If we
On 22/04/2019 02:13, Junio C Hamano wrote:
Phil Hord writes:
Currently it supports these switches:
usage: git rebase [-i] [options] [--exec ] ...
:
--break stop before the mentioned ref
--drop drop the mentioned ref from the todo list
--edit edit the
On Mon, Apr 22, 2019 at 7:23 PM Nguyễn Thái Ngọc Duy wrote:
> @@ -574,6 +615,70 @@ static int show_gitcomp(struct parse_opt_ctx_t *ctx,
> return PARSE_OPT_COMPLETE;
> }
>
> +/*
> + * Scan and may produce a new option[] array, which should be used
> + * instead of the original 'options'.
>
Change the option parsing machinery so that e.g. "clone --recurs ..."
doesn't error out because "clone" understands both "--recursive" and
"--recurse-submodules" to mean the same thing.
Initially "clone" just understood --recursive until the
--recurses-submodules alias was added in ccdd3da652 ("cl
Denton Liu writes:
>> > -'{tilde}', e.g. 'master{tilde}3'::
>> > +'{tilde}[]', e.g. 'HEAD~, master{tilde}3'::
>>
>> Why doesn't this example say "HEAD{tilde}, master{tilde}3" instead,
>> I wonder?
>
> According to the doc-diff, it doesn't really make a difference:
I was wondering if "HEAD{tilde
Junio C Hamano writes:
> Denton Liu writes:
>
>> After merging 'dl/no-extern-in-func-decl' into 'pu', it seems like the
>> conflict resolution mostly went well except for one spot, which this
>> patch should fix.
>
> I do not think this is a mismerge per-se.
I looked at the merge again, and I a
BOMPARD CORENTIN p1603631 writes:
> Add the --set-upstream option to git pull/fetch
Add _a_?
> which lets the user set the upstream configuration
> (branch..merge and
> branch..remote) for the current branch.
>
> For example a typical use-case like
I don't understand this sentence. Perhaps
A
From: Corentin Bompard
Add new argument which permits stripspace to escape backslashes
in order to have commit messages which begins with commentChars
and backslashes.
Add new function strbuf_addbackslash which adds a backslash before
commentChars and other backslashes used by git commit --amend
On Mon, Apr 22, 2019 at 1:14 PM Denton Liu wrote:
>
> In revisions.txt, the '^' form is mentioned but the '~' form
> is missing. Although both forms are essentially equivalent (they each
> get the first parent of the specified revision), we should mention the
> latter for completeness. Make this c
Hi Eric,
On Mon, Apr 22, 2019 at 03:07:25AM -0400, Eric Sunshine wrote:
> On Mon, Apr 22, 2019 at 1:07 AM Denton Liu wrote:
> > [...]
> > Rewrite `get_merge_tool` to return whether or not the tool was guessed
> > and make git-mergetool call this function instead of duplicating the
> > logic. Also
On Mon, Apr 22, 2019 at 03:32:21PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > @@ -139,7 +139,9 @@ thing no matter the case.
> >'{caret}0' means the commit itself and is used when '' is the
> >object name of a tag object that refers to a commit object.
> >
> > -'{tilde}', e.
On Mon, Apr 22, 2019 at 1:07 AM Denton Liu wrote:
> [...]
> Rewrite `get_merge_tool` to return whether or not the tool was guessed
> and make git-mergetool call this function instead of duplicating the
> logic. Also, let `$GIT_MERGETOOL_GUI` be set to determine whether or not
> the guitool will be
On Mon, Apr 22, 2019 at 1:07 AM Denton Liu wrote:
> In git-difftool, these options specify which tool to ultimately run. As
> a result, they are logically conflicting. Explicitly disallow these
> options from being used together.
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/builtin/difftool
73 matches
Mail list logo
