On Sat, May 04 2019, Jeff King wrote:
> On Thu, Apr 25, 2019 at 04:16:46PM +0900, Junio C Hamano wrote:
>
>> I was revisiting the recent "What's cooking" report, and I am not
>> sure what the current status of the topic is.
>>
>> I do not get a feel that the current bitmap implementation has bee
On Thu, Apr 25, 2019 at 04:16:46PM +0900, Junio C Hamano wrote:
> I was revisiting the recent "What's cooking" report, and I am not
> sure what the current status of the topic is.
>
> I do not get a feel that the current bitmap implementation has been
> widely used in repositories that have vastl
Jeffrey Walton wrote:
> On Wed, May 1, 2019 at 6:30 PM Jonathan Nieder wrote:
>> Sounds like it's using "install" when it should be using "ginstall".
>> config.mak.uname contains, under the SunOS category:
>>
>> INSTALL = /usr/ucb/install
>
> Thanks again Jonathan.
>
> /usr/ucb/install no
On Fri, May 03, 2019 at 10:49:17PM +0200, Johannes Schindelin wrote:
> I am well aware of the way Debian-based systems handle alternatives, and I
> myself also use something similar to write this E-Mail (but it is not a
> symlink, it is a Git alias).
>
> But that's not the hack that I was talking
On Fri, May 03, 2019 at 04:18:02PM -0400, Jeffrey Walton wrote:
> I'm catching one failed self test under a sanitizer build. It looks
> like there's some latent UB present during 'make check'
How are you providing sanitizer options? If you're just putting
-fsanitize=undefined in the compiler flag
Hi Ævar,
On Thu, 2 May 2019, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Apr 26 2019, Johannes Schindelin wrote:
>
> > On Sat, 13 Apr 2019, brian m. carlson wrote:
> >
> >> On Fri, Apr 12, 2019 at 09:51:02PM -0400, Jeff King wrote:
> >> > I wondered how you were going to kick this in, since users ca
Hi Everyone,
I'm catching one failed self test under a sanitizer build. It looks
like there's some latent UB present during 'make check'
ok 39 - using --untracked-cache does not fail when core.untrackedCache is false
ok 40 - setting core.untrackedCache to keep
not ok 41 - test ident field is work
On Fri, May 03, 2019 at 10:55:54AM -0500, Robert Dailey wrote:
> I have a merge commit. HEAD is currently pointing at this merge
> commit. To be exact, HEAD points to master, which points to the merge
> commit. My goal is to diff only the changes in the merge commit (stuff
> committed directly in t
On Fri, May 03, 2019 at 01:45:03PM -0400, Jeff King wrote:
> On Fri, May 03, 2019 at 04:42:11PM +0200, SZEDER Gábor wrote:
>
> > > Since you *could* include it, I now assume that Coccinelle does not need
> > > to follow the `#include`s (otherwise, it would have complained about not
> > > finding t
On Fri, May 03, 2019 at 04:42:11PM +0200, SZEDER Gábor wrote:
> > Since you *could* include it, I now assume that Coccinelle does not need
> > to follow the `#include`s (otherwise, it would have complained about not
> > finding the `windows.h` header in your setup).
>
> We invoke Coccinelle/spatc
On Fri, May 03, 2019 at 03:09:51PM +0100, Andrew Molyneux wrote:
> Encoding name was erroneously documented as UTF-16-LE-BOM; this should
> in fact be UTF-16LE-BOM (no hyphen between '16' and 'LE').
> ---
> Documentation/gitattributes.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
I'm hoping this is mostly a learning opportunity for me. I'm assuming
things are working as designed, but I just don't understand something
fundamental.
I have a merge commit. HEAD is currently pointing at this merge
commit. To be exact, HEAD points to master, which points to the merge
commit. My
On 03/05/2019 11:28, Duy Nguyen wrote:
On Fri, May 3, 2019 at 5:25 PM Christian Spanier wrote:
Hi,
I found a bug where Git may delete untracked files without notice in
certain situations. This bug effects Git 2.21.0 both on Linux and Windows.
In summary this happens when git pull merges a com
On 02/05/2019 11:38, Duy Nguyen wrote:
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
From: Phillip Wood
Currently there is no way to get git to discard changes to the
worktree without overwriting untracked files. `reset --hard`,
`checkout --force`, `checkout :/` and `read-tree --reset
On 5/3/2019 10:16 AM, SZEDER Gábor wrote:
> On Fri, May 03, 2019 at 08:47:25AM -0400, Derrick Stolee wrote:
>> It would be much simpler to restrict the model. Your idea of changing
>> the file name is the inspiration here.
>>
>> * The "commit-graph" file is the base commit graph. It is always
>>
Interactive rebase (i.e. for example "git rebase -i HEAD~10") is used
most often to apply an action to a single commit, e.g. "rename",
"edit", "fixup", etc…
As result, people keep coming up with custom scripts and aliases for
every distinct action.
Instead, it would be nice to have native su
On Fri, May 03, 2019 at 04:42:11PM +0200, SZEDER Gábor wrote:
> > Since you *could* include it, I now assume that Coccinelle does not need
> > to follow the `#include`s (otherwise, it would have complained about not
> > finding the `windows.h` header in your setup).
> I don't really know what can
On Fri, May 03, 2019 at 11:32:32AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 May 2019, SZEDER Gábor wrote:
>
> > On Wed, May 01, 2019 at 06:01:08AM -0400, Denton Liu wrote:
> > > > Is it not possible to exclude certain directories for certain semantic
> > > > patches?
> > > >
> > > >
On Fri, May 03, 2019 at 08:47:25AM -0400, Derrick Stolee wrote:
> It would be much simpler to restrict the model. Your idea of changing
> the file name is the inspiration here.
>
> * The "commit-graph" file is the base commit graph. It is always
> closed under reachability (if a commit exists in
Encoding name was erroneously referred to as UTF-16-LE-BOM in name of
test; this should in fact be UTF-16LE-BOM (no hyphen between '16' and
'LE').
---
t/t0028-working-tree-encoding.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0028-working-tree-encoding.sh b/t/t0028-wor
Encoding name was erroneously documented as UTF-16-LE-BOM; this should
in fact be UTF-16LE-BOM (no hyphen between '16' and 'LE').
---
Documentation/gitattributes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.tx
On Fri, May 03 2019, Derrick Stolee wrote:
> On 5/2/2019 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> But those are separate from any back-compat concerns, which is what I
>> think makes sense to focus on now.
>
> Thinking more on this topic, I think I have a way to satisfy _all_ of
> your conc
On 5/2/2019 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
>
> But those are separate from any back-compat concerns, which is what I
> think makes sense to focus on now.
Thinking more on this topic, I think I have a way to satisfy _all_ of
your concerns by simplifying the plan for incremental commit-grap
On Fri, May 3, 2019 at 5:25 PM Christian Spanier wrote:
>
> Hi,
>
> I found a bug where Git may delete untracked files without notice in
> certain situations. This bug effects Git 2.21.0 both on Linux and Windows.
> In summary this happens when git pull merges a commit that replaces a
> submodule
On Fri, May 3, 2019 at 4:47 PM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> On Fri, 3 May 2019, Duy Nguyen wrote:
>
> > I have a feeling that most operations read the index unlocked,
> > manipulate and only lock before writing things out. So yeah it's
> > probably already racy.
>
> IIRC there is a c
Hi Dscho
On 03/05/2019 10:21, Johannes Schindelin wrote:
Hi Phillip,
On Wed, 1 May 2019, Phillip Wood wrote:
On 30/04/2019 23:49, Johannes Schindelin wrote:
On Tue, 30 Apr 2019, Phillip Wood wrote:
On 29/04/2019 17:07, Johannes Schindelin wrote:
On Fri, 26 Apr 2019, Phillip Wood wrote:
Hi,
I found a bug where Git may delete untracked files without notice in
certain situations. This bug effects Git 2.21.0 both on Linux and Windows.
In summary this happens when git pull merges a commit that replaces a
submodule folder with a symlink. Any files within the folder are deleted
wit
On Thu, May 02, 2019 at 02:04:22AM +0200, SZEDER Gábor wrote:
> On Wed, May 01, 2019 at 06:01:08AM -0400, Denton Liu wrote:
[snip]
> >
> > -- >8 --
> > Subject: [PATCH] Makefile: filter out compat/ from coccicheck
> >
> > Since most files in compat/ are pulled from external sources, ensure
> >
Hi Duy,
On Fri, 3 May 2019, Duy Nguyen wrote:
> I have a feeling that most operations read the index unlocked,
> manipulate and only lock before writing things out. So yeah it's
> probably already racy.
IIRC there is a check for that, so it is not actually racy ;-)
Ciao,
Johannes
Hi,
On Thu, 2 May 2019, SZEDER Gábor wrote:
> On Wed, May 01, 2019 at 06:01:08AM -0400, Denton Liu wrote:
> > > Is it not possible to exclude certain directories for certain semantic
> > > patches?
> > >
> > > I guess we could also simply declare that *all* Coccinelle patches should
> > > leave `
Hi Phillip,
On Thu, 2 May 2019, Phillip Wood wrote:
> From: Phillip Wood
>
> If a merge can be fast-forwarded then make sure that we still edit the
> commit message if the user specifies -c. The implementation follows the
> same pattern that is used for ordinary rewords that are fast-forwarded.
Hi Phillip,
On Wed, 1 May 2019, Phillip Wood wrote:
> On 30/04/2019 23:49, Johannes Schindelin wrote:
> >
> > On Tue, 30 Apr 2019, Phillip Wood wrote:
> >
> > > On 29/04/2019 17:07, Johannes Schindelin wrote:
> > > >
> > > > On Fri, 26 Apr 2019, Phillip Wood wrote:
> > > >
> > > > > From: Phillip
On Thu, Apr 25, 2019 at 02:25:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
[..]
> Do you or anyone have a suggestion for a better CLI option name?
>
> Maybe --pickaxe-patch or --pickaxe-patch-format (to go with git-diff's
> -u aka --patch (i.e. not --raw) default format)? Or
> --pickaxe-G-with-conte
Hi Peff,
On Tue, 30 Apr 2019, Jeff King wrote:
> On Tue, Apr 30, 2019 at 06:07:15PM -0400, Johannes Schindelin wrote:
>
> > Alternatively, I could simply drop that patch from Git for Windows, as
> > it really only concerns users who override the default, opting out of
> > using Git Credential Man
Hi Hannes,
On Wed, 1 May 2019, Johannes Sixt wrote:
> Am 01.05.19 um 00:33 schrieb Johannes Schindelin:
> > On Tue, 30 Apr 2019, Johannes Sixt wrote:
> >> Am 30.04.19 um 01:17 schrieb Johannes Schindelin:
> >>> You're right, this is confusing, especially since Git for Windows 2.x does
> >>> not h
Hi,
On Thu, 2 May 2019, SZEDER Gábor wrote:
> On Tue, Apr 30, 2019 at 06:25:35PM -0400, Johannes Schindelin wrote:
> >
> > On Tue, 30 Apr 2019, SZEDER Gábor wrote:
> >
> > > diff --git a/sequencer.c b/sequencer.c
> > > index 546f281898..c2e4baa90e 100644
> > > --- a/sequencer.c
> > > +++ b/sequen
On Thu, Apr 25, 2019 at 09:44:40AM +0900, Junio C Hamano wrote:
[..]
> So the user would be able to say something like
>
> git log -Ux --since=6.months |
> git patch-grep \
> --commit-names-only \
> --all-match \
> -e '+.*devm_request_threaded_
Hi,
On Thu, 2 May 2019, SZEDER Gábor wrote:
> On Tue, Apr 30, 2019 at 06:16:48PM -0400, Johannes Schindelin wrote:
>
> > > [...]
> >
> > I assume you verified that this works also with our Azure Pipeline?
>
> No, I didn't; only on Travis CI's 14.04 and 16.04 images and on a
> local 16.04 install.
Bcc:
Subject: Re: [PATCH 2/2] diffcore-pickaxe: add --pickaxe-raw-diff for use
with -G
Reply-To:
In-Reply-To: <20190503031531.ga19...@sigill.intra.peff.net>
On Thu, May 02, 2019 at 11:15:31PM -0400, Jeff King wrote:
> On Thu, Apr 25, 2019 at 02:54:48AM +0200, Eugeniu Rosca wrote:
>
> > > This
Hi Andreas,
Thanks for the earlier corrections on 2/3.
On Fri, May 03, 2019 at 10:01:08AM +0200, Andreas Heiduk wrote:
> Am 27.04.19 um 14:15 schrieb Denton Liu:
>
> While reading/reviewing I stumbled across another case for marking optional
> clauses. But the solutions is not a one-liner. @Dent
Am 27.04.19 um 14:15 schrieb Denton Liu:
While reading/reviewing I stumbled across another case for marking optional
clauses. But the solutions is not a one-liner. @Denton Would you please add
that one as Patch 4/4 to your series?
- 8<
Subject: [PATCH]
Am 03.05.19 um 09:17 schrieb Andreas Heiduk:
> Am 27.04.19 um 14:16 schrieb Denton Liu:
>> In revisions.txt, an optional rev argument was not distinguised.
>> Instead, a user had to continue and read the description in order to
>> learn that the argument was optional.
>>
>> Since the [] notation fo
Am 27.04.19 um 14:16 schrieb Denton Liu:
> In revisions.txt, an optional rev argument was not distinguised.
> Instead, a user had to continue and read the description in order to
> learn that the argument was optional.
>
> Since the [] notation for an optional argument is common-knowledge in
> the
43 matches
Mail list logo
