Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

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

[PATCH] gitmodules: document shallow recommendation

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,

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

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

[PATCH] hashmap: clarify that hashmap_entry can safely be discarded

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

[PATCH] apply: mark some file-local symbols static

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

Re: [PATCH] apply: mark some file-local symbols static

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

Re: [RFC/PATCH v11 09/13] bisect--helper: `bisect_write` shell function in C

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

Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

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. >

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

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

Re: [PATCH 1/2] submodule documentation: add options to the subcommand

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

What's cooking in git.git (Aug 2016, #01; Tue, 2)

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

Re: [PATCH 1/2] submodule documentation: add options to the subcommand

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

Re: [PATCH 1/2] submodule documentation: add options to the subcommand

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

Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

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,

Re: [PATCH v5 14/16] merge-recursive: offer an option to retain the output in 'obuf'

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

Re: [PATCH 1/1 v2] pager: move pager-specific setup into the build

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

Re: [PATCH 1/1 v2] pager: move pager-specific setup into the build

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

Re: git bisect for reachable commits only

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

Re: [RFC/PATCH v11 13/13] bisect--helper: `bisect_start` shell function partially in C

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

Re: [RFC/PATCH v11 09/13] bisect--helper: `bisect_write` shell function in C

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,

Re: [PATCH v3 03/10] pkt-line: add packet_flush_gentle()

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 > >> > >>

Re: [RFC/PATCH v11 12/13] bisect--helper: `get_terms` & `bisect_terms` shell function in C

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) { > +

Re: [RFC/PATCH v11 11/13] bisect--helper: `bisect_next_check` shell function in C

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

Re: [RFC/PATCH v11 10/13] bisect--helper: `check_and_set_terms` shell function in C

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

Re: [RFC/PATCH v11 04/13] bisect--helper: `bisect_clean_state` shell function in C

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/",

Re: [RFC/PATCH v11 08/13] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

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()); > +

Re: [RFC/PATCH v11 07/13] bisect--helper: `bisect_reset` shell function in C

Pranit Bauva writes: > + if (!file_exists(git_path_bisect_head())) { > + struct argv_array argv = ARGV_ARRAY_INIT; > + argv_array_pushl(, "checkout", branch.buf, "--", NULL); > + if (run_command_v_opt(argv.argv, RUN_GIT_CMD)) { > +

[PATCH 2/2] submodule update documentation: don't repeat ourselves

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.

[PATCH 1/2] submodule documentation: add options to the subcommand

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 ---

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

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 >

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

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,... > >

Re: [RFC/PATCH v11 02/13] bisect: rewrite `check_term_format` shell function in C

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; > + >

Re: [RFC/PATCH v11 03/13] bisect--helper: `write_terms` shell function in C

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")

Re: git bisect for reachable commits only

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.

Re: [RFC/PATCH v11 01/13] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

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.

Re: [PATCH] t7063: work around FreeBSD's lazy mtime update feature

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

Re: [[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

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

Re: [[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

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".

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

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

get_maintainer.pl and .mailmap entries with more than 2 addresses

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

Re: [PATCH v3 7/8] status: update git-status.txt for --porcelain=v2

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

Re: Client exit whilst running pre-receive hook : commit accepted but no post-receive hook ran

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

Re: [PATCH] t7063: work around FreeBSD's lazy mtime update feature

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. > >>

Re: [PATCH v3 7/8] status: update git-status.txt for --porcelain=v2

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

Re: Un-paged commit messages in git filter-branch's commit-filter?

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

[PATCH v4 4/8] status: per-file data collection for --porcelain=v2

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

[PATCH v4 3/8] status: support --porcelain[=]

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

[PATCH v4 1/8] status: rename long-format print routines

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

[PATCH v4 5/8] status: print per-file porcelain v2 status data

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

[PATCH v4 6/8] status: print branch info with --porcelain=v2 --branch

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

[PATCH v4 7/8] git-status.txt: describe --porcelain=v2 format

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

[PATCH v4 0/8] status: V2 porcelain status

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

[PATCH v4 2/8] status: cleanup API to wt_status_print

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

[PATCH v4 8/8] status: tests for --porcelain=v2

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

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

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,

[PATCH] blame: drop strdup of string literal

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

Re: [[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

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, > >> >

Re: [PATCH] gitweb: escape link body in format_ref_marker

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

Re: git bisect for reachable commits only

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

Re: [[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

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

Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

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

Re: [PATCH v6 05/16] Prepare the builtins for a libified merge_recursive()

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

Re: [PATCH v3 06/10] run-command: add clean_on_exit_handler

> 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

Re: [PATCH v3 06/10] run-command: add clean_on_exit_handler

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 @@ static void cleanup_children(int sig, int