--
Dear friend.
I got your details after an extensive on-line search Via (Network
Power Charitable Trust) for a reliable person, I'm Mrs.Suzan Boni, a
57years old dying woman who was diagnosed for cancer about 4 years
ago, I have decided to donate my late husband fund the sum of
($500,000.00) to y
On Fri, Aug 23, 2019 at 12:01 AM Pratyush Yadav wrote:
>
> Just like the user can select lines to stage or unstage, add the
> ability to revert selected lines.
>
> Signed-off-by: Pratyush Yadav
> ---
> git-gui.sh | 25 -
> lib/diff.tcl | 31 ++---
On Fri, Aug 23, 2019 at 12:51 AM Pratyush Yadav wrote:
>
> On 22/08/19 03:34PM, Junio C Hamano wrote:
> > Pratyush Yadav writes:
> >
> > > This series adds the ability to revert selected lines and hunks in
> > > git-gui. Partially based on the patch by Bert Wesarg [0].
> > >
> > > The commits can
On Mon, Aug 19, 2019 at 02:26:19AM -0400, Denton Liu wrote:
> In 336226c259 (packfile.h: drop extern from function declarations,
> 2019-04-05), `extern` was removed from function declarations because
> it's redundant. However, in 8434e85d5f (repack: refactor pack deletion
> for future use, 2019-06
On Thu, Aug 22, 2019 at 04:44:37PM -0400, Christopher Sean Morrison wrote:
> We’re migrating a very large old repository to Git (the oldest in
> continuous development!) and using the notes feature to preserve Svn
> data like revision IDs and branch information. We’ve run into what
> seems like a
Try this:
# a repo with one file
git init repo
cd repo
echo base >file
git add file
git commit -m base
# now stash a modification
echo modified >file
git stash
# then make the file stat dirty. This will change inode; on systems
# without inodes, probably "sleep 1; touch fil
Aaron,
20.08.2019, 19:46, "Aaron Miller" :
>> Also, just FYI, as far as I know, git-p4 doesn't create "merge" commits,
>> so bidirectional integrations won't look different from ordinary commits in
>> git commit graph.
>
> Ah, I didn't realize that, thank you. Perhaps I should just sync each
>
Elijah Newren wrote:
> * Remove git-filter-branch from git.git. Mention in the release
> notes where people can go to get it.[1]
>
> filter-branch is not merely a slow or difficult-to-use tool, it's one
> that *fosters* mistakes by making it hard to get things right in
> several different ways
On 2019-08-22 at 14:04:16, Derrick Stolee wrote:
> On 8/18/2019 4:04 PM, brian m. carlson wrote:
> > diff --git a/midx.c b/midx.c
> > index d649644420..f29afc0d2d 100644
> > --- a/midx.c
> > +++ b/midx.c
> > @@ -19,8 +19,7 @@
> > #define MIDX_BYTE_NUM_PACKS 8
> > #define MIDX_HASH_VERSION 1
>
>
Thanks. That seems to help.
Just for context, we are using a copy-on-write/cloning solution to give
developers a prebuilt workspace with all the platforms fully built, as well as
sources all cloned,
So they are ready for incremental development.
We create a ext4 diskimage, with a git clone wor
On 22/08/19 03:34PM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> > This series adds the ability to revert selected lines and hunks in
> > git-gui. Partially based on the patch by Bert Wesarg [0].
> >
> > The commits can be found in the topic branch 'py/revert-hunks-lines'
> > at https://gi
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf
> Of
> Junio C Hamano
> Sent: Thursday, August 22, 2019 2:01 PM
> To: Keller, Jacob E
> Cc: git@vger.kernel.org; Jacob Keller
> Subject: Re: [PATCH] git-submodule: fix expansion of depth f
Pratyush Yadav writes:
> This series adds the ability to revert selected lines and hunks in
> git-gui. Partially based on the patch by Bert Wesarg [0].
>
> The commits can be found in the topic branch 'py/revert-hunks-lines'
> at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines
>
>
When the user updates any config variable from the options menu, the new
config gets saved, but the in-memory state of the config variables is
not updated. This results in the old settings being used until the user
either opens the options menu again (which triggers a call to
load_config), or re-st
Just like the user can select lines to stage or unstage, add the
ability to revert selected lines.
Signed-off-by: Pratyush Yadav
---
git-gui.sh | 25 -
lib/diff.tcl | 31 ++-
2 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/git
Just like the user can select a hunk to stage or unstage, add the
ability to revert hunks.
Signed-off-by: Pratyush Yadav
---
git-gui.sh | 14 +-
lib/diff.tcl | 34 +-
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/git-gui.sh b/git-gu
Upcoming commits will introduce reverting lines and hunks. They also
need to prompt the user for confirmation. Put the dialog creation in its
separate function so the same code won't be repeated again and again.
Signed-off-by: Pratyush Yadav
---
lib/index.tcl | 27 +--
1
When reverting files (or hunks or lines that future commits will add), a
confirmation dialog is shown to make sure the user actually wanted to
revert, and did not accidentally click revert.
But for some people's workflow this is an hindrance. So add an option to
disable this behaviour for people w
Hi,
This series adds the ability to revert selected lines and hunks in
git-gui. Partially based on the patch by Bert Wesarg [0].
The commits can be found in the topic branch 'py/revert-hunks-lines'
at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines
Once reviewed, pull the commits
Johannes Sixt writes:
> Inode number would be stable, but st_dev may not be. But it looks like a
> default build does not use it anyway (I see that we do not define
> USE_STDEV), so my guess was most likely wrong.
Ahh, thanks. I overlooked the device number, but I think the
default settings exc
Elijah Newren writes:
> Ooh, if you're going to open this door, then a proposal I assumed
> would be shot down but which I'd be just about as happy with is:
>
> * Remove git-filter-branch from git.git. Mention in the release
> notes where people can go to get it.[1]
> ...
Yup, I think, especi
Am 22.08.19 um 21:32 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 22.08.19 um 20:02 schrieb Saravanan Shanmugham (sarvi):
>>> We have a diskimage/fileysystem that has a 50G Git repository + 900G
>>> of binary/build articles and untracked files. When we mount such a
>>> diskimage, The v
On Thu, Aug 22, 2019 at 1:24 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Questions, comments, or concerns with this proposal? Alternative
> > proposals? If inclusion is acceptable, are there any other tasks that
> > need to be completed first?
>
> I do not want a discussion to begi
Jacob Keller writes:
> From: Jacob Keller
>
> The depth variable already contains "--depth=", so expanding it with an
> additional --depth when invoking the update-clone git submodule--helper
> is incorrect.
>
> Signed-off-by: Jacob Keller
> ---
>
> I'm *reasonably* sure this is correct, but I
Hi,
We’re migrating a very large old repository to Git (the oldest in continuous
development!) and using the notes feature to preserve Svn data like revision
IDs and branch information. We’ve run into what seems like an incomplete
feature or bug in that notes get orphaned/disassociated if an o
From: Jacob Keller
The depth variable already contains "--depth=", so expanding it with an
additional --depth when invoking the update-clone git submodule--helper
is incorrect.
Signed-off-by: Jacob Keller
---
I'm *reasonably* sure this is correct, but I am not sure how to test it.
It's possibl
Elijah Newren writes:
> Questions, comments, or concerns with this proposal? Alternative
> proposals? If inclusion is acceptable, are there any other tasks that
> need to be completed first?
I do not want a discussion to begin with a Devil's Advocate
response, but anyway...
Are we planning to
Denton Liu writes:
> While we're at it, perform some major cleanup of t4014 including some
> stylistic cleanup and also, unmasking of Git return codes.
Wow. It seems that "while we're at it" grew quite large and (from
purely patch count's point of view) ends up appearing as if it were
the prima
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.
>
> Signed-off-by: Thomas Gummerer
> ---
>
> v2 adds the comment as suggested by Szeder.
>
> Junio: I saw this is marke
Johannes Sixt writes:
> Am 22.08.19 um 20:02 schrieb Saravanan Shanmugham (sarvi):
>> We have a diskimage/fileysystem that has a 50G Git repository + 900G
>> of binary/build articles and untracked files. When we mount such a
>> diskimage, The verify first “git status” command can take as long
>>
In t0021.15 one of the things we are checking is that the clean filter
is run when checking out empty-branch. The clean filter needs to be
run to make sure there are no modifications on the file system for the
test.r file, and thus it isn't dangerous to overwrite it.
However in the current test s
Am 22.08.19 um 20:02 schrieb Saravanan Shanmugham (sarvi):
> We have a diskimage/fileysystem that has a 50G Git repository + 900G
> of binary/build articles and untracked files. When we mount such a
> diskimage, The verify first “git status” command can take as long
> 40-50minutes. Subsequent “git
Am 22.08.19 um 19:49 schrieb Thomas Gummerer:
> Right, the above is why I think 'touch' is a good idea here. Short of
> system clocks jumping around, which will most likely break more than
> this test anyway it guarantees that the timestamp is equal or greater
> than the timestamp of the index, wh
On 19/08/2019 17:09, Eric Sunshine wrote:
On Mon, Aug 19, 2019 at 5:18 AM Phillip Wood via GitGitGadget
wrote:
Adapt try_to_commit() to create a new root commit rather than special
casing this in run_git_commit(). The significantly reduces the amount of
s/The/This/
Thanks Eric - well spotte
On 22/08/19 10:08AM, Emily Shaffer wrote:
> On Thu, Aug 22, 2019 at 09:58:48AM -0700, Bryan Turner wrote:
> > On Thu, Aug 22, 2019 at 5:32 AM Giuseppe Crinò wrote:
> > >
> > > Note how `git log` discards the ending quote character:
> >
> >
> >
> > > root@NBR1710R:~/repo# git add foo
> > > root@
Hi everyone,
git-filter-repo[1] is a tool for rewriting or restructuring git
history. The recent Git Rev News article[2] on filter-repo introduced
it and explained how it is much more versatile than git-filter-branch
or BFG Repo Cleaner, and with speed comparable to BFG. (I probably
also should
"Saravanan Shanmugham (sarvi)" writes:
> I suspect warming the filesystem caching is in play.
> But so is the fact that walk every tree to find untracked files as well.
Enable the untracked cache and "update-index --refresh", before
freezing the repository + working tree state in the diskimage?
Mischa POSLAWSKY writes:
> Junio wrote:
>>
>> Mischa POSLAWSKY writes:
>> > Strip an annotated tag of its tagger header and verify it's ignored
>> > correctly in all cases, as fixed in commit e2a81276e8 (ref-filter:
>> > initialize empty name or email fields, 2019-08-19).
>>
>> I am inclined t
Thomas Gummerer writes:
>> # Make sure that the file appears dirty, so checkout below has to
>> # run the configured filter.
>> test-tool chmtime =-10 .git/index &&
>> test-tool chmtime =+0 test.r &&
>
> I think the comment is a good idea. I personally still prefer just
> using 'touch' t
We have a diskimage/fileysystem that has a 50G Git repository + 900G of
binary/build articles and untracked files.
When we mount such a diskimage, The verify first “git status” command can take
as long 40-50minutes.
Subsequent “git status” finish in under 5-10 seconds.
If I had a diskimage of
On 08/22, SZEDER Gábor wrote:
> 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, ...
> > >>
> This probably is totally off-tangent, but do any of these "let's
> advertise fewer" changes at the protocol level have to take into
> account the use of --prune option on the client side?
I don't think so. According to what I understand from the documentation,
the prune option prunes based on th
On Thu, Aug 22, 2019 at 09:58:48AM -0700, Bryan Turner wrote:
> On Thu, Aug 22, 2019 at 5:32 AM Giuseppe Crinò wrote:
> >
> > Note how `git log` discards the ending quote character:
>
>
>
> > root@NBR1710R:~/repo# git add foo
> > root@NBR1710R:~/repo# git commit -m 'first'
> > [master (root-com
On Thu, Aug 22, 2019 at 12:29:08PM -0400, Jeff King wrote:
> On Thu, Aug 22, 2019 at 06:07:02PM +0200, SZEDER Gábor wrote:
>
> > On Thu, Aug 22, 2019 at 10:20:08AM -0400, Charles Diza wrote:
> > > By 2.22.1 at the latest (and continuing into 2.23.0) there is a
> > > problem with the display of prog
Hi,
On Thu, Aug 22, 2019 at 06:07:02PM +0200, SZEDER Gábor wrote:
> On Thu, Aug 22, 2019 at 10:20:08AM -0400, Charles Diza wrote:
> > By 2.22.1 at the latest (and continuing into 2.23.0) there is a
> > problem with the display of progress indication during `git pull`
> > (and possibly other comman
On Thu, Aug 22, 2019 at 09:25:34AM -0700, Jonathan Tan wrote:
> > The batch fetch is purely an optimization, because we'd eventually fetch
> > the individual objects on demand. If the batch one fails, should we
> > continue with the operation? That leaves any error-handling for the
> > overall ope
On Thu, Aug 22, 2019 at 06:40:32PM +0200, SZEDER Gábor wrote:
> > Yes, we moved to v2.22.1 last night. I'll revert those commits on our
> > servers until we come up with a more permanent solution upstream.
>
> I think it's sufficient to revert only 5b12e3123b (progress: use
> term_clear_line(), 2
On Thu, Aug 22, 2019 at 5:32 AM Giuseppe Crinò wrote:
>
> Note how `git log` discards the ending quote character:
> root@NBR1710R:~/repo# git add foo
> root@NBR1710R:~/repo# git commit -m 'first'
> [master (root-commit) a78e11f] first
> Committer: Les Actualite
If you look closely here, in t
On 8/22/2019 12:26 PM, SZEDER Gábor wrote:
> On Thu, Aug 22, 2019 at 09:01:44AM -0700, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>>> Well, that fruit hung much lower than I though, just look at the size
>>> of the WIP patch below. I just hope that there are no unexpected
>>> surprises, but
On Thu, Aug 22, 2019 at 12:29:08PM -0400, Jeff King wrote:
> On Thu, Aug 22, 2019 at 06:07:02PM +0200, SZEDER Gábor wrote:
> > I noticed this today when pushing to GitHub (I suppose they have very
> > recently upgraded?) from Linux, so this is neither specific to 'git
> > pull' nor to macOS.
> >
>
On Thu, Aug 22, 2019 at 06:07:02PM +0200, SZEDER Gábor wrote:
> On Thu, Aug 22, 2019 at 10:20:08AM -0400, Charles Diza wrote:
> > By 2.22.1 at the latest (and continuing into 2.23.0) there is a
> > problem with the display of progress indication during `git pull`
> > (and possibly other commands,
Jonathan Tan writes:
> 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
Junio wrote:
>
> Mischa POSLAWSKY writes:
> > Strip an annotated tag of its tagger header and verify it's ignored
> > correctly in all cases, as fixed in commit e2a81276e8 (ref-filter:
> > initialize empty name or email fields, 2019-08-19).
>
> I am inclined to squash this test part of the updat
On Thu, Aug 22, 2019 at 09:01:44AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > Well, that fruit hung much lower than I though, just look at the size
> > of the WIP patch below. I just hope that there are no unexpected
> > surprises, but FWIW it produces the exact same output for al
> I wondered what would happen when it does not succeed. It looks like the
> whole diff process just dies.
>
> The batch fetch is purely an optimization, because we'd eventually fetch
> the individual objects on demand. If the batch one fails, should we
> continue with the operation? That leaves a
Pratyush Yadav writes:
> This strbuf_addstr_without_crud() function removes various characters
> from the start and end of the author info, one of which is the single
> quotation. I'm not sure why this is done, the more experienced folk
> where will have the answer.
The logic there exists in
Mischa POSLAWSKY writes:
> Alright, thanks for the pointer.
> Here's a batch of tests on all pertaining atoms.
Good to see that you made it much more thorough than my q-n-d
illustration patch ;-)
> -- >8 --
>
> Strip an annotated tag of its tagger header and verify it's ignored
> correctly in a
On Thu, Aug 22, 2019 at 10:20:08AM -0400, Charles Diza wrote:
> By 2.22.1 at the latest (and continuing into 2.23.0) there is a
> problem with the display of progress indication during `git pull`
> (and possibly other commands, I don't know).
>
> I'm on macOS, and this happens in both Terminal.app
Am 22.08.19 um 14:32 schrieb Giuseppe Crinò:
> name = Les Actualite\\'
You can name yourself anything you like, of course, and I don't actually
speak French, but wouldn't it rather be "L'actualité"?
I just reply as a fellow accent-bearer, feel free to ignore me..
René
SZEDER Gábor writes:
> Well, that fruit hung much lower than I though, just look at the size
> of the WIP patch below. I just hope that there are no unexpected
> surprises, but FWIW it produces the exact same output for all files up
> to 't/t5515' in v2.23.0 as the previous patch.
>
> Can't wait
"brian m. carlson" writes:
> On 2019-08-20 at 21:12:00, René Scharfe wrote:
>> So perhaps this on top? (Or squash it in, if you like, but it's
>> certainly not worth a re-roll.)
>
> Yeah, this seems sensible. I'll include it if I do a re-roll.
Thanks.
Johannes Schindelin writes:
>> As with this commit the reset must never change the active branch,
>> the 'HEAD is now at ...' message has now been removed.
>
> Actually, I am not so sure that I like this change.
>
> Previously, users had a chance to figure out to which revision the
> worktree was
On 22/08/19 02:32PM, Giuseppe Crinò wrote:
> Note how `git log` discards the ending quote character:
> ```
> root@NBR1710R:~# git init repo
> Initialized empty Git repository in /root/repo/.git/
> root@NBR1710R:~# cd repo/
> root@NBR1710R:~/repo# git config user.name Les Actualite\'
> root@NBR1710R
On 8/22/2019 4:41 AM, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 07:35:15PM +0200, SZEDER Gábor wrote:
>> So line-level log clearly computes a lot less diffs than
>> '--full-history', though still about 50% more than a regular
>> pathspec-limited history traversal. Looking at the commit-parent
Hi,
On Tue, 20 Aug 2019, René Scharfe wrote:
> Define enum parse_opt_result before using it in a typedef. This avoids
> the following compiler warning:
>
>./parse-options.h:53:14: error: ISO C forbids forward references to 'enum'
> types [-Werror,-Wpedantic]
>typedef enum parse_opt_resu
On 8/22/2019 9:10 AM, Derrick Stolee wrote:
> On 8/21/2019 5:52 PM, Elijah Newren wrote:
>> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
>>> For example, if we add A/B/C as a recursive folder, then we add the
>>> following patterns to the sparse-checkout file:
>>>
>>> /*
>>> !/*/
By 2.22.1 at the latest (and continuing into 2.23.0) there is a problem with
the display of progress indication during `git pull` (and possibly other
commands, I don't know).
I'm on macOS, and this happens in both Terminal.app and iTerm2.app, on both
macOS 10.13.6 and 10.14.6: In a standard 80
On 8/18/2019 4:04 PM, brian m. carlson wrote:
> Instead of hard-coding the hash size, use the_hash_algo to look up the
> hash size at runtime. Remove the #define constant which was used to
> hold the hash length, since writing the expression with the_hash_algo
> provide enough documentary value on
Junio wrote:
> 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 ob
On 8/21/2019 11:16 PM, Elijah Newren wrote:
> 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 a
On 8/21/2019 6:31 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.
>
> Does this slo
On 8/21/2019 6:15 PM, SZEDER Gábor wrote:
> 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"
Junio wrote:
> Junio C Hamano writes:
>
> > Mischa POSLAWSKY writes:
> >
> >> Formatting $(taggername) on headerless tags such as v0.99 in Git
> >> causes a SIGABRT with error "munmap_chunk(): invalid pointer",
> >> because of an oversight in commit f0062d3b74 (ref-filter: free
> >> item->value
On 8/21/2019 5:52 PM, Elijah Newren wrote:
> 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 sig
Note how `git log` discards the ending quote character:
```
root@NBR1710R:~# git init repo
Initialized empty Git repository in /root/repo/.git/
root@NBR1710R:~# cd repo/
root@NBR1710R:~/repo# git config user.name Les Actualite\'
root@NBR1710R:~/repo# cat .git/config
[core]
repositoryformatv
Hi Ben,
On Wed, 21 Aug 2019, Ben Wijen wrote:
> 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)
On Wed, Aug 21, 2019 at 07:35:15PM +0200, SZEDER Gábor wrote:
> So line-level log clearly computes a lot less diffs than
> '--full-history', though still about 50% more than a regular
> pathspec-limited history traversal. Looking at the commit-parent
> pairs in the output, it appears that the diff
77 matches
Mail list logo
