On Mon, Aug 1, 2016 at 7:24 PM, Stefan Beller wrote:
> On Sat, Jul 30, 2016 at 10:25 AM, Christian Couder
> wrote:
>
> I have reviewed briefly all 41 patches and generally they look good to me.
> There were some nits, which should not stop us from proceeding, though.
> This one however is not one
On Windows, it is already pretty expensive to try to recreate the stat()
data that Git assumes is cheap to obtain. To make things halfway decent
in performance, we even have to skip emulating the inode and to
determine the number of hard links.
This is not a huge problem, usually, as either the si
Em Wed, 03 Aug 2016 00:17:10 +0200
Florian Mickler escreveu:
> cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?)
Yes, my kernel.org address is up. Better to keep it as the canonical address,
as this is unlikely to change as it is not associated to an e-mail provider.
>
>
Signed-off-by: Stefan Beller
---
This goes on top of origin/sb/submodule-recommend-shallowness.
I just realized we had an extra page for all the configuration options,
so let's keep that in sync.
Thanks,
Stefan
Documentation/gitmodules.txt | 5 +
1 file changed, 5 insertions(+)
dif
On 08/02/2016 04:26 PM, Joe Perches wrote:
> On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote:
>> cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?)
>>
>> Am Tue, 02 Aug 2016 09:36:21 -0700
>> schrieb Joe Perches :
>>
>>>
>>> Hello Florian.
>>> There is at least an oddi
The API documentation said that the hashmap_entry structure to be
embedded in the caller's structure is to be treated as opaque, which
left the reader wondering if it can safely be discarded when it no
longer is necessary. If the hashmap_entry structure had references
to external resources such as
Signed-off-by: Ramsay Jones
---
Hi Christian,
I had intended to ask you to squash this into your 'cc/apply-am'
branch, specifically commit 4d18b33a (apply: move libified code
from builtin/apply.c to apply.{c,h}, 30-07-2016).
However, having read that commit a little closer, it seems that
you d
On Tue, Aug 2, 2016 at 3:33 PM, Ramsay Jones
wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Christian,
>
> I had intended to ask you to squash this into your 'cc/apply-am'
> branch, specifically commit 4d18b33a (apply: move libified code
> from builtin/apply.c to apply.{c,h}, 30-07-2016).
>
Junio C Hamano writes:
> Pranit Bauva writes:
>
>> Reimplement the `bisect_write` shell function in C and add a
>> `bisect-write` subcommand to `git bisect--helper` to call it from
>> git-bisect.sh
>
> Up to around this step we've seen these patches well enough and I
> think with another reroll
Johannes Schindelin writes:
> I tend to think that the underscore is correct: this change is not so much
> about the builtin (which is written with a dash) but about the function
> (written with an underscore, used by more than just merge-recursive, e.g.
> cherry-pick).
Yes, I agree. "merge-rec
On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote:
> cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?)
>
> Am Tue, 02 Aug 2016 09:36:21 -0700
> schrieb Joe Perches :
>
> >
> > Hello Florian.
> > There is at least an oddity with get_maintainer handling of a
> > .mailm
Stefan Beller writes:
> On Tue, Aug 2, 2016 at 2:45 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> When reading up on a subcommand of `gi submodule`, it is convenient
>>
>> s/gi /git /;
>
> will fix.
>
> And in the neighboring thread you just pointed out you used to just correct
> sp
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
On the 'master' front, the individ
On Tue, Aug 2, 2016 at 2:45 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When reading up on a subcommand of `gi submodule`, it is convenient
>
> s/gi /git /;
will fix.
And in the neighboring thread you just pointed out you used to just correct
spelling fixes like this. I think it real
Stefan Beller writes:
> When reading up on a subcommand of `gi submodule`, it is convenient
s/gi /git /;
> to have its options nearby and not just at the top of the man page.
> Add the options to each subcommand.
>
> While at it, also document the `--checkout` option for `update`.
I do find th
Johannes Schindelin writes:
>> > There are a couple of places where return values never indicated errors
>> > before, as wie simply died instead of returning.
>>
>> s/wie/we/;
>
> Right. What can I say, I am surrounded by too many Germans.
>
> I fixed this locally, in case another re-roll should
Johannes Schindelin writes:
>> But in that case, there would be both messages meant for the
>> standard output and also meant for the standard error, and we need
>> some way to make sure they go to the right channel.
>
> Not necessarily. Let's have a look at our existing code in
> git-rebase.sh:
Eric Wong writes:
> So v3 will be MORE=FRX, as less was added:
>
> commit 98170c0c3ba86eb1cc975e7848d075bf2abc1ed0
> Author: ps
> Date: Mon May 22 10:00:00 2000 +
>
> bmake glue for less.
>
> and more was nuked:
>
> commit cde9059fa3e4dc7e259c3864d7536252a5c580a0
>
Jeff King writes:
> On Mon, Aug 01, 2016 at 04:03:40PM -0700, Junio C Hamano wrote:
>
>> Eric Wong writes:
>>
>> > From: Junio C Hamano
>> >
>> > Allowing PAGER_ENV to be set at build-time allows us to move
>> > pager-specific knowledge out of our build. Currently, this
>> > allows us to set
Oleg Taranenko writes:
> First, assuming the common ancestor is GOOD based on the fact that
> some descendant given as GOOD is pretty bad idea.
What you claim is fundamentally incompatible with the way "bisect"
works as a O(log(n)) operation. It is likely that your definition
of Good for the pu
Pranit Bauva writes:
> +static int bisect_start(struct bisect_terms *terms, int no_checkout,
> + const char **argv, int argc)
> +{
> + int i, j, has_double_dash = 0, must_write_terms = 0, bad_seen = 0;
> + int flag;
> + struct string_list revs = STRING_LIST_INIT_DU
Pranit Bauva writes:
> Reimplement the `bisect_write` shell function in C and add a
> `bisect-write` subcommand to `git bisect--helper` to call it from
> git-bisect.sh
Up to around this step we've seen these patches well enough and I
think with another reroll or two, they are in good enough shap
On Sun, Jul 31, 2016 at 11:45:08PM +0200, Lars Schneider wrote:
>
> > On 31 Jul 2016, at 22:36, Torstem Bögershausen wrote:
> >
> >
> >
> >> Am 29.07.2016 um 20:37 schrieb larsxschnei...@gmail.com:
> >>
> >> From: Lars Schneider
> >>
> >> packet_flush() would die in case of a write error ev
Pranit Bauva writes:
> +static int bisect_terms(struct bisect_terms *terms, int term_defined)
> +{
> + if (get_terms(terms)) {
> + fprintf(stderr, "no terms defined\n");
> + return -1;
> + }
> + if (!term_defined) {
> + printf("Your current terms ar
Pranit Bauva writes:
> +static int mark_good(const char *refname, const struct object_id *oid,
> + int flag, void *cb_data)
> +{
> + int *m_good = (int *)cb_data;
> + *m_good = 0;
> + return 0;
> +}
See below.
> +static int bisect_next_check(const struct bisect_term
Pranit Bauva writes:
> Reimplement the `check_and_set_terms` shell function in C and add
> `check-and-set-terms` subcommand to `git bisect--helper` to call it from
> git-bisect.sh
>
> Using `--check-and-set-terms` subcommand is a temporary measure to port
> shell function in C so as to use the ex
Pranit Bauva writes:
> +static int bisect_clean_state(void)
> +{
> + int result = 0;
> +
> + /* There may be some refs packed during bisection */
> + struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
> + for_each_ref_in("refs/bisect/", mark_for_removal, (void *)
> &re
Pranit Bauva writes:
> + for (i = 0; i < rev_nr; i++) {
> + if (!is_expected_rev(revs[i])) {
> + remove_path(git_path_bisect_ancestors_ok());
> + remove_path(git_path_bisect_expected_rev());
> + return 0;
Same comment on
Pranit Bauva writes:
> + if (!file_exists(git_path_bisect_head())) {
> + struct argv_array argv = ARGV_ARRAY_INIT;
> + argv_array_pushl(&argv, "checkout", branch.buf, "--", NULL);
> + if (run_command_v_opt(argv.argv, RUN_GIT_CMD)) {
> +
The documentation for the `git submodule update` command, repeats itself
for each update option, "This is done when is given, or no
option is given and `submodule..update` is set to .
Avoid these repetitive clauses by stating the command line options take
precedence over configured options.
Also
When reading up on a subcommand of `gi submodule`, it is convenient
to have its options nearby and not just at the top of the man page.
Add the options to each subcommand.
While at it, also document the `--checkout` option for `update`.
Signed-off-by: Stefan Beller
---
This mini series applie
Joe Perches writes:
> Hello Florian.
>
> There is at least an oddity with get_maintainer handling of a
> .mailmap entry form.
>
> For instance:
>
> Mauro's .mailmap entry is:
> Mauro Carvalho Chehab
>
>
>
> Is this a valid form?
I do not think so, according to "git shortlog --help" (the
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> Oh, we are already safely in Unrelated Tangent Land for a while, I would
>> think. Nothing of what we are discussing in this thread has anything to do
>> with Kevin's patch series,...
>
> Oh, no question about that. Go back to my review,
Pranit Bauva writes:
> +/*
> + * Check whether the string `term` belongs to the set of strings
> + * included in the variable arguments.
> + */
> +static int one_of(const char *term, ...)
> +{
> + int res = 0;
> + va_list matches;
> + const char *match;
> +
> + va_start(matches, t
Pranit Bauva writes:
> +static int write_terms(const char *bad, const char *good)
> +{
> + FILE *fp;
> + int res;
> +
> + if (!strcmp(bad, good))
> + return error(_("please use two different terms"));
> +
> + if (check_term_format(bad, "bad") || check_term_format(good,
On Tue, Aug 2, 2016 at 3:15 AM, Oleg Taranenko wrote:
> Guys,
>
> thanks for discussion, I will try to reply in bulk here.
> First, assuming the common ancestor is GOOD based on the fact that
> some descendant given as GOOD is pretty bad idea.
> It may be, but may not be. In the git-flow like work
Pranit Bauva writes:
> `--next-all` is meant to be used as a subcommand to support multiple
> "operation mode" though the current implementation does not contain any
> other subcommand along side with `--next-all` but further commits will
> include some more subcommands.
Sounds sensible.
As lon
Duy Nguyen writes:
> OK how about this squashed in? The name was taken from fbsd definition
> IN_LAZYMOD.
I am sorry that I didn't spot this possiblity earlier, but do we
need anything conditional? Either FREEBSD or LAZYMOD prerequisite
tells very little what the "Work around lazy mtime update"
Johannes Schindelin writes:
>> Perhaps hashmap API needs fixing in the longer term not to call this
>> type hashmap_cmp_fn; instead it should lose cmp and say something
>> like hashmap_eq_fn or something.
>
> Maybe.
>
> But to make sure: you do not expect Kevin to do that in the context of
> this
Jakub Narębski writes:
> The problem is that one expects hashmap_cmp_fn() to return ==0 on equality,
> while one would expect for hashmap_eq_fn() to return true (==1) on equality.
> So we would have to rewrite all calling sites.
Yes, and I do not think it is a "problem". There only are about a
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 1 Aug 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > It would be a serious bug if hashmap_entry_init() played games with
>> > references, given its signature (that this function does not have any
>> > access to the hashma
Hello Florian.
There is at least an oddity with get_maintainer handling of a
.mailmap entry form.
For instance:
Mauro's .mailmap entry is:
Mauro Carvalho Chehab
Is this a valid form?
get_maintainer output for Mauro is:
$ ./scripts/get_maintainer.pl drivers/media/ -f
Mauro Carvalho Ch
On 08/02/2016 11:19 AM, Jakub Narębski wrote:
W dniu 01.08.2016 o 17:39, Jeff Hostetler pisze:
On 07/30/2016 01:22 PM, Jakub Narębski wrote:
W dniu 26.07.2016 o 23:11, Jeff Hostetler pisze:
This is a nice change, available because of lack of backward
compatibility with v1. The porcelain v2
On 2016-07-25 6:22 PM, Jeff King wrote:
On Mon, Jul 25, 2016 at 12:34:04PM +0200, Jan Smets wrote:
I have always assumed the post-receive hook to be executed whenever a commit
is "accepted" by the (gitolite) server. That does not seem to be true any
more.
Generally, yeah, I would expect that t
On Mon, Aug 01, 2016 at 02:04:44PM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Mon, Aug 1, 2016 at 3:37 AM, Torstem Bögershausen wrote:
> >> the term FREEBSD may be too generic to point out a single feature
> >> in an OS distributution.
> >> Following your investigations, it may e
W dniu 01.08.2016 o 17:39, Jeff Hostetler pisze:
> On 07/30/2016 01:22 PM, Jakub Narębski wrote:
>> W dniu 26.07.2016 o 23:11, Jeff Hostetler pisze:
>>
>> This is a nice change, available because of lack of backward
>> compatibility with v1. The porcelain v2 format branch-related
>> information co
On Mon, 1 Aug 2016 17:36:31 -0400
Jeff King wrote:
> On Sun, Jul 31, 2016 at 06:39:35PM +0200, Stefan Tauner wrote:
>
> > > There are some output formats that will wrap lines, but by default,
> > > filter-branch should not be using them (and I could not reproduce the
> > > issue in a simple test
From: Jeff Hostetler
The output of `git status --porcelain` leaves out many details
about the current status that clients might like to have. This
can force them to be less efficient as they may need to launch
secondary commands (and try to match the logic within git) to
accumulate this extra in
From: Jeff Hostetler
Update --porcelain argument to take optional version parameter
to allow multiple porcelain formats to be supported in the future.
The token "v1" is the default value and indicates the traditional
porcelain format. (The token "1" is an alias for that.)
Signed-off-by: Jeff H
From: Jeff Hostetler
Renamed the various wt_status_print*() routines to be
wt_longstatus_print*() to make it clear that these
routines are only concerned with the normal/long
status output.
This will hopefully reduce confusion as other status
formats are added in the future.
Signed-off-by: Jeff
From: Jeff Hostetler
Print per-file information in porcelain v2 format.
Signed-off-by: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
wt-status.c | 283 +++-
1 file changed, 282 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/
From: Jeff Hostetler
Expand porcelain v2 output to include branch and tracking
branch information. This includes the commit SHA, the branch,
the upstream branch, and the ahead and behind counts.
Signed-off-by: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
builtin/commit.c | 5
wt-st
From: Jeff Hostetler
Update status manpage to include information about
porcelain V2 format.
Signed-off-by: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
Documentation/git-status.txt | 123 +--
1 file changed, 119 insertions(+), 4 deletions(-)
diff
This patch series adds porcelain V2 format to status.
This provides detailed information about file changes
and about the current branch.
The new output is accessed via:
git status --porcelain=v2 [--branch]
Relative to the V3 patch series, in this V4 patch series
I've updated Documentation/gi
From: Jeff Hostetler
Refactor the API between builtin/commit.c and wt-status.[ch].
Hide details of the various wt_*status_print() routines inside
wt-status.c behind a single (new) wt_status_print() routine
and eliminate the switch statements from builtin/commit.c
This will allow us to more easil
From: Jeff Hostetler
Unit tests for porcelain v2 status format.
Signed-off-by: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
t/t7064-wtstatus-pv2.sh | 585
1 file changed, 585 insertions(+)
create mode 100755 t/t7064-wtstatus-pv2.sh
diff -
Hi Junio,
On Mon, 1 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > It would be a serious bug if hashmap_entry_init() played games with
> > references, given its signature (that this function does not have any
> > access to the hashmap structure, only to the entry itself):
>
On Tue, Jun 14, 2016 at 01:05:41AM -0400, Jeff King wrote:
> On Tue, Jun 14, 2016 at 12:32:15AM -0400, Eric Sunshine wrote:
>
> > > + struct string_list range_list = STRING_LIST_INIT_NODUP;
> >
> > Related to this series, there's an additional "fix" which ought to be
> > made, probably as
Hi Junio,
On Mon, 1 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Fri, 29 Jul 2016, Junio C Hamano wrote:
> >
> >> Kevin Willford writes:
> >>
> >> > static int patch_id_cmp(struct patch_id *a,
> >> > struct patch_id *b,
> >> > -
On Mon, Aug 1, 2016 at 9:54 PM, Junio C Hamano wrote:
> Jakub Narębski writes:
>
>> Good catch!
>>
>> Acked-by: Jakub Narębski
>
> Sigh; the contents may be good but the patch is unusable as-is
> because of heavy whitespace damage.
>
> I'll fix it up. Thanks, both.
My apologies for that, it see
Guys,
thanks for discussion, I will try to reply in bulk here.
First, assuming the common ancestor is GOOD based on the fact that
some descendant given as GOOD is pretty bad idea.
It may be, but may not be. In the git-flow like workflows new features
(aka branches) are created from trunk (master/d
W dniu 01.08.2016 o 22:11, Junio C Hamano pisze:
> Johannes Schindelin writes:
>> On Fri, 29 Jul 2016, Junio C Hamano wrote:
>>> These error returns initially looks slightly iffy in that in general
>>> the caller of any_cmp_fn() wants to know how a/b compares, but by
>>> returning error(), it alw
Hi Junio,
On Mon, 1 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Subject: Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors
>
> s/merge_/merge-/; for this one alone.
I see that de8946de1694a8cf311daab7b2c416d76cb04d23 still shows it with an
underscore ins
Hi Junio,
On Mon, 1 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Previously, callers of merge_trees() or merge_recursive() expected that
> > code to die() with an error message. This used to be okay because we
> > called those commands from scripts, and had a chance to pr
Hi Junio,
On Mon, 1 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I actually now see how this would work well for "reason 2)". If a
> >> caller wants to run the function and wants to pretend as if it did
> >> not run anything when it failed, for example, using this to sp
> On 02 Aug 2016, at 07:53, Johannes Sixt wrote:
>
> Am 01.08.2016 um 13:14 schrieb Lars Schneider:
> >> On 30 Jul 2016, at 11:50, Johannes Sixt wrote:
> >> Am 30.07.2016 um 01:37 schrieb larsxschnei...@gmail.com:
> >>> static struct child_to_clean *children_to_clean;
> >>> @@ -30,6 +31,8 @@ st
66 matches
Mail list logo
