Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Perhaps something like this (not even compile tested as both of my
>> worktrees are doing something else)
>
> This time with a few additional tests.
>
> -- >8 --
> Subject: [PATCH] fsck: exit with non-zero when problems are found
Seems st
On Thu, Sep 24, 2015 at 12:44 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> Remove the error reporting variable to make the code easier to port
>> over to using ref-filter APIs.
>>
>> This also removes the error from being displayed. As branch.c will use
>> ref-filter APIs in the followi
On Thu, Sep 24, 2015 at 12:27 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Remove the error reporting variable to make the code easier to port
>> over to using ref-filter APIs.
>>
>> This also removes the error from being displayed. As branch.c will use
>> ref-filter APIs in the following
On Thu, Sep 24, 2015 at 12:46 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> The series looks good to me. I did a minor remark on PATCH 5/8 but this
>> should not block inclusion.
>
> Thanks. As long as the log message is telling the truth, I do not
> mind the actual lossage of the error
Mike Rappazzo writes:
> ... Does the porcelain
> format restrict additive changes? That is, is it OK for a future
> patch to add another field in the format, as long as it doesn't alter
> the other values? Is the format that I have used here acceptable
> (assuming the changes proposed below ar
On Tue, Sep 22, 2015 at 3:42 PM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>
>>
>> +--porcelain::
>> + With `list`, output in an easy-to-parse format for scripts.
>> + This format will remain stable across Git versions and regardless of
>> user
>> + configuration.
>
> ... and
Stefan Beller writes:
> I agree the commit 7087c5f3 (SQUASH??? on top of run-command: add an
> asynchronous parallel child processor) makes sense; I arrived at the same
> patch after adding in the feedback.
I dunno. As I said, while a small part of that commit is necessary
to be squashed into [
On Thu, Sep 24, 2015 at 02:20:17AM +0200, Stephan Beyer wrote:
> The definition of log_div() appended information to the web server's
> logfile to make the test more readable. However, it could happen that
> this information is written before the web server writes its log line
> (this consistently
On Thu, Sep 24, 2015 at 02:22:10AM +0200, Stephan Beyer wrote:
> I only checked for profile builds and first tried to bisect the issue,
> which went terribly wrong because using older Git commits (unluckily I
> can't say now how far you should go back in history), the test failed or
> succeeded ra
Hi,
On 09/24/2015 01:24 AM, Jeff King wrote:
>> I noticed that t5561 fails on my machine when compiling with
>> "make PROFILE=GEN". Luckily, the reason seems to be the test only,
>> not the tool it is testing.
>>
>> I tracked it down that far that log_div() (defined in
>> t/t5561-http-backend.sh b
The definition of log_div() appended information to the web server's
logfile to make the test more readable. However, it could happen that
this information is written before the web server writes its log line
(this consistently happens with a PROFILE=GEN build), and hence the
test failed.
To get r
Signed-off-by: Stefan Beller
---
I agree the commit 7087c5f3 (SQUASH??? on top of run-command: add an
asynchronous parallel child processor) makes sense; I arrived at the same
patch after adding in the feedback.
However I have the difference below, which I think could also be squashed in.
when w
On Wed, Sep 23, 2015 at 01:21:39AM +0200, Stephan Beyer wrote:
> I noticed that t5561 fails on my machine when compiling with
> "make PROFILE=GEN". Luckily, the reason seems to be the test only,
> not the tool it is testing.
>
> I tracked it down that far that log_div() (defined in
> t/t5561-http
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Not much has happened on the 'master' or 'next' fronts, but we have
seen quite a lot of activities above them to prepare for the next
cycle, whi
Matthieu Moy writes:
> To be sure, I tried:
>
> echo ee0f5eeeae36cd1b5a346a1e2ae5c8cb841cd5da > .git/refs/heads/broken
>
> where the sha1 is the one of a blob.
> ...
After doing (something like) the above, running "git push --mirror"
to various Git repositories shows their slightly different
b
Hi Joakim,
On 2015-09-23 22:41, Joakim Tjernlund wrote:
> On Wed, 2015-09-23 at 13:10 +0200, Johannes Schindelin wrote:
>>
>> On 2015-09-22 22:58, Joakim Tjernlund wrote:
>> > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote:
>> > >
>> > > The reason should be easy to understand: Git's
Junio C Hamano writes:
> Perhaps something like this (not even compile tested as both of my
> worktrees are doing something else)
This time with a few additional tests.
-- >8 --
Subject: [PATCH] fsck: exit with non-zero when problems are found
After finding some problems (e.g. a ref refs/h
On Tue, Sep 22, 2015 at 6:08 PM, Junio C Hamano wrote:
> Gabor Bernat writes:
>
>> On Mon, Sep 21, 2015 at 11:24 PM, Gábor Bernát
>> ...
>>> Agreed, :) did not abandoned this, just got caught up with many stuff.
>>> Thanks for the help,
>>
>> So do I need to do anything else with this? :)
>
> If
On Wed, 2015-09-23 at 13:10 +0200, Johannes Schindelin wrote:
> Hi Joakim,
>
> On 2015-09-22 22:58, Joakim Tjernlund wrote:
> > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote:
> > >
> > > The reason should be easy to understand: Git's concept is based on the
> > > idea that you hav
Junio C Hamano writes:
>> BTW, this looks like an fsck bug:
>>
>> $ git fsck --strict
>> Checking object directories: 100% (256/256), done.
>> error: refs/heads/broken: not a commit
>> $ echo $?
>> 0
>
> Interesting. Perhaps leave it as a MicroProject for GSoC next year?
> ;-)
Perhaps something
Matthieu Moy writes:
> More precisely: if we find such a branch ref and we're used with an
> option that requires us to lookup the commit, then we report it as an
> error.
> ...
> So I agree with Junio that the commit message is not sufficient: there
> is a behavioral change. I'm OK with it, but
Stefan Beller writes:
> Split the cloning part out to its own function,
> this allow us in a later patch to convert cmd_update in C.
>
> Signed-off-by: Stefan Beller
> ---
It appears that this is not just a refactor and loses the logic
around $cloned_modules variable that seems to avoid doing t
Junio C Hamano writes:
> Karthik Nayak writes:
>
>> Remove the error reporting variable to make the code easier to port
>> over to using ref-filter APIs.
>>
>> This also removes the error from being displayed. As branch.c will use
>> ref-filter APIs in the following patches, the error checking b
Stefan Beller writes:
> I can confirm this now.
>
> git fetch --recurse-submodules=yes -j 400
>
> in an submodule-ified Android tree takes very long to start putting out useful
> information, but if I hardcode the SPAWN_CAP to 4 it looks pretty amazing
> fast.
Nice to hear that parallel fetc
On Wed, Sep 23, 2015 at 12:34 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> You are running "git fetch" that are is a lot more heavy-weight.
>> Because once each of them started fully they will be network bound,
>> it is likely that you would want to run more processes than you have
>>
Junio C Hamano writes:
> You are running "git fetch" that are is a lot more heavy-weight.
> Because once each of them started fully they will be network bound,
> it is likely that you would want to run more processes than you have
> core.
I thought the conclusion would be obvious, but just in ca
Victor Leschuk wrote:
> Hello Eric, thanks for looking into it.
>
> >> git-cat-file has outgrown the parent perl process several times
> >> (git-cat-file - ~3-4Gb, perl - 400Mb).
>
> > Ugh, that sucks.
> > Even the 400Mb size of Perl annoys me greatly and I'd work
> > on fixing it if I had more
Matthieu Moy writes:
> The series looks good to me. I did a minor remark on PATCH 5/8 but this
> should not block inclusion.
Thanks. As long as the log message is telling the truth, I do not
mind the actual lossage of the error message shown to the user.
--
To unsubscribe from this list: send
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs.
>
> This also removes the error from being displayed. As branch.c will use
> ref-filter APIs in the following patches, the error checking becomes
> redundant with the error
Karthik Nayak writes:
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -479,8 +479,6 @@ static void print_ref_list(struct ref_filter *filter,
> struct ref_sorting *sortin
> struct ref_array array;
> int maxwidth = 0;
> const char *remote_prefix = "";
> - struct ref_so
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs.
>
> This also removes the error from being displayed. As branch.c will use
> ref-filter APIs in the following patches, the error checking becomes
> redundant with the error
Make 'branch.c' use 'ref-filter' data structures and make changes to
support the new data structures. This is a part of the process of
porting 'branch.c' to use 'ref-filter' APIs.
This is a temporary step before porting 'branch.c' to use 'ref-filter'
completely. As this is a temporary step, most o
Make 'branch.c' use 'ref-filter' APIs for iterating through refs
sorting. This removes most of the code used in 'branch.c' replacing it
with calls to the 'ref-filter' library.
Make 'branch.c' use the 'filter_refs()' function provided by 'ref-filter'
to filter out tags based on the options set.
We
Add the '--points-at' option provided by 'ref-filter'. The option lets
the user to list only branches which points at the given object.
Add documentation and tests for the same.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
Documentation/git-branch.t
Remove show_detached() and make detached HEAD to be rolled into
regular ref_list by adding REF_DETACHED_HEAD as a kind of branch and
supporting the same in append_ref(). This eliminates the need for an
extra function and helps in easier porting of branch.c to use
ref-filter APIs.
Before show_detac
The previous iteration of the same can be found:
http://www.mail-archive.com/git@vger.kernel.org/msg78153.html
Changes in this version:
* use ref_default_sorting()
* Improve documentation, comments and commit message.
Karthik Nayak (8):
branch: refactor width computation
branch: bump get_head
We check if given ref is the current branch in print_ref_list(). Move
this check to print_ref_item() where it is checked right before
printing. This enables a smooth transition to using ref-filter APIs,
as we can later replace the current check while printing to just check
for FILTER_REFS_DETACHED
Remove the error reporting variable to make the code easier to port
over to using ref-filter APIs.
This also removes the error from being displayed. As branch.c will use
ref-filter APIs in the following patches, the error checking becomes
redundant with the error reporting system found in the ref-
From: Karthik Nayak
Remove unnecessary variables from ref_list and ref_item which were
used for width computation. This is to make ref_item similar to
ref-filter's ref_array_item. This will ensure a smooth port of
branch.c to use ref-filter APIs in further patches.
Previously the maxwidth was co
This is a preperatory patch for 'roll show_detached HEAD into regular
ref_list'. This patch moves get_head_description() to the top so that
it can be used in print_ref_item().
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
Stefan Beller writes:
> I modified the test-run-command test function to start up to 400 processes.
> (Most people will use less than 400 processes in the next 5 years), and run
> just as in t0061:
>
> ./test-run-command run-command-parallel-400 sh -c "printf
> \"%s\n%s\n\" Hello World"
>
> T
Junio C Hamano writes:
> Just to make sure there is no misunderstanding, just like I prefer
> "start one" over "start as many as possible" in order to give
> scheduling decision to the calling loop, I would expect that...
To sum up, what I anticipate would happen over time on top of 06/14
is som
On Tue, Sep 22, 2015 at 11:29 PM, Junio C Hamano wrote:
>
> And this one, when get_next_task() says "nothing more to do", is
> clearly "we returned without starting anything", so according to the
> comment it should be returning 0, but the code returns 1, which
> looks incorrect.
>
>> + if (s
Hello Eric, thanks for looking into it.
>> git-cat-file has outgrown the parent perl process several times
>> (git-cat-file - ~3-4Gb, perl - 400Mb).
> Ugh, that sucks.
> Even the 400Mb size of Perl annoys me greatly and I'd work
> on fixing it if I had more time.
I was going to look at this prob
Johannes Schindelin writes:
>> A .git/tmp/ would make housekeeping easier, you would know that every
>> file under .git
>> should be there and if you find something you don't recognize you would
>> react.
>
> No, it would actually make it harder. I seem to recall that there was
> some problem wi
Ramsay Jones writes:
> Commits 9c0b9f6 ("worktree: add 'list' command", 18-09-2015) and
> 40ca3d3 ("worktree: add functions to get worktree details", 18-08-2015)
> both introduce the use of a C99 feature (declare the loop control
> variable in the loop header initializer section).
>
> Signed-off-
Junio C Hamano writes:
> Stefan Beller writes:
>
>> +static void pp_buffer_stderr(struct parallel_processes *pp)
>> +{
>> +int i;
>> +
>> +while ((i = poll(pp->pfd, pp->max_processes, 100)) < 0) {
>> +if (errno == EINTR)
>> +continue;
>> +pp_cl
On 23 Sep 2015, at 13:11, Luke Diamand wrote:
> On 23 September 2015 at 11:27, Lars Schneider
> wrote:
>>
>> On 23 Sep 2015, at 11:27, Luke Diamand wrote:
>>
>>> Lars,
>>>
>>> I just noticed that your change "git-p4: honor core.ignorecase when
>>> using P4 client specs" seems to break t981
On 23 Sep 2015, at 13:25, Luke Diamand wrote:
> Adding back git@vger.kernel.org, which I inadvertently dropped off the thread.
>
> On 23 September 2015 at 12:22, Luke Diamand wrote:
>> On 23 September 2015 at 11:09, Lars Schneider
>> wrote:
>>>
>>> On 23 Sep 2015, at 11:22, Luke Diamand wr
Adding back git@vger.kernel.org, which I inadvertently dropped off the thread.
On 23 September 2015 at 12:22, Luke Diamand wrote:
> On 23 September 2015 at 11:09, Lars Schneider
> wrote:
>>
>> On 23 Sep 2015, at 11:22, Luke Diamand wrote:
>>
>>> On 23 September 2015 at 09:50, Lars Schneider
Hi Joakim,
On 2015-09-22 22:58, Joakim Tjernlund wrote:
> On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote:
>>
>> The reason should be easy to understand: Git's concept is based on the idea
>> that you have full control over
>> your repository. Other repositories you might only have r
On 23 September 2015 at 11:27, Lars Schneider wrote:
>
> On 23 Sep 2015, at 11:27, Luke Diamand wrote:
>
>> Lars,
>>
>> I just noticed that your change "git-p4: honor core.ignorecase when
>> using P4 client specs" seems to break t9819.
>>
>> I suspect that the problem is just that t9819 needs to
Commits 9c0b9f6 ("worktree: add 'list' command", 18-09-2015) and
40ca3d3 ("worktree: add functions to get worktree details", 18-08-2015)
both introduce the use of a C99 feature (declare the loop control
variable in the loop header initializer section).
Signed-off-by: Ramsay Jones
---
Hi Junio,
On 23 Sep 2015, at 11:27, Luke Diamand wrote:
> Lars,
>
> I just noticed that your change "git-p4: honor core.ignorecase when
> using P4 client specs" seems to break t9819.
>
> I suspect that the problem is just that t9819 needs to be updated to
> reflect your change - do you have any thoughts
Lars,
I just noticed that your change "git-p4: honor core.ignorecase when
using P4 client specs" seems to break t9819.
I suspect that the problem is just that t9819 needs to be updated to
reflect your change - do you have any thoughts on that?
Thanks!
Luke
--
To unsubscribe from this list: send
On 23 Sep 2015, at 10:18, Lars Schneider wrote:
>
> On 23 Sep 2015, at 09:58, Luke Diamand wrote:
>
>> On 21 September 2015 at 23:41, wrote:
>>> From: Lars Schneider
>>>
>>> diff to v6:
>>> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
>>> "[[:space:]]")
>>> * ge
On 23 Sep 2015, at 09:58, Luke Diamand wrote:
> On 21 September 2015 at 23:41, wrote:
>> From: Lars Schneider
>>
>> diff to v6:
>> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
>> "[[:space:]]")
>> * generated patch on top of next (95c4325) to resolve merge conflict
On 21 September 2015 at 23:41, wrote:
> From: Lars Schneider
>
> diff to v6:
> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
> "[[:space:]]")
> * generated patch on top of next (95c4325) to resolve merge conflicts
Trying this out by hand (rather than using the test cas
On 23 Sep 2015, at 00:03, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> diff to v6:
>> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
>> "[[:space:]]")
>> * generated patch on top of next (95c4325) to resolve merge conflicts
On 22 Sep 2015, at 23:49, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> The functions “gitConfig” and “gitConfigBool” are almost identical. Make
>> “gitConfig” more generic by adding an optional type specifier. Use the type
>> specifier “—bool” wit
Thanks a lot for taking care of this!
- Lars
On 22 Sep 2015, at 21:17, Junio C Hamano wrote:
> Yup, this was privately reported and I just squashed a fix in right now ;-)
>
> Thanks. "cd t && make test-lint" would have caught it.
>
> On Tue, Sep 22, 2015 at 12:11 PM, Michael Blume wrote:
>>
Do you need a loan to pay off your bills, start up a business We give out loan
at affordable rate of 2%. For quick response provide the below information.
Name:
Amount:
Duration:
Country:
Age:
Address:
Mobile Number:
Regards.
--
To unsubscribe from this list: send the line "unsubscribe git" in
t
62 matches
Mail list logo
