Re: [PATCH v3] pager: move pager-specific setup into the build

On Thu, Aug 04, 2016 at 03:43:01AM +, Eric Wong wrote: > +PAGER_ENV_CQ = "$(subst ",\",$(subst \,\\,$(PAGER_ENV)))" > +PAGER_ENV_CQ_SQ = $(subst ','\'',$(PAGER_ENV_CQ)) > +BASIC_CFLAGS += -DPAGER_ENV='$(PAGER_ENV_CQ_SQ)' Here we set up CQ_SQ, but there is no PAGER_ENV_SQ. And then... > @@

Re: [PATCH v2] t4130: work around Windows limitation

Am 03.08.2016 um 17:50 schrieb Junio C Hamano: Johannes Sixt writes: The patch itself seems to got whitespace damaged somewhere between you and me, which I fixed up, Sorry for the damaged patch. I forgot that Thunderbird's "Send again" feature as well as copying and pasting

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On Wed, Aug 3, 2016 at 3:36 PM, Michael Haggerty wrote: > On 08/04/2016 12:29 AM, Jacob Keller wrote: >> On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty >> wrote: >> It seems odd to be that a line with "199" spaces and nothing else will >> return

Re: [TIG PATCH] test: make diff/log work with git 2.9

On Tue, Jun 14, 2016 at 4:34 AM, Michael J Gruber wrote: > git 2.9.0 switches the default for diff.renames to true. > > Set this to false in config so that the test suite runs unmodified for > old and new git. Thanks! -- Jonas Fonseca -- To unsubscribe from this

[PATCH v3] pager: move pager-specific setup into the build

From: Junio C Hamano Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. This allows us to set a better default for FreeBSD more(1), which misbehaves if MORE environment variable is left empty, but accepts the same variables

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

Junio C Hamano writes: > I do not think negative (or non-zero) return is an "abuse" at all. > It is misleading in the context of the function whose name has "cmp" > in it, but that is not the fault of this function, rather, the > breakage is more in the API that calls a

Re: What's cooking (interim report)

On Wed, Aug 03, 2016 at 04:06:20PM -0700, Junio C Hamano wrote: > * jk/parseopt-string-list (2016-08-03) 1 commit > - blame: drop strdup of string literal > > A recent API change to parse_opt_string_list() introduced a small > unintended memory leak in the command line parsing of "git blame",

Hello Friend

Hello Friend How is life been with you and your present health condition i hope you are doing great? i saw your profile and i like it so i decided to contact you for a possible relationship and other good business/investment i want to discuss with you,remember that age,race nor ethnic will not

refactoring a branch with e.g. meld how?

I've been asked to seriously reorganize and compress a big branch (75 commits) What I'd like to do is make branches foo_flattened with all commits and branch foo_reorganized starting at the ancestor, then work by incrementally doing meld/commit/meld/commit/etc from foo_flattened into

Re: [PATCH v3 10/10] convert: add filter..process option

