ristian Couder
> Mentored-by: Matthieu Moy
>Signed-off-by: Karthik Nayak
>Signed-off-by: Junio C Hamano
As Junio mentioned I did notice ~13x slower speed.
$ git version
[12:02:08]
git version 2.5.0.275.gac4cc86
$ time git tag --contains HEAD~300
I'm using Windows 10. Before I install git 2.6.1.windows.1, I have
installed git 1.9.5.github.0 (by installing GitHub Desktop), it works just
fine.
But when I installed git 2.6.1.windows.1 (from git-scm.com), I'm not able
to use git anymore:
- The powershell console displayed [(unknown)] instea
Junio C Hamano wrote:
> Here is what I prepared based on your review in an interdiff form.
For what it's worth,
Reviewed-by: Jonathan Nieder
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Jerry Snitselaar writes:
> Is this known and being looked into? I've seen a jump from 12 seconds
> to over 9 minutes with running git tag --contains on my kernel repo.
Thanks for a report. Yes, it seems that there is a recent
regression on the 'master' branch, not yet in any released version,
a
Here is what I prepared based on your review in an interdiff form.
A few points to note:
* Stole the "fmt-merge-msg" example verbatim ;-)
* The description of "show-ref --exclude" mode should be much
clearer now.
Thanks.
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-che
The latest maintenance release Git v2.6.2 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.6.2'
tag and the 'maint' branch that the tag points at:
url = https://kernel
Is this known and being looked into? I've seen a jump from 12 seconds
to over 9 minutes with running git tag --contains on my kernel repo.
snits ~/dev/linux> git --version
git version 2.6.1.145.gb27dacc
snits ~/dev/linux> time git tag --contains 825fcfc
next-20151012
next-20151013
v4.3-rc5
rea
On Fri, 2015-10-16 at 13:34 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > The problem is:
> >
> > trash directory.t7063-status-untracked-cache$ diff trace trace.expect
> > 3,4c3,4
> > < directory invalidation: 1
> > < opendir: 1
> > ---
> >> directory invalidation: 2
> >> opendir: 2
On Fri, Oct 16, 2015 at 2:02 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Discussions turned out that we cannot parallelize the whole loop below
>> `git submodule--helper list` in `git submodule update`, because some
>> changes should be done only one at a time, such as messing up a sub
Stefan Beller writes:
> Discussions turned out that we cannot parallelize the whole loop below
> `git submodule--helper list` in `git submodule update`, because some
> changes should be done only one at a time, such as messing up a submodule
> and leave it up to the user to cleanup the conflicted
Stefan Beller writes:
> The branch variable is used only once so calculate it only when needed.
>
> Signed-off-by: Stefan Beller
> ---
Makes sense.
> git-submodule.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index eea27f8..
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> git-submodule.sh | 2 +-
> t/t7400-submodule-basic.sh | 12 ++--
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 578ec48..eea27f8 100755
> --- a/git-su
On Fri, Oct 16, 2015 at 1:37 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>> git-submodule.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/git-submodule.sh b/git-submodule.sh
>> index 8b0eb9a..578ec48 100755
>> --- a/g
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> git-submodule.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 8b0eb9a..578ec48 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -684,7 +684,7 @@ cmd_
David Turner writes:
> The problem is:
>
> trash directory.t7063-status-untracked-cache$ diff trace trace.expect
> 3,4c3,4
> < directory invalidation: 1
> < opendir: 1
> ---
>> directory invalidation: 2
>> opendir: 2
>
>
> I can repro on a SSD.
>
> I had to try many times to reproduce (I think e
On Fri, 2015-10-16 at 17:22 +0200, Torsten Bögershausen wrote:
> On 15.10.15 09:52, Lars Schneider wrote:
> > Hi,
> >
> > I noticed that "t7063-status-untracked-cache.sh" occasionally fails with
> > "not ok 24 - test sparse status with untracked cache".
>
> I can't reproduce it here.
> Do you wan
Jonathan Nieder writes:
>> --stdin::
>> -Read file names from stdin instead of from the command-line.
>> +Read pathnames from stdin instead of from the command-line.
>
> Here I have to read the description of "-z" to understand that pathnames
> come one per line. How about
>
> Rea
Junio C Hamano wrote:
> The synopsys text and the usage string of subcommands that read list
nit: s/synopsys/synopsis/
[...]
> +++ b/Documentation/git-cat-file.txt
> @@ -10,7 +10,7 @@ SYNOPSIS
>
> [verse]
> 'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e |
>
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] <
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another comma
Ralf Thielow writes:
> There seem to be three more places left missing these angle brances
> at the usage string.
> Junio, feel free to squash this or treat it as a separate patch
> on top, if suitable.
Thanks. Will queue.
>
> -- >8 --
> From: Ralf Thielow
> Date: Fri, 16 Oct 2015 19:09:57 +02
Alex Henrie writes:
> 2015-10-16 10:36 GMT-06:00 Junio C Hamano :
>> Makes sense, as all the other in the usage string are
>> bracketted.
>>
>> Does it make sense to do this for contrib/examples, which is the
>> historical record, though?
>
> I didn't know that contrib/examples was a historical
Tobias Klauser writes:
>> So this is your output code, which gives only the number of lines
>> without the cleaned up result.
>
> This should better be a simple printf("%zu\n", lines) I guess?
I think we actively avoid using %z conversion that is only C99.
If you really want to, you could count
Junio C Hamano writes:
>> -if (mode == INVAL)
>> -usage(usage_msg);
>
> When given "git stripspace -s blorg", we used to set mode to INVAL
> and then showed the correct usage. But we no longer have a check
> that corresponds to the old INVAL thing, do we? Perhaps check argc
> to
Stefan Beller writes:
> so maybe
> fetch.recurseSubmoduleJobs
> fetch.submoduleJobs
> fetch.jobs
> fetch.connectionsToUse
"git remote update" is another example that may want to run multiple
independent 'git fetch' in parallel. I think "When the operation I
ask involves fetching
Alex Henrie wrote:
> ---
> builtin/pull.c | 2 +-
> contrib/examples/git-pull.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/pull.c b/builtin/pull.c
> index a39bb0a..bf3fd3f 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -66,7 +66,
Tobias Klauser writes:
> Use parse-options to parse command-line options instead of a
> hand-crafted implementation.
>
> This is a preparatory patch to simplify the introduction of the
> --count-lines option in a follow-up patch.
The second paragraph is probably of much lessor importance than on
On Mon, Oct 12, 2015 at 4:50 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> There is core.preloadIndex to enable parallel index preload, but
>> that is boolean and not giving fine control to the user. We want to give
>> fine control to the user here I'd assume.
>
> I'd approach this as "f
Tobias Klauser writes:
> - Split patch 2/3 into two patches: patch 2/4 switches git stripspace
> to use parse-options and patch 3/4 introduces the new option.
Much better now.
> - Implement line counting in cmd_stripbuf() instead of (ab-)using
> strbuf_stripspace() for it.
Also sho
2015-10-16 10:36 GMT-06:00 Junio C Hamano :
> Makes sense, as all the other in the usage string are
> bracketted.
>
> Does it make sense to do this for contrib/examples, which is the
> historical record, though?
I didn't know that contrib/examples was a historical record. The last
patch I submitt
Tobias Klauser writes:
Be consistent with the subjects, please.
> strbuf: make stripspace() part of strbuf
s/make/make/ ;-)
> stripspace: Use parse-options for command-line parsing
s/Use/use/
> stripspace: Implement --count-lines option
s/Implement/implement/
> git rebase -i: Use n
Alex Henrie writes:
> Signed-off-by: Alex Henrie
> ---
Makes sense, as all the other in the usage string are
bracketted.
Does it make sense to do this for contrib/examples, which is the
historical record, though? The first one I found with
$ less contrib/examples/*
was this:
#!/bi
David Turner writes:
> We also do dozens or hundreds of merges per day and only saw this quite
> rarely. Interestingly, we could only trigger it with an alternate
> hashing function for git's hashmap implementation, and only once a
> certain bug in that implementation was *fixed*. But that was
I can't reproduce it here.
Do you want to give us some info about your setup ?
OS ?
Harddisk, SSD, Fusion ?
Does "debug=t verbose=t ./t7063-status-untracked-cache.sh >xx.txt 2>&1"
give any more information ?
On 15.10.15 09:52, Lars Schneider wrote:
> Hi,
>
> I noticed that "t7063-status-untrack
Use the newly added --count-lines option for 'git stripspace' to count
lines instead of piping the entire output to 'wc -l'.
Signed-off-by: Tobias Klauser
---
Implements the small project idea from
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#implement_.27--count-lines.27_in_.27git_s
Use parse-options to parse command-line options instead of a
hand-crafted implementation.
This is a preparatory patch to simplify the introduction of the
--count-lines option in a follow-up patch.
Signed-off-by: Tobias Klauser
---
builtin/stripspace.c | 56 --
Implement the --count-lines options for git stripspace to be able to
omit calling:
git stripspace --strip-comments < infile | wc -l
e.g. in git-rebase--interactive.sh. The above command can now be
replaced by:
git stripspace --strip-comments --count-lines < infile
This will make it easier t
Rename stripspace() to strbuf_stripspace() and move it to the strbuf
module. The function is also used in other builtins than stripspace, so
it makes sense to have it in a more generic place. Since it operates on
an strbuf and the function is declared in strbuf.h, move it to strbuf.c
and add the co
(1) Move the stripspace() function to the strbuf module adding a prefix
and changing all users accordingly. Also introduce a wrapper in case
any topic branches still depend on the old name.
(2) Switch git stripspace to use parse-options in order to simplify
introducing new command line
On 12.10.2015 13:30, Aleksey Komarov wrote:
> Now, I'm trying to add a submodule to my repository, but fail to understand
> why
> my .gitignore prevents it from being added. I use the following command to
> check
> if my submodule will be ignored or not:
>
> $ git add --dry-run --ignore-missing
Tobias Klauser writes:
> On 2015-10-15 at 18:52:54 +0200, Matthieu Moy
> wrote:
>> Tobias Klauser writes:
>> > +static const char * const usage_msg[] = {
>>
>> Stick the * to usage_msg please.
>
> Just noticed while looking at how other sub-commands define this, the vast
> majority use "const
On 2015-10-15 at 18:52:54 +0200, Matthieu Moy
wrote:
> Tobias Klauser writes:
> > +static const char * const usage_msg[] = {
>
> Stick the * to usage_msg please.
Just noticed while looking at how other sub-commands define this, the vast
majority use "const char * const" and not "const char con
From: "Johannes Schindelin"
Hi Francois-Xavier,
On Thu, 15 Oct 2015, Francois-Xavier Le Bail wrote:
On 13/10/2015 15:29, Philip Oakley wrote:
> Thus the only sha1 numbers that could be used are those that are
> within the (possibly implied) instruction sheet (which will list the
> current sh
On 2015-10-15 at 21:21:53 +0200, Matthieu Moy
wrote:
> Tobias Klauser writes:
>
> > + * comments are considered contents to be removed or not. Returns the
> > + * number of lines in the resulting buffer.
>
> We write comments at imperative tone, hence "Return", not "Returns".
The other commen
On 2015-10-15 at 19:58:26 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> > diff --git a/Documentation/git-stripspace.txt
> > b/Documentation/git-stripspace.txt
> > index 60328d5..411e17c 100644
> > --- a/Documentation/git-stripspace.txt
> > +++ b/Documentation/git-stripspace.txt
> >
By default when fetching one remote nothing is printed unless there
are changes that need fetching. This makes fetching multiple remotes
be just as verbose as fetching a single remote.
This is needed when fetching multiple repositories using the myrepos
tool in minimal output mode, where myrepos o
On 2015-10-15 at 18:52:54 +0200, Matthieu Moy
wrote:
> Tobias Klauser writes:
>
> > --- a/Documentation/git-stripspace.txt
> > +++ b/Documentation/git-stripspace.txt
> > @@ -9,7 +9,7 @@ git-stripspace - Remove unnecessary whitespace
> > SYNOPSIS
> >
> > [verse]
> > -'git stripspace'
On 2015-10-15 at 18:42:23 +0200, Matthieu Moy
wrote:
> Tobias Klauser writes:
>
> > Also switch all current users of stripspace() to the new function name
> > and keep a temporary wrapper inline function for topic branches still
> > using stripspace().
>
> Since you have this temporary wrappe
Thanks for the review.
On 2015-10-15 at 19:36:17 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> > Rename stripspace() to strbuf_stripspace() and move it to the strbuf
> > module as suggested in [1].
> >
> > Also switch all current users of stripspace() to the new function name
> > an
On Thu, 2015-10-15 at 13:51 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> >> > +static inline void drop_ce_ref(struct cache_entry *ce)
> >> > +{
> >> > +if (ce != NULL) {
> >> > +assert(ce->ref_count >= 0);
> >>
> >> Shouldn't this be "> 0" to prevent double fre
Resend. The previous replies didn't make it to git-ml because of html part
inserted by gmail.
On 10/15/2015 11:59 PM, Junio C Hamano wrote:
Are you talking about making a clone of a repository that was
created with "clone --reference", to borrow from the same
third repository the original is bo
50 matches
Mail list logo
