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
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
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 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
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'
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 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
> >
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
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 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
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 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
(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
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
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 --
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
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
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
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
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
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
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:
> - 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
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:
> 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
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,
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
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
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
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
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
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
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 |
>
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
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
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
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_
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 +-
> 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
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:
> 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
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo
