From: Johannes Schindelin
This should be more reliable than the current method, and prepares the
test suite for a consistent way to clean up before re-running the tests
with different options.
Signed-off-by: Johannes Schindelin
---
t/lib-git-p4.sh| 10 +-
t
From: Johannes Schindelin
This makes use of the just-introduced consistent way to specify that a
long-running process needs to be terminated at the end of a test script
run.
Signed-off-by: Johannes Schindelin
---
t/interop/i5500-git-daemon.sh | 1 -
t/lib-git-daemon.sh | 3 +--
t
Hi Stolee,
On Fri, 12 Oct 2018, Derrick Stolee wrote:
>
> In an effort to ensure new code is reasonably covered by the test suite, we
> now have contrib/coverage-diff.sh to combine the gcov output from 'make
> coverage-test ; make coverage-report' with the output from '
ven with '{caret}' in front are
> +subtracted from that set. The remaining objects are what come out in the
> command's output. Various other options and paths parameters can be used
> to further limit the result.
I am not sure if this is a good rewrite. It gives a false
impression as if
Hello,
This is a new iteration of `git stash`, based on the last review.
This iteration fixes some code styling issues, bring some changes
to `do_push_stash()` and `do_create_stash()` to be closer to API by
following Thomas Gummerer's review of last iteration [1]. Also, there
were some missing
This commit introduces tests for `git stash show`
config. It tests all the cases where `stash.showStat`
and `stash.showPatch` are unset or set to true / false.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3907-stash-show-config.sh | 83
1 file changed, 83
On 10/12, Farhan Khan wrote:
> Hi all,
>
> Does git load the entire index file into memory when it wants to
> edit/view it? I ask because I wonder if this can become a problem with
> the index file becomes arbitrarily large, like for the Linux kernel.
Yes, currently git always l
Sergey Andreenko writes:
> git.exe diff --numstat "C:\diff" "C:\base"
> ...
> output will be:
>
> 0 1 {iff => ase}/1.txt
>
> So (folder_name_length) symbols were cut from the path (“C:\\d” and “C:\\b”).
>
> Is any way
Hello,
I'm writing a remote helper and decided implement the `fetch` and `push`
capabilities,
but one thing still remains a mystery for me. Namely, is my helper supposed
to instantiate and pin git objects in `GIT_DIR` upon `fetch `?
In general I'm trying to determine how exactly I need
Lily Ballard writes:
> I haven’t checked any other commands that the glossary lists as
> taking pathspecs (except `git add`, which does properly list it as
> taking pathspecs), so I don’t know if any of the other commands
> incorrectly list themselves as taking files when they take
he current discussion:
https://github.com/travis-ci/travis-ci/issues/10210
BTW: on reading the git mailing list a suggestion seems to be to ask
the server operator (GitHub in this case) to set:
"git config uploadpack.allowReachableSHA1InWant 1"
Apparently this has some security implication
> On large repositories with lots of tags - git wire protocol v2 fails
> to fetch shallow changes, it fails with error `pack has XXX unresolved
> deltas`. Unfortunately I didn't find easy way to reproduce it except
> cloning+fetching chromium repository, the way jenkins does.
> Rep
git diff –numstat FOLDER1 FOLDER2 works strange when run from a git
controlled folder.
The output shrinks some symbols in the diff file paths.
For example:
Create a folder and call git init, for example: `C:\test`.
mkdir C:\test
cd C:\test
git init
he function p4BranchesInGit().
> >
> > Instead, put the unshelved changes into refs/remotes/p4-unshelved/.
>
> I am not a p4 user (and not a git-p4 user), so it is a bit hard for
> me to assess if this is a backward incompatibile change and if so
> how serious potential break
Hi all,
Does git load the entire index file into memory when it wants to
edit/view it? I ask because I wonder if this can become a problem with
the index file becomes arbitrarily large, like for the Linux kernel.
Thanks,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC
es/p4-unshelved/.
I am not a p4 user (and not a git-p4 user), so it is a bit hard for
me to assess if this is a backward incompatibile change and if so
how serious potential breakage to existing users would be.
>
> -If the target branch in refs/remotes/p4/unshelved already e
In an effort to ensure new code is reasonably covered by the test suite,
we now have contrib/coverage-diff.sh to combine the gcov output from
'make coverage-test ; make coverage-report' with the output from 'git
diff A B' to discover _new_ lines of code that are not covered.
This report
Johannes Schindelin writes:
> On Sun, 7 Oct 2018, Junio C Hamano wrote:
>
>> And then there is an unnamed misdesigned language that has a
>> regmatch() function, which takes a string that contains a regular
>> expression, but somehow requires that string to begin and end with a
>> slash for no
Hi Junio,
On Sun, 7 Oct 2018, Junio C Hamano wrote:
> And then there is an unnamed misdesigned language that has a
> regmatch() function, which takes a string that contains a regular
> expression, but somehow requires that string to begin and end with a
> slash for no justifiable reason ;-).
It
The previous git-p4 unshelve support would check for changes
in Perforce to the files being unshelved since the original
shelve, and would complain if any were found.
This was to ensure that the user wouldn't end up with both the
shelved change delta, and some deltas from other changes
This patch series teaches the git-p4 unshelve command to handle
intervening changes to the Perforce files.
At the moment if you try to unshelve a file, and that file has been
modified since the shelving, git-p4 refuses. That is so that it
doesn't end up generating a commit containing deltas from
If deleting or moving a file, sometimes P4 doesn't report the file size.
The code handles this just fine but some logging crashes. Stop this
happening.
There was some earlier discussion on the list about this:
https://public-inbox.org/git/xmqq1sqpp1vv@gitster.mtv.corp.google.com/
Signed
---
Documentation/git-p4.txt | 6 +++---
git-p4.py| 3 ++-
t/t9832-unshelve.sh | 6 +++---
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 41780a5aa9..c7705ae6e7 100644
--- a/Documentation/git-p4.txt
git-rev-list has a mode where it works on the granularity of trees and
blobs, rather than commits only. When discussing this mode in
documenation, it can get awkward to refer to the list of arguments that
may include blobs and trees as . It is especially awkward in a
follow-up patch, so prepare
This is definitely a low-level command, it's hard to argue
against it belonging in plumbing.
Signed-off-by: Daniels Umanovskis
---
command-list.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/command-list.txt b/command-list.txt
index c36ea3c18..966705358 100644
Also remove git-cherry from Bash completion because plumbing
commands do not belong there.
Signed-off-by: Daniels Umanovskis
---
Up to discussion whether cherry should be considered plumbing.
I lean towards considering it a rarely-used porcelain command, but
a case could be made either way so
9901
I don't think it implies that.
The last comment starts with "Code calls git fetch periodically". I
presume that it does so in the background (to prevent blocking the UI
until 'git fetch' runs), therefore 'git gc --auto' starts already in
the background. Furthermore, notice that 'git prun
Hi Ævar
On 11/10/2018 11:08, Ævar Arnfjörð Bjarmason wrote:
On Thu, Oct 11 2018, Phillip Wood wrote:
Hi Ævar
On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:
Expand on the work started in 095c741edd ("commit: run git gc --auto
just before the post-commit hook", 2018-02-28)
:
>> >> Expand on the work started in 095c741edd ("commit: run git gc --auto
>> >> just before the post-commit hook", 2018-02-28) to run "gc --auto" in
>> >> more commands where new objects can be created.
>> >>
>> >> The nota
On Thu, Oct 11, 2018 at 12:08:47PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Oct 11 2018, Phillip Wood wrote:
>
> > Hi Ævar
> >
> > On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:
> >> Expand on the work started in 095c741edd ("commit: ru
On Thu, Oct 11 2018, Phillip Wood wrote:
> Hi Ævar
>
> On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:
>> Expand on the work started in 095c741edd ("commit: run git gc --auto
>> just before the post-commit hook", 2018-02-28) to run "gc --auto"
Hi,
I use git-repo which makes use of Git for Windows and also uses the
gpg tool bundled in Git for Windows.
I am able to run the git-repo with Git-2.18.0-64-bit.exe, but recently
I updated the Git to new release of Git for Windows 2.19.1 and that
does not work with git-repo tool. I found
Hi Ævar
On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:
> Expand on the work started in 095c741edd ("commit: run git gc --auto
> just before the post-commit hook", 2018-02-28) to run "gc --auto" in
> more commands where new objects can be created.
>
> T
Hello,
On large repositories with lots of tags - git wire protocol v2 fails
to fetch shallow changes, it fails with error `pack has XXX unresolved
deltas`. Unfortunately I didn't find easy way to reproduce it except
cloning+fetching chromium repository, the way jenkins does.
Reproduction steps
`git ls-files` takes zero or more s, but the manpage (and the `-h`
output) lists it as taking zero or more s instead. This is confusing as
is documented in `man git` as a filename, without any magic. But a
pathspec has a lot of special handling. The gitglossary entry for pathspec does
say
Daniels Umanovskis writes:
> On 10/11/18 12:26 AM, Junio C Hamano wrote:
>> Among the remaining ones in the list, cherry and get-tar-commit-id
>> are probably better classified as plumbing. I do not know why
>> cherry is marked for completion; perhaps some crazy people use that
>> on the
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Thu, Oct 04, 2018 at 11:09:58PM -0700, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>> >> git-gc - Cleanup unnecessary files and optimize the local repository
>> >>
>> >> Creating these
On 10/11/18 12:26 AM, Junio C Hamano wrote:
> Among the remaining ones in the list, cherry and get-tar-commit-id
> are probably better classified as plumbing. I do not know why
> cherry is marked for completion; perhaps some crazy people use that
> on the command line?
I think cherry could go
Daniels Umanovskis writes:
> git-rev-parse mostly seems like plumbing, and is more usd in
> scripts than in regular use. Online it's often mentioned as
> a plumbing command. Nonetheless it's listed under porcelain
> interrogators in `man git`. It seems appropriate to formally
&g
On Thu, Oct 04, 2018 at 11:09:58PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> git-gc - Cleanup unnecessary files and optimize the local repository
> >>
> >> Creating these indexes like the commit-graph falls under "optimize the
> >
This patch started as a refactoring to make 'get_next_submodule' more
readable, but upon doing so, I realized that "git fetch" of the submodule
actually doesn't need to be run in the submodules worktree. So let's run
it in its git dir instead.
That should pave the way towards fetching
git-rev-parse mostly seems like plumbing, and is more usd in
scripts than in regular use. Online it's often mentioned as
a plumbing command. Nonetheless it's listed under porcelain
interrogators in `man git`. It seems appropriate to formally
move git-rev-parse to plumbing interrogators.
Signed
Expand on the work started in 095c741edd ("commit: run git gc --auto
just before the post-commit hook", 2018-02-28) to run "gc --auto" in
more commands where new objects can be created.
The notably missing commands are now "rebase" and "stash". Both are
r the user about what he wants, but probably not via
>> gc --auto emitting the same warning every time, e.g. in one of these
>> threads I suggested maybe "git status" should emit this.
>
> I have to say, I don't have a lot of sympathy for this.
>
> I've been running wi
Hello,
Am 10.10.2018 um 01:38 schrieb Артем Семенов:
> Hello.
>
> Git svn bug on merging svn branches:
>
> Svn repository (branches tag trunk).
>
> 1. Add a some file by svn tools.
> 2. Create a new branch by svn tools (e.g. br1) .
> 3. Create a new branch by svn to
ster the user about what he wants, but probably not via
> > gc --auto emitting the same warning every time, e.g. in one of these
> > threads I suggested maybe "git status" should emit this.
>
> I have to say, I don't have a lot of sympathy for this.
>
> I've b
same warning every time, e.g. in one of these
> threads I suggested maybe "git status" should emit this.
I have to say, I don't have a lot of sympathy for this.
I've been running with the patches I sent before for a while now, and
the behavior that they create is great. I think we can
On Wed, Oct 10, 2018 at 8:21 AM Junio C Hamano wrote:
> We probably can keep the "let's not run for a day" safety while
> pretending that "git gc -auto" succeeded for callers like "git svn"
> so that these callers do not hae to do "eval { ...
On 2018-10-07 2:08 am, Junio C Hamano wrote:
Steve writes:
Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list`
command:
--name-status --oneline --patch-with-stat
Signed-off-by: Steven Fernandez
g again in ~3 minutes when you run your next command.
>
> We probably can keep the "let's not run for a day" safety while
> pretending that "git gc -auto" succeeded for callers like "git svn"
> so that these callers do not hae to do "eval { ... }" to hid
Christian Couder writes:
> So I think one solution to this problem is already proposed on our web site.
OK, that's a good start. The next step is to make those who are
involved in these education programs to be more aware of it ;-)
t;"gc --auto" we'll fork to the background, peg a core at 100% CPU for
>2-3 minutes or whatever it is, only do get nowhere and do the same
>thing again in ~3 minutes when you run your next command.
We probably can keep the "let's not run for a day"
On Wed, Oct 10 2018, Martin Langhoff wrote:
> On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason
> wrote:
>> As Jeff's
>> https://public-inbox.org/git/20180716175103.gb18...@sigill.intra.peff.net/
>> and my https://public-inbox.org/git/878t69dgvx@evledraar
g
>> - as the warning is gone, no gc.log is produced
>> - subsequent gc runs don't exit due to gc.log
>>
>> My very humble +1 on that.
>>
>> As for downsides... if we have truly tons of _recent_ loose objects,
>> it'll ... take disk space? I'm fine with that.
>
&g
On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason
wrote:
> As Jeff's
> https://public-inbox.org/git/20180716175103.gb18...@sigill.intra.peff.net/
> and my https://public-inbox.org/git/878t69dgvx@evledraar.gmail.com/
> note it's a bit more complex than that.
Ok, my bad for
't exit due to gc.log
>
> My very humble +1 on that.
>
> As for downsides... if we have truly tons of _recent_ loose objects,
> it'll ... take disk space? I'm fine with that.
As Jeff's
https://public-inbox.org/git/20180716175103.gb18...@sigill.intra.peff.net/
and my https://public-inbox
For consistency, add full stops in a few places and outdent a line by
one space.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-send-email.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
have truly tons of _recent_ loose objects,
it'll ... take disk space? I'm fine with that.
For more aggressive gc options, thoughts:
- Do we always consider git gc --prune=now "safe" in a "won't delete
stuff the user is likely to want" sense? For example -- are the
referen
On Wed, Oct 10, 2018 at 10:46 AM Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
> > Personally, I find the "whoever is picking it up should do the thinking"
> > much too harsh for a first-time contributor who specifically came through
> > the Outreachy program, i.e. expected to have a
Johannes Schindelin writes:
> Personally, I find the "whoever is picking it up should do the thinking"
> much too harsh for a first-time contributor who specifically came through
> the Outreachy program, i.e. expected to have a gentle introduction into
> the project, and into the ways we work.
ote:
> >> Hi All,
> > Hello, Ananya! Welcome.
> >
> >> I was searching through #leftovers and found this.
> >> https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
> >>
> >> This patch add
On Tue, Oct 09 2018, Martin Langhoff wrote:
> Hi folks,
>
> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
> I hit the gc error:
>
> warning: There are too many unreachable loose objects; run 'git prune'
> to remove them.
> gc --auto: command r
he gc error:
>>
>> warning: There are too many unreachable loose objects; run 'git prune'
>> to remove them.
>> gc --auto: command returned error: 255
>
> GC can be annoying when that happens... For git-svn, perhaps
> this can be appropriate to at least allow the import to
esolve,
and when that happens what does it return? "HEAD"? Can the
caller tell the case in which .git/HEAD is a symref that points
at refs/heads/HEAD (i.e. we are on a branch whose name is "HEAD")
and the case in which .git/HEAD fails to resolve and you get
&
Hello.
Git svn bug on merging svn branches:
Svn repository (branches tag trunk).
1. Add a some file by svn tools.
2. Create a new branch by svn tools (e.g. br1) .
3. Create a new branch by svn tools on branch br1 (e.g. br2).
4. Add some changes to file f1 in branch br1. Commit by svn tools.
5
Martin Langhoff wrote:
> Hi folks,
>
> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
> I hit the gc error:
>
> warning: There are too many unreachable loose objects; run 'git prune'
> to remove them.
> gc --auto: command returned error: 255
Hi folks,
Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
I hit the gc error:
warning: There are too many unreachable loose objects; run 'git prune'
to remove them.
gc --auto: command returned error: 255
I don't seem to be the only one --
https://stackoverflow.com
eed, that's what I did.
> But what about "*.c"? I
> don't think a bloom filter can answer that.
Surely not, but it could easily return "maybe", and thus simply fall
back to look at the diff.
However, I've looked through the output of
grep '^git log[^|]*[\[*?]' ~
es me a starting point to try the Bloom filter approach
> and see what the numbers are like. You did all the "git" stuff like
> computing the changed paths, so thanks!
Great, I hope it can be useful. I almost wrote it as perl consuming the
output of "log --format=%h --nam
y. I think it's only feasible if we give
up sorting, and then I wonder what other problems that might cause.
The patch below gives me a starting point to try the Bloom filter
approach and see what the numbers are like. You did all the "git" stuff
like computing the changed paths, so thanks!
not be out of the question to store
bitmaps like this. I'm much more worried about the maintenance cost of
adding new entries incrementally. I think it's only feasible if we give
up sorting, and then I wonder what other problems that might cause.
-Peff
-- >8 --
diff --git a/Makefile b/Makefile
i
On Tue, Oct 09 2018, Derrick Stolee wrote:
> The filter needs to store every path that would be considered "not
> TREESAME". It can't store wildcards, so you would need to evaluate the
> wildcard and test all of those paths individually (not a good idea).
If full paths are stored, yes, But
Signed-off-by: Daniels Umanovskis
---
Documentation/git-branch.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bf5316ffa..a7167df74 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git
On Tue, Oct 9, 2018 at 7:33 AM Ντέντος Σταύρος wrote:
>
> I have install the latest git version from the PPA:
> $ git --version
> git version 2.19.1
> $ lsb_release -rd
> Description: Ubuntu 16.04.5 LTS
> Release: 16.04
>
> However, trying to autocomplete git difftool
I have install the latest git version from the PPA:
$ git --version
git version 2.19.1
$ lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04
However, trying to autocomplete git difftool --cached gives:
$ env -i bash --rcfile /etc/profile
$ . /usr/share/bash-completion/completions/git
>> look in remove, added, or both lines).
> >
> > Yeah, here is a lunchtime hack that hasn't even been compile tested.
> >
> > diff.c | 4
> > diff.h | 2 ++
> > diffcore-pickaxe.c | 22 --
> > 3 files changed, 2
(Changing title to reflect the new topic.)
On 10/8/2018 11:08 PM, Jeff King wrote:
On Mon, Oct 08, 2018 at 02:29:47PM -0400, Derrick Stolee wrote:
There are two questions that I was hoping to answer by looking at
your code:
1. How do you store your Bloom filter? Is it connected to the
ed.
>
> diff.c | 4
> diff.h | 2 ++
> diffcore-pickaxe.c | 22 --
> 3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index f0c7557b40..d1f2780844 100644
> --- a/diff.c
> +++ b/diff.c
This documents the existing behaviour of "git help cmd" when cmd is an
alias, as well as providing a hint to use the "git cmd --help" form to
be taken directly to the man page for the aliased command.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-help.txt | 4 +++
As discussed in the thread for v1 of this patch [1] [2], this changes the
rules for "git foo --help" when foo is an alias.
(1) When invoked as "git help foo", we continue to print the "foo is
aliased to bar" message and nothing else.
(2) If foo is an alias f
Derrick Stolee writes:
> On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
>> Hi All,
> Hello, Ananya! Welcome.
>
>> I was searching through #leftovers and found this.
>> https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.co
On Mon, 8 Oct 2018, Jacob Keller wrote:
> On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote:
> >
> > On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
> >
> > > Julia Lawall writes:
> > >
> > > >> Doing the same for -S is much harder at the machinery level, as it
> > > >> performs
--
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index f0c7557b40..d1f2780844 100644
--- a/diff.c
+++ b/diff.c
@@ -5068,6 +5068,10 @@ int diff_opt_parse(struct diff_options *options,
}
else if (!strcmp(arg, "--pickaxe-all"))
On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote:
>
> On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
>
> > Julia Lawall writes:
> >
> > >> Doing the same for -S is much harder at the machinery level, as it
> > >> performs its thing without internally running "diff" twice, but just
On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
> Julia Lawall writes:
>
> >> Doing the same for -S is much harder at the machinery level, as it
> >> performs its thing without internally running "diff" twice, but just
> >> counts the number of occurrences of 'foo'---that is
On Mon, Oct 08, 2018 at 02:29:47PM -0400, Derrick Stolee wrote:
> > > > But I'm afraid it will take a while until I get around to turn it into
> > > > something presentable...
> > > Do you have the code pushed somewhere public where one could take a look?
> > > I
> > > Do you have the code
On Mon, 8 Oct 2018 at 22:43, Derrick Stolee wrote:
>
> On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
> > Hi All,
> Hello, Ananya! Welcome.
>
> > I was searching through #leftovers and found this.
> > https://public-inbox.org/git/cabpp-bgvvxcbzx44e
Julia Lawall writes:
>> Doing the same for -S is much harder at the machinery level, as it
>> performs its thing without internally running "diff" twice, but just
>> counts the number of occurrences of 'foo'---that is sufficient for
>> its intended use, and more efficient.
>
> There is still the
SZEDER Gábor writes:
> There is certainly potential there. With a (very) rough PoC
> experiment, a 8MB bloom filter, and a carefully choosen path I can
> achieve a nice, almost 25x speedup:
>
> $ time git rev-list --count HEAD -- t/valgrind/valgrind.sh
> 6
>
> r
Contributors to Git use a variety of editors, each with their own
configuration files. Because C lacks the defined norms on how to indent
and style code that other languages, such as Ruby and Rust, have, it's
possible for various contributors, especially new ones, to have
configured their editor
On Mon, Oct 08, 2018 at 10:53:52PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> It looks like we can add at least "pm" and "pl" to that pattern:
Sure. I didn't think we had any of those, but you've just proven me
wrong. I'll send a v3 shortly.
--
brian m. carlson: Houston, Texas, US
OpenPGP:
On Mon, Oct 08 2018, brian m. carlson wrote:
> Contributors to Git use a variety of editors, each with their own
> configuration files. Because C lacks the defined norms on how to indent
> and style code that other languages, such as Ruby and Rust, have, it's
> possible
Contributors to Git use a variety of editors, each with their own
configuration files. Because C lacks the defined norms on how to indent
and style code that other languages, such as Ruby and Rust, have, it's
possible for various contributors, especially new ones, to have
configured their editor
ing tree object)
3. The path doesn't change very often (need to inspect many TREESAME
pairs before finding enough interesting commits)
4. Some sub-path changes often (so the TREESAME comparison needs to
parse beyond that sub-path often)
Our standard examples (Git and Linux repos) don't have m
I think that's the next big frontier in getting
> >>things like "git log -- path" to a reasonable run-time.
> >There is certainly potential there. With a (very) rough PoC
> >experiment, a 8MB bloom filter, and a carefully choosen path I can
> >achieve a nice
On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
Hi All,
Hello, Ananya! Welcome.
I was searching through #leftovers and found this.
https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
This patch address the task discussed in the above link
Hi All,
I was searching through #leftovers and found this.
https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
This patch address the task discussed in the above link.
From: Ananya Krishan Maram
skip the #include of git-compat-util.h since all .c
On 10/8/2018 12:41 PM, SZEDER Gábor wrote:
On Wed, Oct 03, 2018 at 03:18:05PM -0400, Jeff King wrote:
I'm still excited about the prospect of a bloom filter for paths which
each commit touches. I think that's the next big frontier in getting
things like "git log -- path" to a reas
On Wed, Oct 03, 2018 at 03:18:05PM -0400, Jeff King wrote:
> I'm still excited about the prospect of a bloom filter for paths which
> each commit touches. I think that's the next big frontier in getting
> things like "git log -- path" to a reasonable run-time.
There is
On Sun, 7 Oct 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > On Sat, Oct 6, 2018 at 5:16 PM Julia Lawall wrote:
> >> Git log -S or -G make it possible to find commits that have particular
> >> words in the changed lines. Sometimes
601 - 700 of 30258 matches
Mail list logo