[Some of those answers might have been invalidated by v4] W dniu 01.08.2016 o 19:55, Lars Schneider pisze: >> On 01 Aug 2016, at 00:19, Jakub Narębski wrote: >> W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze: >> [...] >>> +static int multi_packet_read(int fd_in,

Re: [RFC/PATCH] rebase--interactive: Add "sign" command

On Thu, Aug 4, 2016 at 6:08 AM, Jeff King wrote: > On Wed, Aug 03, 2016 at 09:08:48AM -0700, Junio C Hamano wrote: > >> > However, I could imagine that we actually want this to be more extensible. >> > After all, all you are doing is to introduce a new rebase -i command that >> >

Re: [RFC/PATCH] rebase--interactive: Add "sign" command

On Thu, Aug 4, 2016 at 2:31 AM, Johannes Schindelin wrote: > Hi Chris, > > On Wed, 3 Aug 2016, Chris Packham wrote: > >> This is similar to the existing "reword" command in that it can be used >> to update the commit message the difference is that the editor presented

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

On 2016-08-03 3:54 PM, Junio C Hamano wrote: Jeff King writes: I agree it would be a good property to have. I think it's hard to do atomically, though. Certainly we can wait to tell the other side "your push has been recorded" until after the hook is run. But we would already

Re: [PATCH 2/8] xdl_change_compact(): clarify code

On Wed, Aug 3, 2016 at 4:14 PM, Michael Haggerty wrote: > On 08/04/2016 12:11 AM, Stefan Beller wrote: >> On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty >> wrote: >>> Write things out a bit longer but less cryptically. Add more comments. >> >> By

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On Wed, Aug 3, 2016 at 4:30 PM, Michael Haggerty wrote: > This is an important point for the optimization, but less so for the > implementation of the heuristic here. I was dynamically optimizing the > ten other variables, and everything that goes into the bonus includes >

Re: [PATCH v4 07/12] run-command: add clean_on_exit_handler

On Thu, Aug 04, 2016 at 01:09:57AM +0200, Lars Schneider wrote: > > Or better yet, do not require a shutdown at all. The filter sees EOF and > > knows there is nothing more to do. If we are in the middle of an > > operation, then it knows git died. If not, then presumably git had > > nothing else

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On 08/04/2016 12:51 AM, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 3:41 PM, Michael Haggerty wrote: >> On 08/04/2016 12:30 AM, Stefan Beller wrote: >>> On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty >>> wrote: >>> +return 10 * score

Re: [PATCHv4 6/7] submodule--helper: add remote-branch helper

On Wed, Aug 3, 2016 at 4:13 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c >> index fb90c64..9be2c75 100644 >> --- a/builtin/submodule--helper.c >> +++

Re: [PATCH 2/8] xdl_change_compact(): clarify code

On 08/04/2016 12:11 AM, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty wrote: >> Write things out a bit longer but less cryptically. Add more comments. > > By less cryptic you mean in Git coding style ;) > The original author (do we want to cc

Re: [PATCHv4 6/7] submodule update: allow '.' for branch value

Stefan Beller writes: > Gerrit has a "superproject subscription" feature[1], that triggers a > commit in a superproject that is subscribed to its submodules. > Conceptually this Gerrit feature can be done on the client side with > Git via (except for raciness, error handling

Re: [PATCHv4 6/7] submodule--helper: add remote-branch helper

Stefan Beller writes: > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c > index fb90c64..9be2c75 100644 > --- a/builtin/submodule--helper.c > +++ b/builtin/submodule--helper.c > @@ -899,6 +899,39 @@ static int resolve_relative_path(int argc, const char

Re: What's cooking (interim report)

On Wed, Aug 3, 2016 at 4:06 PM, Junio C Hamano wrote: > > * sb/submodule-update-dot-branch (2016-08-01) 7 commits > - submodule update: allow '.' for branch value > - submodule--helper: add remote-branch helper > - submodule-config: keep configured branch around > -

Re: [PATCH v4 07/12] run-command: add clean_on_exit_handler

> On 04 Aug 2016, at 00:53, Jeff King wrote: > > On Thu, Aug 04, 2016 at 12:15:46AM +0200, Lars Schneider wrote: > >>> I'm not clear on why we want this cleanup filter. It looks like you use >>> it in the final patch to send an explicit shutdown to any filters we >>> start. But

[PATCH 4/7] trace: cosmetic fixes for error messages

The error messages for the trace code are often multi-line; the first line gets a nice "warning:", but the rest are left-aligned. Let's give them an indentation to make sure they stand out as a unit. While we're here, let's also downcase the first letter of each error (our usual style), and break

[PATCH 5/7] trace: correct variable name in write() error message

Our error message for write() always mentions GIT_TRACE, even though we may be writing for a different variable entirely. It's also not quite accurate to say "fd given by GIT_TRACE environment variable", as we may hit this error based on a filename the user put in the variable (we do complain and

What's cooking (interim report)

Quite a many topics have been merged to 'master' and 'next'. As I just did a full "What's cooking" yesterday, I'd only list the new topics and "highlights", the latter of which are what would benefit from the last round of eyeballs from reviewers. Many topics have been in 'Cooking' section even

Re: [PATCH 0/7] minor trace fixes and cosmetic improvements

On Wed, Aug 03, 2016 at 06:56:00PM -0400, Jeff King wrote: > On Wed, Aug 03, 2016 at 05:39:20PM -0400, Jeff King wrote: > > > Thinking about (2), I'd go so far as to say that the trace actually > > should just be using: > > > > if (write_in_full(...) < 0) > > warning("unable to write

[PATCH 1/7] trace: handle NULL argument in trace_disable()

All of the trace functions treat a NULL key as a synonym for the default GIT_TRACE key. Except for trace_disable(), which will segfault. Fortunately, this can't cause any bugs, as the function has no callers. But rather than drop it, let's fix the bug, as I plan to add a caller. Signed-off-by:

[PATCH 6/7] trace: disable key after write error

If we get a write error writing to a trace descriptor, the error isn't likely to go away if we keep writing. Instead, you'll just get the same error over and over. E.g., try: GIT_TRACE_PACKET=42 git ls-remote >/dev/null You don't really need to see: warning: unable to write trace for

[PATCH 0/7] minor trace fixes and cosmetic improvements

On Wed, Aug 03, 2016 at 05:39:20PM -0400, Jeff King wrote: > Thinking about (2), I'd go so far as to say that the trace actually > should just be using: > > if (write_in_full(...) < 0) > warning("unable to write trace to ...: %s", strerror(errno)); > > and we should get rid of

[PATCH 7/7] write_or_die: drop write_or_whine_pipe()

This function has no callers, and is not likely to gain any because it's confusing to use. It unconditionally complains to stderr, but _doesn't_ die. Yet any caller which wants a "gentle" write would generally want to suppress the error message, because presumably they're going to write a better

[PATCH 3/7] trace: use warning() for printing trace errors

Right now we just fprintf() straight to stderr, which can make the output hard to distinguish. It would be helpful to give it one of our usual prefixes like "error:", "warning:", etc. It doesn't make sense to use error() here, as the trace code is "optional" debugging code. If something goes

[PATCH 2/7] trace: stop using write_or_whine_pipe()

The write_or_whine_pipe function does two things: 1. it checks for EPIPE and converts it into a signal death 2. it prints a message to stderr on error The first thing does not help us, and actively hurts. Generally we would simply die from SIGPIPE in this case, unless somebody has taken the

Re: [PATCH v4 07/12] run-command: add clean_on_exit_handler

On Thu, Aug 04, 2016 at 12:15:46AM +0200, Lars Schneider wrote: > > I'm not clear on why we want this cleanup filter. It looks like you use > > it in the final patch to send an explicit shutdown to any filters we > > start. But I see two issues with that: > > > > 1. This shutdown may come at

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On Wed, Aug 3, 2016 at 3:41 PM, Michael Haggerty wrote: > On 08/04/2016 12:30 AM, Stefan Beller wrote: >> On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty >> wrote: >> >>> +return 10 * score - bonus; >> >> Would it make sense to define-ify the

Re: [PATCH v3 10/10] convert: add filter..process option

[Note that some of this might have been invalidated by v4] W dniu 01.08.2016 o 15:32, Lars Schneider pisze: >> On 31 Jul 2016, at 00:05, Jakub Narębski wrote: >> W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze: >>> Git starts the filter on first usage and expects a

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On 08/04/2016 12:30 AM, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty wrote: > >> +return 10 * score - bonus; > > Would it make sense to define-ify the 10 as well > as this is the only hardcoded number in the > scoring function? I started

Re: [PATCH v4 11/12] convert: add filter..process option

On Wed, Aug 03, 2016 at 11:48:00PM +0200, Lars Schneider wrote: > OK. Is this the v2 discussion you are referring to? > http://public-inbox.org/git/1461972887-22100-1-git-send-email-sbeller%40google.com/ > > What format do you suggest? > > packet: git< git-filter-protocol\n > packet:

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On 08/04/2016 12:29 AM, Jacob Keller wrote: > On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty wrote: >> +/* >> + * If a line is indented more than this, get_indent() just returns this >> value. >> + * This avoids having to do absurd amounts of work for data that are not >>

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty wrote: > +return 10 * score - bonus; Would it make sense to define-ify the 10 as well as this is the only hardcoded number in the scoring function? -- To unsubscribe from this list: send the line "unsubscribe git" in

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty wrote: > +/* > + * If a line is indented more than this, get_indent() just returns this > value. > + * This avoids having to do absurd amounts of work for data that are not > + * human-readable text, and also ensures that the

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

Hey Junio, On Tue, Aug 2, 2016 at 11:16 PM, Junio C Hamano wrote: > Pranit Bauva writes: > >> +static int bisect_clean_state(void) >> +{ >> + int result = 0; >> + >> + /* There may be some refs packed during bisection */ >> + struct

Re: [PATCH v4 07/12] run-command: add clean_on_exit_handler

> On 03 Aug 2016, at 23:24, Jeff King wrote: > > On Wed, Aug 03, 2016 at 06:42:20PM +0200, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> Some commands might need to perform cleanup tasks on exit. Let's give >> them an interface for

Re: [PATCH 2/8] xdl_change_compact(): clarify code

On Wed, Aug 3, 2016 at 3:00 PM, Michael Haggerty wrote: > Write things out a bit longer but less cryptically. Add more comments. By less cryptic you mean in Git coding style ;) The original author (do we want to cc Davido?) may disagree. > + > + /* >

[PATCH 3/8] xdl_change_compact(): rename i to end

Rename i to end, and alternate between using start and end as the indexing variable as appropriate. Rename ixref to end_matching_other. Add some more comments. Signed-off-by: Michael Haggerty --- xdiff/xdiffi.c | 70

[PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

Some groups of added/deleted lines in diffs can be slid up or down, because lines at the edges of the group are not unique. Picking good shifts for such groups is not a matter of correctness but definitely has a big effect on aesthetics. For example, consider the following two diffs. The first is

[PATCH 0/8] Better heuristics make prettier diffs

I've talked about this quite a bit on the list already. The idea is to improve ugly diffs like @@ -231,6 +231,9 @@ if (!defined $initial_reply_to && $prompting) { } if (!$smtp_server) { + $smtp_server = $repo->config('sendemail.smtpserver'); +} +if (!$smtp_server)

[PATCH 1/8] xdl_change_compact(): rename some local variables for clarity

* ix -> i * ixo -> io * ixs -> start * grpsiz -> groupsize Signed-off-by: Michael Haggerty --- Thankfully, we don't have to limit indentifers to six characters, so start naming things more understandably. xdiff/xdiffi.c | 66

Re: [PATCH 0/8] Better heuristics make prettier diffs

On 08/04/2016 12:00 AM, Michael Haggerty wrote: > I've talked about this quite a bit on the list already. The idea is to > improve ugly diffs I forgot to note that this patch series is also available from my GitHub account [1] as branch "diff-indent-heuristics". Also, I will be away from my

Re: [PATCH v4 11/12] convert: add filter..process option

> On 03 Aug 2016, at 23:43, Junio C Hamano wrote: > > On Wed, Aug 3, 2016 at 2:37 PM, Lars Schneider > wrote: >>> >>> I think this was already pointed out in the previous review by Peff, >>> but a variable "ret" that says "0 is bad" somehow makes

Re: [PATCH v4 11/12] convert: add filter..process option

On Wed, Aug 3, 2016 at 2:37 PM, Lars Schneider wrote: >> >> I think this was already pointed out in the previous review by Peff, >> but a variable "ret" that says "0 is bad" somehow makes it hard to >> follow the code. Perhaps rename it to "int error", flip the meaning,

[PATCH 4/8] xdl_change_compact(): do one final shift or the other, not both

There is no need to shift the group to match a diff in the other file if we're just going to override that shift based on the compaction heuristic. Note that this changes the behavior if the matching shift would have shifted the group higher than the last blank line: the old code would have

[PATCH 2/8] xdl_change_compact(): clarify code

Write things out a bit longer but less cryptically. Add more comments. Signed-off-by: Michael Haggerty --- I find the loops in the old code, with unfamiliar patterns of embedded increment/decrement operators, confusing, and I think that writing things out a little bit more

[PATCH 6/8] xdl_change_compact(): keep track of the earliest end

This makes it easier to detect whether shifting is possible, and will also make the next change easier. Signed-off-by: Michael Haggerty --- xdiff/xdiffi.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c index

[PATCH 5/8] xdl_change_compact(): fix compaction heuristic to adjust io

The code branch used for the compaction heuristic incorrectly forgot to keep io in sync while the group was shifted. I think that could have led to reading past the end of the rchgo array. Signed-off-by: Michael Haggerty --- I didn't actually try to verify the presence of a

[PATCH 7/8] is_blank_line: take a single xrecord_t as argument

There is no reason for it to take an array and index as argument, as it only accesses a single element of the array. Signed-off-by: Michael Haggerty --- xdiff/xdiffi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xdiff/xdiffi.c

Re: [PATCH v4 01/12] pkt-line: extract set_packet_header()

> On 03 Aug 2016, at 22:18, Junio C Hamano wrote: > > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> set_packet_header() converts an integer to a 4 byte hex string. Make >> this function locally available so that other pkt-line

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

Jeff Hostetler writes: > + else if (!strcmp(arg, "v1") || !strcmp(arg,"1")) Missing SP between arg, and "1" here (FYI, editing it here to fix would affect a later patch that has this line in the context). Other than that looking good so far. -- To unsubscribe from

Re: [PATCH v4 01/12] pkt-line: extract set_packet_header()

On Wed, Aug 03, 2016 at 05:12:21PM -0400, Jeff King wrote: > The alternative is to hand-code it, which is what send_sideband() does > (it uses xsnprintf("%04x") to do the hex formatting, though). After seeing that, I wondered why we need set_packet_header() at all. But we do for the case when we

Re: [PATCH v4 11/12] convert: add filter..process option

> On 03 Aug 2016, at 22:29, Junio C Hamano wrote: > > larsxschnei...@gmail.com writes: > >> +#define FILTER_CAPABILITIES_CLEAN(1u<<0) >> +#define FILTER_CAPABILITIES_SMUDGE (1u<<1) >> +#define FILTER_SUPPORTS_CLEAN(type) ((type) & FILTER_CAPABILITIES_CLEAN) >>

Re: [PATCH v4 11/12] convert: add filter..process option

> On 03 Aug 2016, at 19:45, Junio C Hamano wrote: > > larsxschnei...@gmail.com writes: > >> packet: git< git-filter-protocol\n >> packet: git< version=2\n >> packet: git< capabilities=clean smudge\n > > During the discussion on the future of

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Wed, Jul 27, 2016 at 8:40 AM, Duy Nguyen wrote: > On Tue, Jul 26, 2016 at 8:15 PM, Stefan Beller wrote: >>> How to store stuff in .git is the implementation details that the user >>> does not care about. >> >> They do unfortunately. :( > > Well.. i mean

Re: [PATCH v4 03/12] pkt-line: add packet_flush_gentle()

On Wed, Aug 03, 2016 at 06:42:16PM +0200, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > packet_flush() would die in case of a write error even though for some callers > an error would be acceptable. Add packet_flush_gentle() which writes a > pkt-line >

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

On Wed, Aug 03, 2016 at 01:57:09PM -0700, Junio C Hamano wrote: > All bugs are from my original, I think. Here is a proposed squash. > > * This shouldn't make much difference for @@PAGER_ENV@@, but not >quoting the default assignment, i.e. > > : "${VAR=VAL}" && export VAR > >is

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

Jeff Hostetler writes: > 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

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

Jeff Hostetler writes: > 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. We tend to write

Re: [PATCH v4 07/12] run-command: add clean_on_exit_handler

On Wed, Aug 03, 2016 at 06:42:20PM +0200, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Some commands might need to perform cleanup tasks on exit. Let's give > them an interface for doing this. > > Please note, that the cleanup callback is not executed if

Re: [PATCH v4 01/12] pkt-line: extract set_packet_header()

On Wed, Aug 03, 2016 at 01:18:55PM -0700, Junio C Hamano wrote: > larsxschnei...@gmail.com writes: > > > From: Lars Schneider > > > > set_packet_header() converts an integer to a 4 byte hex string. Make > > this function locally available so that other pkt-line

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

Eric Wong writes: > Junio C Hamano wrote: >> All bugs are from my original, I think. Here is a proposed squash. > > Thanks, I'll take the git-sh-setup changes. > > I actually just rewrote setup_pager_env using split_cmdline and > eliminated all the scary (to

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

Junio C Hamano wrote: > All bugs are from my original, I think. Here is a proposed squash. Thanks, I'll take the git-sh-setup changes. I actually just rewrote setup_pager_env using split_cmdline and eliminated all the scary (to me) pointer arithmetic and avoided strbuf, too.

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

Jeff King writes: > On Mon, Aug 01, 2016 at 09:49:37PM +, Eric Wong wrote: > > You'd want: > > argv_array_pushf(env, "%.*s", (int)(cp - pager_env), pager_env); > > Also: > >> +strbuf_reset(); > > should this be strbuf_release()? If we didn't follow the

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

Hey Junio, On Wed, Aug 3, 2016 at 3:47 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Pranit Bauva writes: >> >>> Reimplement the `bisect_write` shell function in C and add a >>> `bisect-write` subcommand to `git

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

Hey Junio, On Wed, Aug 3, 2016 at 1:55 AM, Junio C Hamano wrote: > 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

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

Hey Junio, On Wed, Aug 3, 2016 at 1:49 AM, Junio C Hamano wrote: > Pranit Bauva writes: > >> +static int bisect_start(struct bisect_terms *terms, int no_checkout, >> + const char **argv, int argc) >> +{ >> + int i, j,

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

Hey Junio, On Wed, Aug 3, 2016 at 12:47 AM, Junio C Hamano wrote: > Pranit Bauva writes: > >> +static int mark_good(const char *refname, const struct object_id *oid, >> + int flag, void *cb_data) >> +{ >> + int *m_good = (int

[PATCHv4 6/7] submodule update: allow '.' for branch value

Gerrit has a "superproject subscription" feature[1], that triggers a commit in a superproject that is subscribed to its submodules. Conceptually this Gerrit feature can be done on the client side with Git via (except for raciness, error handling etc): while [ true ]; do git -C submodule

[PATCHv4 {6,7}/7] submodule update: allow '.' for branch value

This replaces the last two commits of sb/submodule-update-dot-branch. Thanks Jeff for pointing out the possible segfault. In the last commit I removed commented code in the test. Thanks, Stefan diff to sb/submodule-update-dot-branch: diff --git a/builtin/submodule--helper.c

[PATCHv4 6/7] submodule--helper: add remote-branch helper

In a later patch we want to enhance the logic for the branch selection. Rewrite the current logic to be in C, so we can directly use C when we enhance the logic. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- builtin/submodule--helper.c |

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

Hey Junio, On Wed, Aug 3, 2016 at 12:52 AM, Junio C Hamano wrote: > Pranit Bauva writes: > >> +static int bisect_terms(struct bisect_terms *terms, int term_defined) >> +{ >> + if (get_terms(terms)) { >> + fprintf(stderr, "no terms

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

Hey Junio, On Wed, Aug 3, 2016 at 12:23 AM, Junio C Hamano wrote: > 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

Re: [PATCH v4 11/12] convert: add filter..process option

larsxschnei...@gmail.com writes: > +#define FILTER_CAPABILITIES_CLEAN(1u<<0) > +#define FILTER_CAPABILITIES_SMUDGE (1u<<1) > +#define FILTER_SUPPORTS_CLEAN(type) ((type) & FILTER_CAPABILITIES_CLEAN) > +#define FILTER_SUPPORTS_SMUDGE(type) ((type) & FILTER_CAPABILITIES_SMUDGE) I would

Re: [PATCHv3 6/7] submodule--helper: add remote-branch helper

On Wed, Aug 03, 2016 at 01:11:51PM -0700, Stefan Beller wrote: > > Coverity complains about "sub" being NULL here, and indeed, it seems > > like an easy segfault: > > > > $ ./git submodule--helper remote-branch foo > > Segmentation fault > > > > I guess this should return NULL in that case.

Re: [PATCH v3 04/10] pkt-line: call packet_trace() only if a packet is actually send

[This response might have been invalidated by v4] W dniu 01.08.2016 o 14:18, Lars Schneider pisze: >> On 30 Jul 2016, at 14:29, Jakub Narębski wrote: >> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >> I don't buy this explanation. If you want to trace packets,

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

Hey Junio, On Tue, Aug 2, 2016 at 11:01 PM, Junio C Hamano wrote: > 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

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

Hey Junio, On Tue, Aug 2, 2016 at 11:08 PM, Junio C Hamano wrote: > Pranit Bauva writes: > >> +static int write_terms(const char *bad, const char *good) >> +{ >> + FILE *fp; >> + int res; >> + >> + if (!strcmp(bad, good)) >> +

Re: [PATCH v3 02/10] pkt-line: add direct_packet_write() and direct_packet_write_data()

[This response might have been invalidated by v4] W dniu 01.08.2016 o 14:00, Lars Schneider pisze: >> On 30 Jul 2016, at 12:49, Jakub Narębski wrote: >> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >>> >>> Sometimes pkt-line data is already available in a buffer

Re: [PATCH v4 01/12] pkt-line: extract set_packet_header()

larsxschnei...@gmail.com writes: > From: Lars Schneider > > set_packet_header() converts an integer to a 4 byte hex string. Make > this function locally available so that other pkt-line functions can > use it. Didn't I say that this is a bad idea already in an earlier

Re: [PATCHv3 6/7] submodule--helper: add remote-branch helper

On Wed, Aug 3, 2016 at 9:25 AM, Jeff King wrote: > On Thu, Jul 28, 2016 at 05:44:08PM -0700, Stefan Beller wrote: > >> +static const char *remote_submodule_branch(const char *path) >> +{ >> + const struct submodule *sub; >> + gitmodules_config(); >> +

Re: [PATCH] pass constants as first argument to st_mult()

On Wed, Aug 3, 2016 at 12:13 PM, Jeff King wrote: > On Mon, Aug 01, 2016 at 03:31:45PM -0700, Junio C Hamano wrote: > > I think in my head I rewrite any multiplication like "N of M" as having > "N" as the smaller number. I.e., it is conceptually simpler to me to > count five 30's,

Re: [PATCH v3 01/10] pkt-line: extract set_packet_header()

[This response might have been invalidated by v4] W dniu 01.08.2016 o 13:33, Lars Schneider pisze: >> On 30 Jul 2016, at 12:30, Jakub Narębski wrote: >>> #define hex(a) (hexchar[(a) & 15]) >> >> I guess that this is inherited from the original, but this preprocessor >> macro

Re: [PATCH] pass constants as first argument to st_mult()

On Wed, Aug 03, 2016 at 12:59:34PM -0700, Stefan Beller wrote: > I think I'd find calloc intuitive as a typical textbook question, "I > want to have space for "foos", which each cost 5 memory, go figure out > how much I need and hand it back to me". I think it is more a language question than a

Re: [PATCH] pass constants as first argument to st_mult()

On Wed, Aug 3, 2016 at 9:13 PM, Jeff King wrote: > On Mon, Aug 01, 2016 at 03:31:45PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> >> *1* I have a slight suspicion that this is cultural, i.e. how >> >> arithmetic is taught in grade schools. When an

Re: [OT] USENIX paper on Git

On Wed, 3 Aug 2016, Santiago Torres wrote: So if you want to treat Git as a cryptographic end-to-end distribution mechanism, then no, it fails horribly at that. But the state of the art in source code distribution, no matter which system you use, is much less advanced than that. People download

Re: [PATCH] pass constants as first argument to st_mult()

On Wed, Aug 3, 2016 at 12:49 PM, Jeff King wrote: > On Wed, Aug 03, 2016 at 12:41:30PM -0700, Junio C Hamano wrote: > >> On Wed, Aug 3, 2016 at 12:13 PM, Jeff King wrote: >> > On Mon, Aug 01, 2016 at 03:31:45PM -0700, Junio C Hamano wrote: >> > >> > I think in my

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

Jeff King writes: > I agree it would be a good property to have. I think it's hard to do > atomically, though. Certainly we can wait to tell the other side "your > push has been recorded" until after the hook is run. But we would > already have updated the refs locally at that

Re: [PATCH] pass constants as first argument to st_mult()

Jeff King writes: > On Wed, Aug 03, 2016 at 12:41:30PM -0700, Junio C Hamano wrote: > >> On Wed, Aug 3, 2016 at 12:13 PM, Jeff King wrote: >> > On Mon, Aug 01, 2016 at 03:31:45PM -0700, Junio C Hamano wrote: >> > >> > I think in my head I rewrite any multiplication

Re: [PATCH] pass constants as first argument to st_mult()

On Wed, Aug 03, 2016 at 12:41:30PM -0700, Junio C Hamano wrote: > On Wed, Aug 3, 2016 at 12:13 PM, Jeff King wrote: > > On Mon, Aug 01, 2016 at 03:31:45PM -0700, Junio C Hamano wrote: > > > > I think in my head I rewrite any multiplication like "N of M" as having > > "N" as the

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

On Tue, Aug 02, 2016 at 12:01:57PM -0400, Stephen Morton wrote: > Sounds tricky. I do think it's important, almost a 'data integrity' issue, > that IF a commit is received, THEN the post-receive hook must be run. Too > much mission-critical stuff is based on post-receive hooks. I agree it would

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote: > > I'd welcome any feedback, whether on the interface and workflow, the > internals and collaboration, ideas on presenting diffs of patch series, > or anything else. > One other nice thing I've noticed about this tool is the way

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

Junio C Hamano writes: > If you mean to tell the user "I won't describe it in detail, if you > really want to know, > go run blame yourself", spell it out like so. I was hoping that you > can summarize > in-line there to help the readers here. Here is a proposed fixup.

  1   2   >