On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
> > 2fa233a554 builtin/pack-objects.c 1512) hashcpy(base_oid.hash,
> > base_sha1);
> > 2fa233a554 builtin/pack-objects.c 1513) if
> > (!in_same_island(>idx.oid, _oid))
> > 2fa233a554 builtin/pack-objects.c 1514) return 0;
>
> These
Ping?
We are at -rc0, this progress output is a new feature since v2.19.0,
and the numbers shown are still way off.
On Mon, Oct 15, 2018 at 06:54:47PM +0200, SZEDER Gábor wrote:
> On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
>
> > @@ -560,6 +563,9 @@ static int
On Sat, Nov 17, 2018 at 12:30:58PM -0800, Stefan Xenos wrote:
> > Further, I see that this document tries to suggest a proliferation of new
> > commands
>
> It does. Let me explain a bit about the reasoning behind this
> breakdown of commands. My main priority was to keep the commands as
>
The test coverage reports started mid-way through this release cycle, so
I thought it would be good to do a full review of the new uncovered code
since the last release.
I eliminated most of the uncovered code due to the following cases:
1. Code was only moved or refactored.
2. Code was
On Sun, Nov 18, 2018 at 8:58 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> As noted in
> https://public-inbox.org/git/87d0r217vr@evledraar.gmail.com/ I'm
> happy to see this implemented. I have not read this patch in much
> detail...
>
> > [...]
On Mon, Nov 19, 2018 at 12:42 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > When :(attr) was added, it supported one of the two main pathspec
> > matching functions, the one that works on a list of paths. The other
> > one works on a tree,
On Mon, Nov 19, 2018 at 12:16 PM Ævar Arnfjörð Bjarmason
wrote:
> As an aside, how do you do the inverse of matching for an attribute by
> value? I.e.:
>
> $ git ls-files | wc -l; git ls-files ':(attr:diff=perl)' | wc -l
> 3522
> 65
>
> I'd like something gives me all files that don't
On Mon, Nov 19, 2018 at 2:08 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Nov 12 2018, Duy Nguyen wrote:
>
> > On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
> >>
> >> Nguyễn Thái Ngọc Duy writes:
> >>
> >> > Since the purpose of printing this is to help disambiguate. Only do it
> >>
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index d158c8d0bf..fc84db67a1 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -854,9 +854,23 @@ test_must_be_empty () {
>
> # Tests that
On Mon, Nov 12 2018, Duy Nguyen wrote:
> On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > Since the purpose of printing this is to help disambiguate. Only do it
>> > when "--" is missing (the actual reason though is many tests check
>> > empty
On Wed, Nov 14 2018, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> It is a good idea to error out early upon seeing, say, `-Cbad`, rather
> than starting the rebase only to have the `--am` backend complain later.
>
> Let's do this.
>
> The only options accepting
On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote:
> While I don't have an HFS+ volume to test, I suspect this patch should be
> needed for both, even if I have to say thay even the broken output was
> better than the current state.
>
> Travis seems to be using a case sensitive filesystem so
On Sun, Nov 18, 2018 at 08:51:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > But this also reveals an interesting thing: even though we walk on a
> > tree, we check attributes from _worktree_ (and optionally fall back to
> > the index). This is how attributes are implemented since forever. I
> >
On Mon, Nov 19 2018, Mgr Georg Black wrote:
> Hello everyone,
> We have source codes in many files of 20 years development. It's approx
> 800mb. There are many programs. Every has about 100-200 modules.
> Company has 40 developers. They all works via terminal on aix.
> At this time we have
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
> When :(attr) was added, it supported one of the two main pathspec
> matching functions, the one that works on a list of paths. The other
> one works on a tree, tree_entry_interesting(), which gets :(attr)
> support in this series.
>
> With
On Sun, Nov 18 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> When :(attr) was added, it supported one of the two main pathspec
>> matching functions, the one that works on a list of paths. The other
>> one works on a tree, tree_entry_interesting(),
On Mon, Nov 19 2018, Carlo Marcelo Arenas Belón wrote:
> 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> 2018-07-27)
> introduced all tests but without a check for CURL support from git.
>
> Signed-off-by: Carlo Marcelo Arenas Belón
> ---
>
On Tue, Nov 13, 2018 at 06:04:15PM -0500, _g e r r y _ _l o w r y _ wrote:
> Examples:
>
> {me, extreme often, Windows} very granular, with a brief yet appropriate
> comment [like narrating a story] per commit-i change a few
> lines of code,
> Alt+Tab to Git Bash, Git Add/Commit,
> Alt+Tab
Dear
I am a contractor with shell petroleum here in the Uk and want to
invest this $104M Dollars in real estate management and part in your
company or any other area of business you know best that will be of
good profit to both of us in your country
kindly send to me your home or Office
On 2018-11-19 00:40, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>>> This needs to go on top of pu, to cover all the good stuff
>>>cooking here.
>>
>> Better to work on top of 'master', as the work in 'pu' will be
>> rewritten several times, probably.
>
> We may not be able to find any
On 2018-11-19 04:33, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
>>> Torsten Bögershausen writes:
>>>
And it may even be that we need a special handling for the "\" to be
treated as "/".
>>>
>>> I do not do Windows, but is_dir_sep() needs to be tweaked if you want to do
>>>
Stefan Xenos writes:
> The scenario you describe would not produce an origin edge in the
> metacommit graph. If the user amended X, there would be no origin
> edges - just a replacement. If you cherry-picked Z you'd get no
> replacements and just an origin. In neither case would you get both
>
Stefan Xenos writes:
>> I meant the project's history, not the meta-graph thing.
>
> In that case, we agree. The proposal suggests that "origin" should be
> reachable from the meta-graph for the cherry-picked commit, NOT the
> cherry-picked commit itself. Does that resolve our disagreement, or
> I meant the project's history, not the meta-graph thing.
In that case, we agree. The proposal suggests that "origin" should be
reachable from the meta-graph for the cherry-picked commit, NOT the
cherry-picked commit itself. Does that resolve our disagreement, or is
reachability from the
"Randall S. Becker" writes:
>> Torsten Bögershausen writes:
>>
>> > And it may even be that we need a special handling for the "\" to be
>> > treated as "/".
>>
>> I do not do Windows, but is_dir_sep() needs to be tweaked if you want to do
>> that.
>
> Heavy Cygwin user here. It is used in my
Stefan Xenos writes:
>> And the other half is that while I consider the "origin" thing is
>> unnecessary for the above reasons, having it means we need to not
>> just transfer the history reading to aa7ce555 and d664309ee (which
>> are necessary anyway while we have histories to transplant from
Sorry, that should have been uploaded with a subject starting with
[RFC PATCH v2]. I'm not sure why git send-email ignored my argument to
--subject-prefix. I'm going to try to change the subject one more
time. Please excuse me in advance if I accidentally spam the list by
sending the same email
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf Of
> Junio C Hamano
> Sent: November 18, 2018 19:07
> To: Torsten Bögershausen
> Cc: Steven Penny ; git@vger.kernel.org
> Subject: Re: Cygwin Git with Windows paths
>
> Torsten Bögershausen wri
Jeff King writes:
> And it seems we worked around this in de2f95ebed (mailmap: work around
> implementations with pure inline strcasecmp, 2013-09-12). So I don't
> think there is any blocker there.
>
> (Though of course I have no idea on other portability questions around
> _stricmp(); I'll
Nguyễn Thái Ngọc Duy writes:
> But this also reveals an interesting thing: even though we walk on a
> tree, we check attributes from _worktree_ (and optionally fall back to
> the index). This is how attributes are implemented since forever. I
> think this is not a big deal if we communicate
> Am I correct to understand that the reason why a commit object is
> (ab|re)used to represent a meta-commit is because by doing so we
> would get connectivity (i.e. fetching & pushing would transfer all
> the associated objects along) for free, and by not representing it
> as
Torsten Bögershausen writes:
> And it may even be that we need a special handling for the "\" to be treated
> as "/".
I do not do Windows, but is_dir_sep() needs to be tweaked if you
want to do that.
Derrick Stolee writes:
>> This needs to go on top of pu, to cover all the good stuff
>>cooking here.
>
> Better to work on top of 'master', as the work in 'pu' will be
> rewritten several times, probably.
We may not be able to find any good moment to update some codepaths
with deep
Stefan Xenos writes:
>> I don't think this counts as a typical modification and is probably hard to
>> detect automatically.
>
> Clever use of commands! (side: wouldn't it just be easier to just use
> git commit --amend, though?)
When an original commit is mostly an early part of a feature,
> This breaks the "git change" symmetry with "git branch", but after
> responding to other messages regarding that command, I'm starting to
> think that's not really a problem.
Sorry, I appended that sentence to the wrong paragraph. It should have
gone with the previous one that regarding the
> I don't think this counts as a typical modification and is probably hard to
> detect automatically.
Clever use of commands! (side: wouldn't it just be easier to just use
git commit --amend, though?)
Either way, I agree that there should be a way to manually create a
change graph or modify one
On Sun, Nov 18, 2018 at 10:02:02PM +0100, Sven Strickroth wrote:
> This also removes an implicit conversion from size_t (unsigned) to int
> (signed).
>
> _stricmp as well as _strnicmp are both available since VS2012.
Once upon a time we had problems with taking a function pointer of
strcasecmp
On 11/17/2018 10:11 AM, tbo...@web.de wrote:
From: Torsten Bögershausen
Currently Git users can not commit files >4Gib under 64 bit Windows,
where "long" is 32 bit but size_t is 64 bit.
Improve the code base in small steps, as small as possible.
What started with a small patch to replace
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
As noted in
https://public-inbox.org/git/87d0r217vr@evledraar.gmail.com/ I'm
happy to see this implemented. I have not read this patch in much
detail...
> [...]
> Documentation/glossary-content.txt | 2 +
> [...]
> diff --git
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
> When :(attr) was added, it supported one of the two main pathspec
> matching functions, the one that works on a list of paths. The other
> one works on a tree, tree_entry_interesting(), which gets :(attr)
> support in this series.
>
> With
On Sun, Nov 18, 2018 at 12:28 PM Torsten Bögershausen wrote:
> Thanks for testing.
> It looks as if there is more work to be done then just a simple patch.
>
> My last question for today:
> Does
>
> git clone '/cgdrive/c/my/dir'
>
> work ?
yes - these all work and resolve to same path:
git
On Sun, Nov 18, 2018 at 11:34:04AM -0600, Steven Penny wrote:
> On Sun, Nov 18, 2018 at 11:15 AM Torsten Bögershausen wrote:
> > But it may be that we need to pull in more stuff, similar to mingw,
> > to get the C: stuff working, see
> > "skip_dos_drive_prefix"
> >
> > And it may even be that we
On Sun, Nov 18, 2018 at 11:15 AM Torsten Bögershausen wrote:
> But it may be that we need to pull in more stuff, similar to mingw,
> to get the C: stuff working, see
> "skip_dos_drive_prefix"
>
> And it may even be that we need a special handling for the "\" to be treated
> as "/".
>
> If you
On Sun, Nov 18, 2018 at 10:23:19AM -0600, Steven Penny wrote:
> On Sun, Nov 18, 2018 at 9:41 AM Torsten Bögershausen wrote:
> > Thanks for the report
> > It seams as if "C:" is not recognized as an absolute path under
> > cygwin.
> > May be it should ?
> >
> > Does the following help ? (fully
On Sun, Nov 18, 2018 at 9:41 AM Torsten Bögershausen wrote:
> Thanks for the report
> It seams as if "C:" is not recognized as an absolute path under
> cygwin.
> May be it should ?
>
> Does the following help ? (fully untested)
that looks promising - but its not getting pulled in where it needs
On Sun, Nov 18, 2018 at 07:21:58AM -0800, Steven Penny wrote:
> Cygwin programs can handle Unix form paths:
>
>$ ls /var
>cache lib log run tmp
>
> and also Windows form paths:
>
>$ ls 'C:\cygwin64\var'
>cache lib log run tmp
>
> However current Cygwin Git cannot:
>
>
On Sat, Nov 17, 2018 at 06:32:33PM -0500, Denton Liu wrote:
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 106148254d..0d3db34f08 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -247,6 +247,54 @@ test_expect_success 'merge --squash c3 with c7' '
> test_cmp expect
On Sun, Nov 18 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Do you mean that you don't agree that following should always create
>> both "foo" and e.g. ".git/refs/heads/master" with the same 644
>> (-rw-rw-r--) mode:
>>
>> (
>> rm -rf /tmp/repo &&
>>
Ævar Arnfjörð Bjarmason writes:
> Do you mean that you don't agree that following should always create
> both "foo" and e.g. ".git/refs/heads/master" with the same 644
> (-rw-rw-r--) mode:
>
> (
> rm -rf /tmp/repo &&
> umask 022 &&
> git init /tmp/repo &&
> cd
Denton Liu writes:
>> I wonder if this is what you really meant to have instead:
>>
>> >else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
>> > - whence == FROM_COMMIT)
>> > - wt_status_add_cut_line(s->fp);
>> > + whence ==
Slavica Djukic writes:
>> Yes, but for that you'd need to be checking the resulting commit
>> object that represents the stash entry. It should be created under
>> the substitute identity.
> Would it be correct to check it like this:
>
> git reset &&
> >1 &&
> git add 1
Resending this without HTML enabled... sorry if you receive it twice.
> The file name and the title are in a mismatch.
Good point. However, the focus of this proposal really is supposed to
be on the underlying data structure, not just the evolve command
(which is the driving use-case for the
On Sat, Nov 17 2018, Junio C Hamano wrote:
> Christian Couder writes:
>
>> "However, as noted in those commits we'd still create the file as
>> 0600, and would just re-chmod it only if core.sharedRepository is set
>> to "true" or "all". If c
> I am not sure that we necessarily need this to be a graph. I think part
> of the problems with not being able to GC *any* of this is by this
> requirement to have it stored in a graph, rather than having mappings from
> which you could reconstruct any non-GC'ed parts of that graph, if you
>
figuration since we ran
"git var" above. Why does this test suspect that somebody in the
future may break the expectation that after running 'git add' and/or
'git stash', our committer identity may have been changed, and how
would such a breakage happen?
In previous re-roll, you suggested
Hi Stefan
On 16/11/2018 21:47, Stefan Beller wrote:
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
From: Phillip Wood
Currently diff --color-moved-ws=allow-indentation-change does not
support indentation that contains a mix of tabs and spaces. For
example in commit 546f70f377
On 16/11/2018 20:40, Stefan Beller wrote:
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
From: Phillip Wood
When running
git diff --color-moved-ws=allow-indentation-change v2.18.0 v2.19.0
cmp_in_block_with_wsd() is called 694908327 times. Of those 42.7%
return after comparing a
Jeff King writes:
> I suspect it would be less confusing if the rewrite were inverted, like:
>
> [url "gh:"]
> rewriteTo = https://github.com
> rewritePrivate
>
> [url "git://github.com"]
> rewriteTo = https://github.com
>
> where the mapping of sections to rewrite rules must be
Christian Couder writes:
> "However, as noted in those commits we'd still create the file as
> 0600, and would just re-chmod it only if core.sharedRepository is set
> to "true" or "all". If core.sharedRepository is unset or set to
> "false", the
On Sat, Nov 17, 2018 at 07:52:30AM +0100, Christian Couder wrote:
> On Fri, Nov 16, 2018 at 8:20 PM Duy Nguyen wrote:
> >
> > On Fri, Nov 16, 2018 at 8:07 PM SZEDER Gábor wrote:
> >
> > > With the default 20% threshold a new shared index is written rather
> > > frequently with our usual small
On Sat, Nov 17, 2018 at 04:46:22PM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> >> $ git request-pull HEAD^ git://foo.example.com/example | grep example
> >> ssh://bar.example.com/example
> >>
> >> I think that if we use the "principle of least surprise," insteadOf
> >>
On Fri, Nov 16, 2018 at 08:25:43PM +0100, Christian Couder wrote:
> On Fri, Nov 16, 2018 at 7:29 PM SZEDER Gábor wrote:
> >
> > On Fri, Nov 16, 2018 at 06:31:05PM +0100, Christian Couder wrote:
> > > diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> > > index 2ac47aa0e4..fa1d3d468b
On Sat, Nov 17, 2018 at 10:29 AM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > However, as noted in those commits we'd still create the file as 0600,
> > and would just re-chmod it depending on the setting of
> > core.sharedRepository. So without core.split
Christian Couder writes:
> However, as noted in those commits we'd still create the file as 0600,
> and would just re-chmod it depending on the setting of
> core.sharedRepository. So without core.splitIndex a system with
> e.g. the umask set to group writeability would work for
Jacques Bodin-Hullin writes:
> Subject: Re: [PATCH-2] Change writing style
Let's do the usual ": summary" instead. Perhaps
Subject: parse-options: lose an unnecessary space in an error message
It is obvious why it is done, so I do not see a need for any other
descriptio
Christian Couder writes:
>> > +test_expect_success POSIXPERM 'same mode for index & split index' '
>> > + git init same-mode &&
>> > + (
>> > + cd same-mode &&
>> > + test_commit A &&
>> > + test_modebits .git/index >index_mode &&
>> > +
Denton Liu writes:
> If commit.cleanup = scissors is specified, don't produce a scissors line
> if one already exists in the MERGE_MSG file.
Are we already sometimes adding a scissors line in that file? The
impression I was getting was that the change in the step 2/2 is the
only reason why
"brian m. carlson" writes:
>> $ git request-pull HEAD^ git://foo.example.com/example | grep example
>> ssh://bar.example.com/example
>>
>> I think that if we use the "principle of least surprise," insteadOf
>> rules shouldn't be applied for git-request-pull URLs.
>
> I'd like to point out a
ions of git
> +should always fill in an empty commit comment and tools like fsck should
> ignore
> +the content of the commit comment if present in a future repository version.
> +This will allow future versions of git to add metadata to the meta-commit
> +comments or tree without breaking
Jeff King writes:
> Actually, I realized there's an even simpler way to do this. Here it is.
>
> -- >8 --
> Subject: [PATCH] bundle: dup() output descriptor closer to point-of-use
>
> When writing a bundle to a file, the bundle code actually creates
> "your.bundle.lock" using our lockfile
On Fri, Nov 16, 2018 at 8:20 PM Duy Nguyen wrote:
>
> On Fri, Nov 16, 2018 at 8:07 PM SZEDER Gábor wrote:
>
> > With the default 20% threshold a new shared index is written rather
> > frequently with our usual small test-repos:
>
> Side note. Split index is definitely not meant for small repos.
On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
> So maybe we should just document this interface better. It seems one
> implicit dependency is that we expect a manpage for the tool to exist
> for --help.
Yeah, I think this really the only problematic assumption. The
On Thu, Nov 15, 2018 at 2:00 AM wrote:
> +Goals
> +-
> +Legend: Goals marked with P0 are required. Goals marked with Pn should be
> +attempted unless they interfere with goals marked with Pn-1.
> +
> +P0. All commands that modify commits (such as the normal commit --amend or
> +rebase
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
>
> From: Phillip Wood
>
> Currently diff --color-moved-ws=allow-indentation-change does not
> support indentation that contains a mix of tabs and spaces. For
> example in commit 546f70f377 ("convert.h: drop 'extern' from function
>
On 11/14/2018 7:55 PM, sxe...@google.com wrote:
From: Stefan Xenos
This document describes what an obsolescence graph for
git would look like, the behavior of the evolve command,
and the changes planned for other commands.
Thanks for putting this together!
diff --git
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
>
> From: Phillip Wood
>
> When running
>
> git diff --color-moved-ws=allow-indentation-change v2.18.0 v2.19.0
>
> cmp_in_block_with_wsd() is called 694908327 times. Of those 42.7%
> return after comparing a and b. By comparing the lengths
On 2018.11.16 03:48, Jeff King wrote:
> In a v2 smart-http conversation, the server should reply to our initial
> request with a pkt-line saying "version 2" (this is the start of the
> "capabilities advertisement"). We check for the string using
> starts_with(), but that's overly permissive (it
On 2018.11.16 03:47, Jeff King wrote:
> After making initial contact with an http server, we have to decide if
> the server supports smart-http, and if so, which version. Our rules are
> a bit inconsistent:
>
> 1. For v0, we require that the content-type indicates a smart-http
> response.
On 2018.11.16 03:44, Jeff King wrote:
[...]
> Amusingly, this does break the test you just added, because it tries to
> issue an ERR after claiming "text/html" (and after my patch, we
> correctly fall back to dumb-http).
Heh yeah, I copied the script from a dumb-http test without reading the
On 2018.11.16 11:45, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> >> What I was alludding to was a lot simpler, though. An advert string
> >> "version=0:version=1" from a client that prefers version 0 won't be
> >> !strcmp("version=0", advert) but seeing many strcmp() in the patch
> >>
On Fri, Nov 16, 2018 at 7:29 PM SZEDER Gábor wrote:
>
> On Fri, Nov 16, 2018 at 06:31:05PM +0100, Christian Couder wrote:
> > diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> > index 2ac47aa0e4..fa1d3d468b 100755
> > --- a/t/t1700-split-index.sh
> > +++ b/t/t1700-split-index.sh
> >
On Fri, Nov 16 2018, SZEDER Gábor wrote:
> On Fri, Nov 16, 2018 at 06:31:05PM +0100, Christian Couder wrote:
>> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
>> index 2ac47aa0e4..fa1d3d468b 100755
>> --- a/t/t1700-split-index.sh
>> +++ b/t/t1700-split-index.sh
>> @@ -381,6
On Fri, Nov 16 2018, Michael Haggerty wrote:
> On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
> wrote:
>> [...]
>> A follow-up on this: We should really fix this for other
>> reasons. I.e. compile in some "this is stuff we ourselves think is in
>> git".
>>
>> There's other
On Fri, Nov 16, 2018 at 8:07 PM SZEDER Gábor wrote:
>
> On Fri, Nov 16, 2018 at 06:41:43PM +0100, Christian Couder wrote:
> > On Tue, Nov 13, 2018 at 6:34 PM Ævar Arnfjörð Bjarmason
> > wrote:
>
> > > I'm asking whether the bug in this patch isn't revealing an existing
> > > issue with us not
On Fri, Nov 16, 2018 at 8:10 PM Christian Couder
wrote:
>
> On Fri, Nov 16, 2018 at 7:03 PM Duy Nguyen wrote:
> >
> > On Fri, Nov 16, 2018 at 6:31 PM Christian Couder
> > wrote:
> > > diff --git a/read-cache.c b/read-cache.c
> > > index 8c924506dd..ea80600bff 100644
> > > --- a/read-cache.c
> >
he: use shared perms when writing shared index", 2017-06-25)
and 3ee83f48e5 ("t1700: make sure split-index respects
core.sharedrepository", 2017-06-25).
However, as noted in those commits we'd still create the file as 0600,
and would just re-chmod it depending on the setting of
On Fri, Nov 16, 2018 at 06:41:43PM +0100, Christian Couder wrote:
> On Tue, Nov 13, 2018 at 6:34 PM Ævar Arnfjörð Bjarmason
> wrote:
> > I'm asking whether the bug in this patch isn't revealing an existing
> > issue with us not having any tests for N number of sharedindex.*
> > files. I.e. we
On Fri, Nov 16, 2018 at 3:04 AM Phillip Wood wrote:
>
> From: Phillip Wood
>
> Most of the documentation uses 'whitespace' rather than 'white space'
> or 'white spaces' convert to latter two to the former for consistency.
Makes sense; this doesn't touch docs, but also code.
$ git grep "white
On Fri, Nov 16, 2018 at 06:31:05PM +0100, Christian Couder wrote:
> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> index 2ac47aa0e4..fa1d3d468b 100755
> --- a/t/t1700-split-index.sh
> +++ b/t/t1700-split-index.sh
> @@ -381,6 +381,26 @@ test_expect_success 'check
On Fri, Nov 16, 2018 at 6:31 PM Christian Couder
wrote:
> diff --git a/read-cache.c b/read-cache.c
> index 8c924506dd..ea80600bff 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -3165,7 +3165,8 @@ int write_locked_index(struct index_state *istate,
> struct lock_file *lock,
>
On Tue, Nov 13, 2018 at 6:34 PM Ævar Arnfjörð Bjarmason
wrote:
>
> On Tue, Nov 13 2018, Duy Nguyen wrote:
>
> > On Tue, Nov 13, 2018 at 4:32 PM Ævar Arnfjörð Bjarmason
> > wrote:
> > I don't have any bright idea how to catch the literal _X file.
> > It's a temporary file and will not last
On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
wrote:
> [...]
> A follow-up on this: We should really fix this for other
> reasons. I.e. compile in some "this is stuff we ourselves think is in
> git".
>
> There's other manifestations of this, e.g.:
>
> git-sizer --help # => shows
Hi Peff,
On Fri, 16 Nov 2018, Jeff King wrote:
> On Thu, Nov 15, 2018 at 09:01:07PM +0100, Johannes Schindelin wrote:
>
> > > It seems like we should be checking that the stale lockfile isn't left,
> > > which is the real problem (the warning is annoying, but is a symptom of
> > > the same
epo) and "objectname:short" (which currently segfaults).
>
> Arguably, use of ref-filter machinery in ls-remote, whether it is
> given from inside or outside a repo, was a mistake in 1fb20dfd
> ("ls-remote: create '--sort' option", 2018-04-09), as the whole
> point
On 11/13/2018 7:12 PM, Stefan Beller wrote:
Please have a look at the last 4 patches specifically as they were new in
the last iteration (but did not receive any comment), as they demonstrate
and fix a problem that is only exposed when using GIT_TEST_COMMIT_GRAPH=1
for the test suite.
I took a
Hi Mikhail,
On Mon, 17 Sep 2018, Mikhail Matrosov wrote:
> Please try the following:
>
> mmatrosov@Mikhail-PC:~/test$ git init --bare server
> Initialized empty Git repository in /home/mmatrosov/test/server/
> mmatrosov@Mikhail-PC:~/test$ git clone server local
> Cloning into 'local'...
>
On Thu, Nov 15, 2018 at 11:59:56PM -0800, Elijah Newren wrote:
> diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
> index d7d73061d0..5690fe2810 100755
> --- a/t/t9350-fast-export.sh
> +++ b/t/t9350-fast-export.sh
> @@ -77,6 +77,23 @@ test_expect_success 'fast-export
>
On Thu, Nov 15, 2018 at 01:28:26PM -0500, Konstantin Ryabitsev wrote:
> Hi, all:
>
> Looks like setting url.insteadOf rules alters the output of
> git-request-pull. I'm not sure that's the intended use of insteadOf,
> which is supposed to replace URLs for local use, not to expose them
> publicly
Josh Steadmon writes:
>> This one unfortunately seems to interact rather badly with your
>> js/remote-archive-v2 topic which is already in 'next', when this
>> topic is merged to 'pu', and my attempt to mechanically resolve
>> conflicts breaks t5000.
>
> Hmm, should we drop js/remote-archive-v2
On Fri, Nov 02 2018, Ævar Arnfjörð Bjarmason wrote:
> I think up to patch 4 here should be near a state that's ready for
> inclusion.
>
> Although I'm on the fence with the approach in 1/5. Should this be a
> giant getopt switch statement like that in a helper script? An
> alternative would be
801 - 900 of 100366 matches
Mail list logo
