Æ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 == FR
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 grap
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
merge.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
Finally, w
On Sat, Nov 17, 2018 at 05:06:43PM +0900, Junio C Hamano wrote:
> 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 this becomes necessary. In which case this change
> makes no sense as a stand
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 core.sharedRepository is unset or set to
>> "false", th
> 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
> reall
Bitte bestätigen Sie meinen Vorschlag, es ist sehr dringend, ich habe
Ihr Profil gesehen und bin es
wirklich interessiert an dir, bitte antworte
Michelle
Hi Junio,
On 16-Nov-18 11:12 AM, Junio C Hamano wrote:
Slavica Djukic writes:
+ git var GIT_COMMITTER_IDENT >actual &&
+ test_cmp expected actual &&
I am not sure what you are testing with this step. There is nothing
that changed environment variables or configuration since we r
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 "unsigned long" with size_t
in one file (convert.c) e
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 ("convert
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 and
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 one-to-
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", then the file mode will not be changed, so without
> co
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 tes
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
> >> rules
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 10
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.splitIndex a system with
> > e.g.
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 the members of
> t
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
description in the body of th
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 &&
>> > + tes
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 this
23 matches
Mail list logo
