Dear Pratyush,
putting me in Cc would have been nice :(
I will look into your patches in the comming hours.
Bert
On Mon, Aug 19, 2019 at 11:41 PM Pratyush Yadav wrote:
>
> Hi,
>
> This series adds the ability to revert selected lines and hunks in
> git-gui. Partially based on the patch by Bert
> On Tue, Aug 20, 2019 at 12:35 PM Uwe Brauer wrote:
> Try adding '--all' to include all refs, not just the current HEAD, to
> begin logging from. Here is what I see after running your setup
> script.
> $ git log --graph --decorate --all
> * commit 3262040f2d8d5f31b4918bda998
Line-level log can be very slow with rename detection enabled (and its
enabled by default), which is caused by it using the diff machinery
very inefficiently. The second patch fixes the issue and make it much
faster, especially in large repositories.
This patch series is independent from my other
A helper function to parse the paths involved in the line ranges and
to turn them into a pathspec will be useful in the next patch.
Signed-off-by: SZEDER Gábor
---
line-log.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/line-log.c b/line-
With rename detection enabled the line-level log is able to trace the
evolution of line ranges across whole-file renames [1]. Alas, to
achieve that it uses the diff machinery very inefficiently, making the
operation very slow [2]. And since rename detection is enabled by
default, the line-level l
On Mon, Aug 19, 2019 at 12:12:32PM -0400, Derrick Stolee wrote:
> On 8/19/2019 11:02 AM, SZEDER Gábor wrote:
> > On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
> >> Note that I don't include the "without patch" numbers. For some
> >> reason the path provided is particularly nasty a
> That's it, thanks. Interestingly enough the
> git graph looks differently from the mercurial one.
It does not. I just did not understand the git commands at first sight
well enough. Both graphs look the same. Sorry for the noise.
Hi everyone,
The 54th edition of Git Rev News is now published:
https://git.github.io/rev_news/2019/08/21/edition-54/
Thanks a lot to Elijah Newren, Jeff Hostetler, Andrew Ardill and
Jean-Noël Avila who contributed this month!
Enjoy,
Christian, Jakub, Markus and Gabriel.
So, does QGit have a test build for Windows, perhaps run as a
regression test to verify the build each time a change is made to the
source?
Rick
On Thu, Aug 15, 2019 at 4:06 PM Rick Tillery wrote:
>
> QGit's README (
> https://github.com/tibirna/qgit/blob/master/README.adoc ) directs me
> to thi
On 21/08/2019 15:01, Christian Couder wrote:
Hi everyone,
The 54th edition of Git Rev News is now published:
https://git.github.io/rev_news/2019/08/21/edition-54/
Thanks a lot to Elijah Newren, Jeff Hostetler, Andrew Ardill and
Jean-Noël Avila who contributed this month!
Enjoy,
Christian,
On 08/20, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Fix the test by updating the mtime of test.r, so git is forced to
> > check the contents of the file, and the clean filter is run as the
> > test expects.
>
> Hmph, depending on the timestamp granularity, with this patch,
> test.r w
On 08/20, Johannes Sixt wrote:
> Am 20.08.19 um 08:56 schrieb Thomas Gummerer:
> > Fix the test by updating the mtime of test.r, ...
>
> > diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
> > index e10f5f787f..66f75005d5 100755
> > --- a/t/t0021-conversion.sh
> > +++ b/t/t0021-conversion
Junio C Hamano writes:
> "Garima Singh via GitGitGadget" writes:
>
>> create mode 100644 t/helper/test-quote.c
>> create mode 100755 t/t0091-quote.sh
>
> I do not appreciate these two new files only to test this corner
> case. ...
To avoid misunderstanding, I am not against having unit tests
Thomas Gummerer writes:
> It will also check the contents if the mtime is greater than the
> timestamp of the index, so the 'touch' here would also cover that.
>
> So the changes here do solve the race completely.
OK, the explanation makes sense.
Either test.r has been correctly checked out and
On 8/21/2019 7:04 AM, SZEDER Gábor wrote:
> With rename detection enabled the line-level log is able to trace the
> evolution of line ranges across whole-file renames [1]. Alas, to
> achieve that it uses the diff machinery very inefficiently, making the
> operation very slow [2]. And since rename
On August 20, 2019 6:56 PM, brian m. carlson wrote:
> To: git@vger.kernel.org
> Cc: Duy Nguyen
> Subject: Feedback on git switch and git restore
>
> I just wanted to let folks know that I've seen multiple positive comments on
> Twitter today (at least 3) about "git switch" and "git restore". Fol
Eric Sunshine writes:
> This synopsis shows only 'verify' accepting --[no-]progress,
> however, ...
> This is misleading. The --progress option does not _toggle_ the
> setting. ...
Thanks for a careful review.
SZEDER Gábor writes:
> So basically the line-level log computes a full tree diff for each
> commit-parent pair in step (1) to be used for rename detection in step
> (4) in the off chance that an interesting path is missing from the
> parent.
Good explanation. As we are not supporting swapping o
On Wed, Aug 21, 2019 at 11:53:28AM -0400, Derrick Stolee wrote:
> On 8/21/2019 7:04 AM, SZEDER Gábor wrote:
> > With rename detection enabled the line-level log is able to trace the
> > evolution of line ranges across whole-file renames [1]. Alas, to
> > achieve that it uses the diff machinery ver
On Sat, Aug 17, 2019 at 10:38:46PM +0200, Martin Ågren wrote:
> On Sat, 17 Aug 2019 at 02:42, Emily Shaffer wrote:
> >
> > Add a new step to the build to generate a whitelist of git-config
> > variables which are appropriate to include in the output of
> > git-bugreport. New variables can be added
On 8/21/2019 1:35 PM, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 11:53:28AM -0400, Derrick Stolee wrote:
>> On 8/21/2019 7:04 AM, SZEDER Gábor wrote:
>>> With rename detection enabled the line-level log is able to trace the
>>> evolution of line ranges across whole-file renames [1]. Alas, to
>>
Am 21.08.19 um 16:56 schrieb Thomas Gummerer:
> On 08/20, Johannes Sixt wrote:
>> Am 20.08.19 um 08:56 schrieb Thomas Gummerer:
>>> Fix the test by updating the mtime of test.r, ...
>>
>>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>>> index e10f5f787f..66f75005d5 100755
>>> --- a/t
Denton Liu writes:
> Next, while we're at it, surround option arguments with <>.
I'd suggest squashing this in to complete the above.
cf.
---
Documentation/git-format-patch.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-format-patch.txt
Consider the following scenario:
git checkout not-the-master
work work work
git rebase --autostash upstream master
Here 'rebase --autostash ' incorrectly moves the
active branch (not-the-master) to master (before the rebase).
The expected behavior: (58794775:/git-rebase.sh:526)
A
Hi,
I have done some more tests on what's actually going on.
The active branch is currently reset to master (before the rebase)
The confusion was because of me naming the active branch 'upstream'
I hope this clears things up...
Ben Wijen (1):
rebase.c: make sure the active branch isn't moved
As we were integrating Git 2.23.0 into VFS for Git, we discovered that "git
checkout -b new-branch" went from 0.3s to 10+s on the Windows OS repo. This
was an intentional change when writing the "git switch" builtin. Here is the
commit message for 65f099b ("switch: no worktree status unless real br
From: Derrick Stolee
This reverts commit 65f099b3988198f0fdf3ef7a21dc01c556d21fff, which
removed logic for avoiding extra cost in "git checkout -b" in favor
of the new "git switch -c". This will cause a performance issue for
users in large repos.
Signed-off-by: Derrick Stolee
---
Documentation
From: Derrick Stolee
Recommend that users use 'git switch -c' instead.
Signed-off-by: Derrick Stolee
---
builtin/.checkout.c.swp | Bin 77824 -> 0 bytes
builtin/checkout.c | 9 -
2 files changed, 8 insertions(+), 1 deletion(-)
delete mode 100644 builtin/.checkout.c.swp
diff --
Denton Liu writes:
> Teach format-patch to use the first line of the branch description as
> the Subject: of the generated cover letter, rather than "*** SUBJECT
I would not say "the first line", as I do not think that is what
happens by calling pretty.c::format_subject(). The function is
desig
On 21/08/19 09:06AM, Bert Wesarg wrote:
> Dear Pratyush,
>
> putting me in Cc would have been nice :(
I wasn't sure if you were interested in git-gui any more, so I decided
to not bother you. I will Cc you when I send a re-roll.
> I will look into your patches in the comming hours.
Thanks.
On 20/08/19 11:19PM, Johannes Sixt wrote:
> Am 20.08.19 um 21:29 schrieb Pratyush Yadav:
> > On 20/08/19 09:21PM, Johannes Sixt wrote:
> >> Please don't do this. This confirmation dialog is unacceptable in my
> >> workflow. I use reversals of hunks and lines frequently, almost like a
> >> secondary
On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
wrote:
>
> This RFC includes a potential direction to make the sparse-checkout more
> user-friendly. While there, I also present a way to use a limited set of
> patterns to gain a significant performance boost in very large repositori
Junio C Hamano writes:
> Mischa POSLAWSKY writes:
>
>> If I understand correctly, such tags cannot be produced normally anymore.
>> Therefore I'm unsure how to make tests, and if that is even warranted.
>
> Thanks for spotting.
A quick trial to recreate a tag object seems to succeed:
$ git
On Wed, Aug 21, 2019 at 08:23:23PM +0200, Johannes Sixt wrote:
> Am 21.08.19 um 16:56 schrieb Thomas Gummerer:
> > On 08/20, Johannes Sixt wrote:
> >> Am 20.08.19 um 08:56 schrieb Thomas Gummerer:
> >>> Fix the test by updating the mtime of test.r, ...
> >>
> >>> diff --git a/t/t0021-conversion.sh
On Wed, Aug 21, 2019 at 12:18:33PM -0700, Derrick Stolee via GitGitGadget wrote:
> This reverts commit 65f099b3988198f0fdf3ef7a21dc01c556d21fff, which
> removed logic for avoiding extra cost in "git checkout -b" in favor
> of the new "git switch -c". This will cause a performance issue for
> users
This was discovered by one of my colleagues when using a partial clone.
I thought I had resolved the problem with the commits mentioned in patch
1 (e70a3030e7 and ancestors), but apparently that is not the case (that
only worked for native protocols). So here is a fix for HTTP.
I'm not sure of the
Commit e70a3030e7 ("fetch: do not list refs if fetching only hashes",
2018-10-07) and its ancestors taught Git, as an optimization, to skip
the ls-refs step when it is not necessary during a protocol v2 fetch
(for example, when lazy fetching a missing object in a partial clone, or
when running "git
The only transport that does not allow fetch() to be called before
get_refs_list() is the bundle transport. Clean up the code by teaching
the bundle transport the ability to do this, and removing support for
transports that don't support this order of invocation.
Signed-off-by: Jonathan Tan
---
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 branches, but I am still holding onto them.
The first batch of topics post 2.2
On Wed, Aug 21, 2019 at 12:18:32PM -0700, Derrick Stolee via GitGitGadget wrote:
> As we were integrating Git 2.23.0 into VFS for Git, we discovered that "git
> checkout -b new-branch" went from 0.3s to 10+s on the Windows OS repo.
Does this slowdown only affect the Windows OS repo with VFS for Gi
On Mon, Aug 19, 2019 at 10:50:24PM -0700, Junio C Hamano wrote:
> Bryan Turner writes:
>
> > Is there any way, with "git for-each-ref", to output the "fully"
> > peeled SHA of a tag's ultimate target, regardless of how many layers
> > must be traversed?
>
> I do not think I wrote it to allow di
On Wed, Aug 21, 2019 at 12:21 PM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> Recommend that users use 'git switch -c' instead.
>
> Signed-off-by: Derrick Stolee
> ---
> builtin/.checkout.c.swp | Bin 77824 -> 0 bytes
> builtin/checkout.c | 9 -
> 2 files c
Jeff King writes:
> There's this gem in ref-filter.c, which blames back to your 9f613ddd21
> (Add git-for-each-ref: helper for language bindings, 2006-09-15):
>
> /*
>* NEEDSWORK: This derefs tag only once, which
>* is good to deal with chains of trust, but
>
Hi,
On Wed, Aug 21, 2019 at 12:21 PM Derrick Stolee via GitGitGadget
wrote:
>
> As we were integrating Git 2.23.0 into VFS for Git, we discovered that "git
> checkout -b new-branch" went from 0.3s to 10+s on the Windows OS repo. This
> was an intentional change when writing the "git switch" built
On Wed, Aug 21, 2019 at 5:01 PM SZEDER Gábor wrote:
>
> On Wed, Aug 21, 2019 at 12:18:32PM -0700, Derrick Stolee via GitGitGadget
> wrote:
> > As we were integrating Git 2.23.0 into VFS for Git, we discovered that "git
> > checkout -b new-branch" went from 0.3s to 10+s on the Windows OS repo.
>
>
On Tue, Aug 20, 2019 at 02:39:24PM -0700, Jonathan Tan wrote:
> > Jonathan Tan writes:
> >
> > > In 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08),
> > > diff was taught to batch the fetching of missing objects when operating
> > > on a partial clone, but was not taught to refr
On Wed, Aug 21, 2019 at 08:07:29PM -0700, Junio C Hamano wrote:
> But after we learn that a ref "refs/tags/foo" points at a tag object
> that points at another tag object, what can the script do? It
> cannot feed the other tag found that way back into --format=%(*)
> machinery of for-each-ref, as
Hello, Confirm the receipt of my my first email as I am waiting to
hear from you.
Edwin.
48 matches
Mail list logo
