On Wed, Nov 15, 2023 at 09:49:31AM -0800, Kees Cook wrote:
> On Wed, Nov 15, 2023 at 06:03:30PM +0100, Borislav Petkov wrote:
> > From: "Borislav Petkov (AMD)"
> >
> > After receiving a second patchset this week without knowing which tree
> > it applies on and trying to apply it on the obvious on
On 22/10/19 09:46AM, Bert Wesarg wrote:
> On Mon, Oct 21, 2019 at 9:35 PM Johannes Sixt wrote:
> >
> > Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> > > Dear Pratyush,
> > >
> > > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > > the stage-list. But I think it should be disab
if there
> are no more changes to this file in the worktree. I.e., you wont be
> able to apply the 'undo' anymore to the worktree file if it is not
> listed anymore. Though even that case should be able to implement.
> Though the undo is currently not bound to a specific path. Thi
On 10/23/2019 1:00 PM, Torsten Bögershausen wrote:
> On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
>> Here is today's test coverage report. The usual report format is
>> available online [1], [2]. The report listed below is a new format
>> that groups lines by the commit that intr
nt_sanitized_diff () {
> git diff "$@" >diff.raw &&
> ...
>
> Or, better yet, keep the original design and pass the diff in as the
> shell function's input, so a caller would say:
>
> git diff HEAD >diff.raw &&
> sanitize_conflicted_diff exp
On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
> Here is today's test coverage report. The usual report format is
> available online [1], [2]. The report listed below is a new format
> that groups lines by the commit that introduced them [3]. Thanks
> Peff for the feedback on that
On Wed, Oct 23, 2019 at 07:05:04PM +0900, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > The Azure Pipelines builds are failing for macOS due to a change in the
> > location of the perforce cask. The command outputs the following
On Wed, Oct 23, 2019 at 01:01:00PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
> >> and 'logs/refs/worktree', next to the already existing
> >> 'logs/refs/bisect'. This resulted in a trie node with the pa
On 10/23/19 1:02 AM, Jeff King wrote:
> On Tue, Oct 22, 2019 at 07:28:47PM -0400, Prarit Bhargava wrote:
>
>> In many projects the number of contributors is low enough that users know
>> each other and the full email address doesn't need to be displayed.
>> Displaying only the author's username
On 10/22/19 7:48 PM, brian m. carlson wrote:
> On 2019-10-22 at 23:28:47, Prarit Bhargava wrote:
>> In many projects the number of contributors is low enough that users know
>> each other and the full email address doesn't need to be displayed.
>> Displaying only the author's username saves a lo
On Wed, Oct 23, 2019 at 01:01:35PM +, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The previous commit includes a failing test for an issue around
> fetch.writeCommitGraph and fetching in a repo with a submodule. Here, we
> fix that bug and set the test to "test_expect_su
On 10/22/19 7:46 PM, Junio C Hamano wrote:
> Prarit Bhargava writes:
>
>> Subject: Re: [PATCH] pretty: Add "%aU"|"%au" option to output author's
>> username
>
> Downcase "Add" (see "git shortlog --no-merges -100 master" an
On Wed, Oct 23, 2019 at 01:01:34PM +, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> While dogfooding, Johannes found a bug in the fetch.writeCommitGraph
> config behavior. His example initially happened during a clone with
> --recurse-submodules, we found that this happens
On Fri, Oct 18, 2019 at 2:52 PM Denton Liu wrote:
> On Thu, Oct 17, 2019 at 07:41:44PM -0400, Eric Sunshine wrote:
> > On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> > > - test "$COPY" = "$(git rev-parse --verify me/copy)" &&
> > > + test_cmp_rev "$COPY" me/copy &&
> >
> > This t
ot;
> +}
>
> +test_apply_with_3way success default true
> +test_apply_with_3way failure 'merge.conflictStyle = diff3' 'test_config
> merge.conflictStyle diff3'
This isn't the prettiest way to achieve this; the "success"/"failure"
arguments, espe
On Wednesday 23 October 2019 13:09:51 CEST Denton Liu wrote:
> On Wed, Oct 23, 2019 at 10:15:15AM +, Jerome Pouiller wrote:
> > On Wednesday 23 October 2019 10:55:03 CEST Denton Liu wrote:
> > > I am currently have a WIP patchset that will print the location of the
> > > failed patch file (.git
On 10/22/2019 11:48 PM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>>> I'm slightly wary of changing the output of plumbing commands
>>> like this. If a script wants progress output it can already get
>>> it by passing --verbose. With this change a script that does not
>>> want that output
On Wed, Oct 23, 2019 at 10:15:15AM +, Jerome Pouiller wrote:
> On Wednesday 23 October 2019 10:55:03 CEST Denton Liu wrote:
> > I am currently have a WIP patchset that will print the location of the
> > failed patch file (.git/rebase-apply/patch) in the case of a failure as
> > well as the line
On Wednesday 23 October 2019 10:55:03 CEST Denton Liu wrote:
> On Wed, Oct 23, 2019 at 08:49:41AM +, Jerome Pouiller wrote:
> > On Wednesday 23 October 2019 04:24:58 CEST Junio C Hamano wrote:
> > > Jerome Pouiller writes:
> > > > I try to use "git am" to apply a patch sent using "git send-ema
Eric Wong wrote:
> Johannes Schindelin wrote:
> > I guess your patch won't hurt.
>
> Cool, will update tests and resend.
Turns out the t3206 "trivial reordering" case is way too noisy.
I might need to change diff.c to support this case; will update
in a few days or week.
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The Azure Pipelines builds are failing for macOS due to a change in the
> location of the perforce cask. The command outputs the following error:
>
> + brew install caskroom/cask/perforce
> Error: caskroom/cas
On Wed, Oct 23, 2019 at 07:22:12AM +, Aleksey Mikhaylov wrote:
> "Could not access submodule" error when pulling recursively with Git 2.22.0.
> This issue causes if there is submodule in submodule.
> Please use my simple test repository to reproduce the problem:
> https://github.com/agmikhailo
Hi Jerome,
On Wed, Oct 23, 2019 at 08:49:41AM +, Jerome Pouiller wrote:
> On Wednesday 23 October 2019 04:24:58 CEST Junio C Hamano wrote:
> > Jerome Pouiller writes:
> > > I try to use "git am" to apply a patch sent using "git send-email". This
> > > patch does not apply properly. I try to u
On Wednesday 23 October 2019 04:24:58 CEST Junio C Hamano wrote:
> Jerome Pouiller writes:
> > I try to use "git am" to apply a patch sent using "git send-email". This
> > patch does not apply properly. I try to use "git am --show-current-patch"
> > to understand the problem. However, since origin
On Wed, Oct 23, 2019 at 12:52 PM Junio C Hamano wrote:
>
> Emily Shaffer writes:
>
> > As for the content of this change, I absolutely approve. I've stumbled
> > across some of these empty docs while looking for answers before and
> > found it really demoralizing - the community is so interested
On Wed, Oct 23, 2019 at 10:05 AM Emily Shaffer wrote:
>
> On Tue, Oct 22, 2019 at 06:19:35PM +, Heba Waly via GitGitGadget wrote:
> > From: Heba Waly
> >
> > Remove empty and redundant documentation files from the
> > Documentation/technical/ directory.
> >
> > As part of moving the documenta
On Tue, Oct 22, 2019 at 07:28:47PM -0400, Prarit Bhargava wrote:
> In many projects the number of contributors is low enough that users know
> each other and the full email address doesn't need to be displayed.
> Displaying only the author's username saves a lot of columns on the screen.
> For exa
On Wed, Oct 23, 2019 at 9:59 AM Emily Shaffer wrote:
>
> On Tue, Oct 22, 2019 at 07:05:06AM +, Heba Waly via GitGitGadget wrote:
> > From: Heba Waly
> >
> > Move the documentation from Documentation/technical/api-config.txt into
> > config.h
>
> This is still a little thin for what we usually
Emily Shaffer writes:
> +# Commit
> +
> +This is the one we're all familiar with - commits are those things we write
> at
> +1am, angry at a pesky bug, and label with something like "really fix it this
> +time", right?
> +
> +A commit references exactly one tree. That's the root directory of you
Eric Wong writes:
> What Konstantin said about git repos being transient.
> It wasn't too much work to recreate those blobs from
> scratch since git-apply has done it since 2005.
;-)
> We could get around transient repos with automatic mirroring
> bots which never deletes or overwrites anything
SZEDER Gábor writes:
>> - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
>> and 'logs/refs/worktree', next to the already existing
>> 'logs/refs/bisect'. This resulted in a trie node with the path
>> 'logs/refs', which didn't exist before, and which doesn't have a
"Derrick Stolee via GitGitGadget" writes:
> V4 UPDATE: Rebased on latest master to include ew/hashmap and
> ds/include-exclude in the base.
>
> This series makes the sparse-checkout feature more user-friendly. While
> there, I also present a way to use a limited set of patterns to gain a
> signif
Derrick Stolee writes:
>> I'm slightly wary of changing the output of plumbing commands
>> like this. If a script wants progress output it can already get
>> it by passing --verbose. With this change a script that does not
>> want that output now has to pass --no-verbose.
>
> If a script is calli
SZEDER Gábor writes:
>> +char *base = buf->buf + git_dir_len, *base2 = NULL;
>> +
>> +if (ends_with(base, ".lock"))
>> +base = base2 = xstrndup(base, strlen(base) - 5);
>
> Hm, this adds the magic number 5 and calls strlen(base) twice, because
> ends_with() calls strip_suffix(
"Johannes Schindelin via GitGitGadget"
writes:
> In dcb500dc16c (cherry-pick/revert: advise using --skip, 2019-07-02), we
> introduced a helpful message that suggests to run git cherry-pick --skip
> (instead of the previous message that talked about git reset) when a
> cherry-pick failed due to
"Johannes Schindelin via GitGitGadget"
writes:
> Note: we take pains to handle the situation when a user runs a `git
> cherry-pick` _during_ a rebase. This is quite valid (e.g. in an `exec`
> line in an interactive rebase). On the other hand, it is not possible to
> run a rebase during a cherry-p
Jerome Pouiller writes:
> Hello all,
>
> I try to use "git am" to apply a patch sent using "git send-email". This
> patch does not apply properly. I try to use "git am --show-current-patch"
> to understand the problem. However, since original mail is encoded in quoted-
> printable, data returned
Denton Liu writes:
> According to t/README, test_must_fail() should only be used to test for
> failure in Git commands. Replace the invocations of
> `test_must_fail grep` with `! grep`.
>
> Signed-off-by: Denton Liu
> ---
> *sigh* Here's another cleanup patch for 'dl/submodule-set-branch'. It's
Emily Shaffer writes:
>> ...
>> +/**
>> + * The config API gives callers a way to access Git configuration files
>> + * (and files which have the same syntax). See linkgit:git-config[1] for a
>
> Ah, here's another place where the Asciidoc link isn't going to do
> anything anymore.
>
> Otherwise
Johannes Schindelin writes:
> However, I think this is _really_ ugly and intrusive. The opposite of
> what my goals were.
>
> So I think I'll just bite the bullet and use a temporary copy if the
> argument ends in `.lock`.
Sounds like a quite sensible design decision to me.
Bert Wesarg writes:
> Please ignore this. Will rebase on 2.24-rc0 and will only include the
> test changes.
Thanks.
"Johannes Schindelin via GitGitGadget"
writes:
> Changes since v1:
>
> * Fixed typo "nore" -> "nor" in the commit message.
>
> Johannes Schindelin (2):
> ci(visual-studio): use strict compile flags, and optimization
> ci(visual-studio): actually run the tests in parallel
>
> azure-pipelines
Jeff King writes:
> But here's where it gets tricky. In addition to catching any size
> mismatches, this will also catch signedness problems. I.e., if we make
> OPT_INTEGER() use "intp", then everybody passing in &unsigned_var now
> gets a compiler warning. Which maybe is a good thing, I dunno.
Johannes Schindelin wrote:
> Hi Eric,
>
>
> On Thu, 17 Oct 2019, Eric Wong wrote:
>
> > (WIP, mostly stream-of-concious notes + reasoning)
> >
> > When using "git format-patch --range-diff", the pre and
> > post-image blob OIDs are in each email, while the exact
> > commit OIDs are rarely share
On Tue, Oct 22, 2019 at 08:48:20PM -0400, Jeff King wrote:
> I admit I am puzzled, though, _why_ the presence of the submodule
> matters. That is, from your explanation, I thought the issue was simply
> that `fetch` walked (and marked) some commits, and the flags overlapped
> with what the commit-
On Tue, Oct 22, 2019 at 08:35:57PM -0400, Derrick Stolee wrote:
> > In the cover letter Derrick mentioned that he used
> > https://github.com/derrickstolee/numbers for testing, and that repo
> > has a submodule as well.
>
> I completely forgot that I put a submodule in that repo. It makes sense
>
On 10/22/2019 7:35 PM, SZEDER Gábor wrote:
> On Tue, Oct 22, 2019 at 05:45:54PM -0400, Jeff King wrote:
>> Puzzling...
>
> Submodules?
>
> $ cd ~/src/git/
> $ git quotelog 86cfd61e6b
> 86cfd61e6b (sha1dc: optionally use sha1collisiondetection as a submodule,
> 2017-07-01)
> $ git init
On Wed, Oct 23, 2019 at 01:23:25AM +0200, Johannes Schindelin wrote:
> On Fri, 18 Oct 2019, SZEDER Gábor wrote:
>
> > On Thu, Oct 17, 2019 at 12:47:33PM +, Johannes Schindelin via
> > GitGitGadget wrote:
> > > From: Johannes Schindelin
> > >
> > > The CI builds are failing for Mac OS X due t
Emily Shaffer writes:
> As for the content of this change, I absolutely approve. I've stumbled
> across some of these empty docs while looking for answers before and
> found it really demoralizing - the community is so interested in
> teaching me how to contribute that they've sat on a TODO for 1
On 2019-10-22 at 23:28:47, Prarit Bhargava wrote:
> In many projects the number of contributors is low enough that users know
> each other and the full email address doesn't need to be displayed.
> Displaying only the author's username saves a lot of columns on the screen.
> For example displaying
Prarit Bhargava writes:
> Subject: Re: [PATCH] pretty: Add "%aU"|"%au" option to output author's
> username
Downcase "Add" (see "git shortlog --no-merges -100 master" and
mimick the project convention).
> Add a "%aU"|"
Johannes Schindelin writes:
>> This is already in 'next' X-<; reverting a merge is cheap but I
>> prefer to do so when we already have a replacement.
>
> I force-pushed (see https://github.com/gitgitgadget/git/pull/400), and
> once Stolee approves, he will submit v3. This will only change the
> c
On Tue, Oct 22, 2019 at 05:45:54PM -0400, Jeff King wrote:
> On Tue, Oct 22, 2019 at 04:33:16PM -0400, Jeff King wrote:
>
> > > I have failed to produce a test using the file:// protocol that
> > > demonstrates this bug.
> >
> > Hmm, from the description, it sounds like it should be easy. I might
Hi,
On Mon, 21 Oct 2019, Denton Liu wrote:
> Hi Johannes,
>
> On Mon, Oct 21, 2019 at 08:44:40PM +0200, Johannes Schindelin wrote:
> > Hi Junio,
> >
> > On Fri, 18 Oct 2019, Junio C Hamano wrote:
> >
> > > Denton Liu writes:
> > >
> > > > There are many += lists in the Makefile and, over time, t
Hi Junio,
On Mon, 21 Oct 2019, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Thu, Oct 17, 2019 at 12:47:33PM +, Johannes Schindelin via
> > GitGitGadget wrote:
> >> From: Johannes Schindelin
> >>
> >> The CI builds are failing for Mac OS X due to a change in the
> >
> > s/CI/Azure
27;t
> look why). This worked fine for a while, until a couple of days ago
> Perforce updated the r19.1 binaries in place, breaking those
> checksums.
>
> If we were to still run 'brew update', then it would shortly fix the
> checksum mismatch. But we don't run
On Tue, Oct 22, 2019 at 04:33:16PM -0400, Jeff King wrote:
> > I have failed to produce a test using the file:// protocol that
> > demonstrates this bug.
>
> Hmm, from the description, it sounds like it should be easy. I might
> poke at it a bit.
Hmph. I can reproduce it here, but it seems to de
On Fri, Sep 20, 2019 at 06:47:01PM -0700, Emily Shaffer wrote:
> On Fri, Sep 20, 2019 at 10:04:48AM -0700, Jonathan Tan wrote:
> > > Prospective mentors need to sign up on that site, and should propose a
> > > project they'd be willing to mentor.
> >
> > [snip]
> >
> > > I'm happy to discuss poss
On Tue, Oct 22, 2019 at 06:19:35PM +, Heba Waly via GitGitGadget wrote:
> From: Heba Waly
>
> Remove empty and redundant documentation files from the
> Documentation/technical/ directory.
>
> As part of moving the documentation from Documentation/technical/api-* to
> header files, the follow
On Tue, Oct 22, 2019 at 07:05:06AM +, Heba Waly via GitGitGadget wrote:
> From: Heba Waly
>
> Move the documentation from Documentation/technical/api-config.txt into
> config.h
This is still a little thin for what we usually want from commit
messages. Try to imagine that five years from now,
On Sun, Oct 20, 2019 at 09:35:17PM +1300, Heba Waly wrote:
> On Sat, Oct 19, 2019 at 11:52 AM Emily Shaffer
> wrote:
> >
> > On Fri, Oct 18, 2019 at 12:06:59AM +, Heba Waly via GitGitGadget wrote:
> > > From: Heba Waly
> >
> > Hi Heba,
> >
> > Thanks for the patch!
> >
> > I'd like to highli
On Tue, Oct 22, 2019 at 04:06:16PM -0400, Jeff King wrote:
I'm biased, but I think the commit-graph is generally really good to
have
in almost all cases. I actually do not know of a good reason to _not_ have
it.
A lot depends on how much you do on the server. If you're serving a web
interface
On Tue, Oct 22, 2019 at 05:28:55PM +, Derrick Stolee via GitGitGadget wrote:
> However, the UNINTERESTING flag is used in lots of places in the
> codebase. This flag usually means some barrier to stop a commit walk,
> such as in revision-walking to compare histories. It is not often
> cleared
[resending, looks like we lost Konstantin from the cc]
On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:
> I'm biased, but I think the commit-graph is generally really good to have
> in almost all cases. I actually do not know of a good reason to _not_ have
> it.
A lot depends on h
On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:
> I'm biased, but I think the commit-graph is generally really good to have
> in almost all cases. I actually do not know of a good reason to _not_ have
> it.
A lot depends on how much you do on the server. If you're serving a web
in
First, the commit message could probably be reordered to start with the
main point (reusing of packfiles at object granularity instead of
allowing reuse of only one contiguous region). To specific points:
> The dynamic array of `struct reused_chunk` is useful
> because we need to know not just the
On 10/22/2019 12:51 PM, Konstantin Ryabitsev wrote:
> Hi, all:
>
> I've read the docs on commitGraph and it's not 100% clear to me if turning it
> on and generating commit graphs would be useful on the server-side. I know
> it's going to be enabled by default and automatically generated whenever
On Tue, Oct 22, 2019 at 09:18:35PM +0200, Johannes Schindelin wrote:
As to recreating blobs from mails: Wow. That's quite a length you're
going, and I think it is a shame that you have to. If only every
contribution came accompanied with a pullable branch in a public
repository.
Trouble is, tho
Hi Eric,
On Thu, 17 Oct 2019, Eric Wong wrote:
> (WIP, mostly stream-of-concious notes + reasoning)
>
> When using "git format-patch --range-diff", the pre and
> post-image blob OIDs are in each email, while the exact
> commit OIDs are rarely shared via emails (only the tip
> commit from "git re
Sorry for the long delay before getting back to this; the other stuff
I was working on took longer than expected.
On Mon, Oct 14, 2019 at 3:42 AM Johannes Schindelin
wrote:
> On Sat, 12 Oct 2019, Elijah Newren wrote:
> > On Sat, Oct 12, 2019 at 1:37 PM Johannes Schindelin
> > wrote:
> > >
> > >
Vegard Nossum wrote:
> I sent v2 of the patches (with metadata _after_ the diff) to the git
> list here:
>
> https://public-inbox.org/git/20191022114518.32055-1-vegard.nos...@oracle.com/T/#u
>
> As I wrote in there, we could already today start using
>
>git am --message-id
>
> when applyin
> From: Jeff King
>
> In a following commit we will need to allocate a variable
> number of bitmap words, instead of always 32, so let's add
> bitmap_word_alloc() for this purpose.
>
> We will also always access at least one word for each bitmap,
> so we want to make sure that at least one is al
On 10/22/19 3:53 PM, Theodore Y. Ts'o wrote:
On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:
As I wrote in there, we could already today start using
git am --message-id
when applying patches and this would provide something that a bot could
annotate with git notes pointing
On Mon, Oct 21, 2019 at 09:54:42PM +, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> Ever since worktrees were introduced, the `git_path()` function _really_
> needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
> specific to the worktree, and t
Hi Dscho,
Install went Ok.
Did a quick test on the config locations and `git config -l
-show-origin` has 'lost' the ProgramData location as planned.
The minor pedant did notice that the new location is listed slightly
differently from the release notes.
`file:C:/Program Files/Git/mingw64/..
Hi Matheus,
On Mon, Oct 21, 2019 at 7:14 PM Matheus Tavares Bernardino
wrote:
>
> I wrote a small follow-up post to talk about the conclusion of my GSoC
> project. I believe the main remaining tasks are now finally complete
> :) If you would be interested in taking a look, the post is at
> https:
On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:
>
> As I wrote in there, we could already today start using
>
> git am --message-id
>
> when applying patches and this would provide something that a bot could
> annotate with git notes pointing to lore/LKML/LWN/whatever. I think t
El lun., 21 oct. 2019 a las 20:35, Emily Shaffer
() escribió:
>
> On Mon, Oct 21, 2019 at 12:39:16PM +0200, Miriam R. wrote:
> > Dear Git developers,
> > I’m an Outreachy applicant, I would like to make my contribution to
> > apply to this Outreachy internship period.
>
> Welcome, Miriam! Good to h
On 10/20/19 8:28 AM, Vegard Nossum wrote:
On 10/20/19 5:17 AM, Willy Tarreau wrote:
On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:
On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
The problem I ran into with putting the metadata at the end was
detecting where
Jeff King writes:
>> ...
>> I agree with you that it did correctly sort them in ASCII order.
>
> What's the purpose of sorting them, though? I thought it was less for
> aesthetics and more to to keep lines deterministic (to avoid two
> branches adding the same line in different places, thus causi
Hi Karina,
Please see my answer below.
On Mon, Oct 21, 2019 at 6:59 PM Karina Saucedo
wrote:
>
> Hello, my name is Karina and I'm and Outreachy applicant.
> I´m interested in applying to the project 'Add did you mean hints´ and
> I was wondering how can I start contributing since there seem to b
On Mon, Oct 21, 2019 at 9:04 PM Pratyush Yadav wrote:
>
> On 21/10/19 11:16AM, Bert Wesarg wrote:
> > Dear Pratyush,
> >
> > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > the stage-list. But I think it should be disabled, like the 'Revert
> > Hunk' and 'Revert Line' menu
Hello,
I added the git list to Cc:. For the new readers: The context of this
thread can be found at
https://lwn.net/ml/linux-kernel/20191017234348.wcbbo2njexn7ixpk@willie-the-truck/
On Mon, Oct 21, 2019 at 08:46:58AM +0200, Ingo Molnar wrote:
> Anyway, a small Git feature request: it would be sup
On Mon, Oct 21, 2019 at 9:35 PM Johannes Sixt wrote:
>
> Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> > Dear Pratyush,
> >
> > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > the stage-list. But I think it should be disabled, like the 'Revert
> > Hunk' and 'Revert Line' menu
On Mon, Oct 21, 2019 at 04:04:22PM -0700, Elijah Newren wrote:
> > 4211.3: git log --follow [...]8.56(8.41+0.15) -0.2% 3.67(3.53+0.13)
> > -57.2%
>
> Many nice speedups here, not just commit-graph (the rev-list cases)
> but also log -L (from sg/line-log-tree-diff-optim, I believe), and log
On Mon, Oct 21, 2019 at 1:50 PM Derrick Stolee wrote:
> I ran a few of the performance tests against the Linux repository
> using v2.22.0, v2.23.0, and the new v2.24.0-rc0. I thought it worth
> pointing out that the drastic performance improvements are due to
> turning on the commit-graph by defa
Team,
a couple of days later than I wanted, but at least it is now here:
https://github.com/git-for-windows/git/releases/tag/v2.24.0-rc0.windows.1
Please test...
Thank you,
Johannes
On Mon, Oct 21, 2019 at 06:00:43PM +0200, SZEDER Gábor wrote:
> 'logs/refs' is not a working tree-specific path, but since commit
> b9317d55a3 (Make sure refs/rewritten/ is per-worktree, 2019-03-07)
> 'git rev-parse --git-path' has been returning a bogus path if a
> trailing '/' is present:
>
>
(dropping some of the other aliases from this reply)
I ran a few of the performance tests against the Linux repository
using v2.22.0, v2.23.0, and the new v2.24.0-rc0. I thought it worth
pointing out that the drastic performance improvements are due to
turning on the commit-graph by default. I had
On 10/18/2019 8:20 PM, Emily Shaffer wrote:
> An overview of what Git object types mean and how they loosely translate
> into filesystem types users are already familiar with is a good start to
> making Git's internals less scary to users. This post is an interactive
> overview of the various types
Hi Junio,
On Fri, 18 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > Ever since worktrees were introduced, the `git_path()` function _really_
> > needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
> >
On Tue, Oct 22, 2019 at 04:49:19AM +0900, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> ... I do not particularly see this change (there may be similar
> >> ones) desirable. I'd find it it be much more natural to sort
> >> "commit-anything" after "commit", and that is true with or
Johannes Schindelin writes:
>> ... I do not particularly see this change (there may be similar
>> ones) desirable. I'd find it it be much more natural to sort
>> "commit-anything" after "commit", and that is true with or without
>> the common extension ".o" added to these entries.
>>
>> In short
Hi Gábor,
On Fri, 18 Oct 2019, SZEDER Gábor wrote:
> On Fri, Oct 18, 2019 at 01:06:18PM +0200, SZEDER Gábor wrote:
> > I didn't look yesterday at all, but now I did, and, unfortunately, see
> > two more bugs
>
> The second patch is kind of a bugfix, though luckily the bug doesn't
> actually manif
Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> Dear Pratyush,
>
> I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> the stage-list. But I think it should be disabled, like the 'Revert
> Hunk' and 'Revert Line' menu entry.
>
> Can you confirm this?
Technically, it need not be dis
Hi Denton,
On Wed, 16 Oct 2019, Denton Liu wrote:
> In rebase, one can pass the `--autostash` option to cause the worktree
> to be automatically stashed before continuing with the rebase. This
> option is missing in merge, however.
>
> Implement the `--autostash` option and corresponding `merge.a
On 21/10/19 11:16AM, Bert Wesarg wrote:
> Dear Pratyush,
>
> I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> the stage-list. But I think it should be disabled, like the 'Revert
> Hunk' and 'Revert Line' menu entry.
I'm not sure what you mean. There is no "Revert Last Hunk" m
Hi Denton,
On Wed, 16 Oct 2019, Denton Liu wrote:
> Continue the process of lib-ifying the autostash code. In a future
> commit, this will be used to implement `--autostash` in other builtins.
>
> This patch is best viewed with `--color-moved` and
> `--color-moved-ws=allow-indentation-change`.
>
Hi,
[sorry, Phillip, my reply-all fu deserts me today, apparently.]
On Fri, 18 Oct 2019, Phillip Wood wrote:
> Hi Denton
>
> It's great to see this being libified, I've had it in mind to do this so we
> can avoid forking 'git checkout' in sequencer.c
>
> On 16/10/2019 18:26, Denton Liu wrote:
>
Hi Johannes,
On Mon, Oct 21, 2019 at 08:44:40PM +0200, Johannes Schindelin wrote:
> Hi Junio,
>
> On Fri, 18 Oct 2019, Junio C Hamano wrote:
>
> > Denton Liu writes:
> >
> > > There are many += lists in the Makefile and, over time, they have gotten
> > > slightly out of order, alphabetically. A
1 - 100 of 116325 matches
Mail list logo
