Christian Couder wrote:
> On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> wrote:
> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > [snip]
> >>
> >> I'd welcome any feedback, whether on the interface and workflow,
"brian m. carlson" wrote:
> On Mon, Aug 01, 2016 at 01:05:56AM +, Eric Wong wrote:
> > + while (*cp && *cp == ' ')
> > + cp++;
>
> So it looks like this function splits on spaces but doesn't provide any
> escaping mechanism. Is there
> On 30 Jul 2016, at 12:30, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> set_packet_header() converts an integer to a 4 byte hex string. Make
>> this function locally available so
The vast majority of error messages in Git's source code which report a
bug use the convention to prefix the message with "BUG:".
As part of cleaning up merge-recursive to stop die()ing except in case of
detected bugs, let's just make the remainder of the bug reports consistent
with the de facto
> On 30 Jul 2016, at 14:29, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> The packet_trace() call is not ideal in format_packet() as we would print
>
> Style; I think the
> On 31 Jul 2016, at 00:05, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected
This is the sixth iteration of the long-awaited re-roll of the attempt to
avoid spawning merge-recursive from the builtin am and use merge_recursive()
directly instead.
The *real* reason for the reroll is that I need a libified recursive
merge to accelerate the interactive rebase by teaching the
> On 30 Jul 2016, at 11:50, Johannes Sixt wrote:
>
> Am 30.07.2016 um 01:37 schrieb larsxschnei...@gmail.com:
>> Some commands might need to perform cleanup tasks on exit. Let's give
>> them an interface for doing this.
>>
>> Signed-off-by: Lars Schneider
> On 30 Jul 2016, at 15:58, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> According to LARGE_PACKET_MAX in pkt-line.h the maximal lenght of a
>> pkt-line packet is 65520 bytes. The
> On 30 Jul 2016, at 14:04, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> packet_flush() would die in case of a write error even though for some
>> callers
>> an error would be
Hi Junio,
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,
> > - void *keydata)
> > + struct diff_options *opt)
> > {
> >
W dniu 01.08.2016 o 09:00, Eric Wong pisze:
> "brian m. carlson" wrote:
>> On Mon, Aug 01, 2016 at 01:05:56AM +, Eric Wong wrote:
>>> + while (*cp && *cp == ' ')
>>> + cp++;
>>
>> So it looks like this function splits on spaces but
Hi Stephen,
On Wed, 27 Jul 2016, Stephen Morton wrote:
> On Wed, Jul 27, 2016 at 11:03 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 27 Jul 2016, Stephen Morton wrote:
> >
> >> diff --git a/sequencer.c b/sequencer.c
> >> index cdfac82..ce06876 100644
> >> ---
It is technically allowed, as per C89, for functions' return type to
be complete structs (i.e. *not* just pointers to structs).
However, it was just an oversight of this developer when converting
Python code to C code in 6d297f8 (Status update on merge-recursive in
C, 2006-07-08) which introduced
The recursive merge machinery accumulates its output in an output
buffer, to be flushed at the end of merge_recursive(). At this point,
we forgot to release the output buffer.
When calling merge_trees() (i.e. the non-recursive part of the recursive
merge) directly, the output buffer is never
The data structure passed to the recursive merge machinery has a feature
where the caller can ask for the output to be buffered into a strbuf, by
setting the field 'buffer_output'.
Previously, we died without flushing, losing accumulated output. With
this patch, we show the output first, and
> On 30 Jul 2016, at 12:49, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> Sometimes pkt-line data is already available in a buffer and it would
>> be a waste of resources to write
It was noticed by Brendan Forster last October that the builtin `git am`
regressed on that. Our hot fix reverted to spawning the recursive merge
instead of using it as a library function.
As we are about to revert that hot fix, after making the recursive merge a
true library function (i.e. a
Last October, we had to change this code to run `git merge-recursive`
in a child process: git-am wants to print some helpful advice when the
merge failed, but the code in question was not prepared to return, it
die()d instead.
We are finally at a point when the code *is* prepared to return
Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14),
we already accumulate the output in a buffer. The idea was to avoid
interfering with the progress output that goes to stderr, which is
unbuffered, when we write to stdout, which is buffered.
We extend that buffering to allow
We are about to libify the recursive merge machinery, where we only
die() in case of a bug or memory contention. To that end, we must heed
negative return values as indicating errors.
This requires our functions to be careful to pass through error
conditions in call chains, and for quite a few
There are a couple of places where return values never indicated errors
before, as wie simply died instead of returning.
But now negative return values mean that there was an error and we have to
abort the operation. Let's do exactly that.
Signed-off-by: Johannes Schindelin
It is possible that a tree cannot be written (think: disk full). We
will want to give the caller a chance to clean up instead of letting
the program die() in such a case.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 4 ++--
1 file changed, 2
Ever since 66a155b (Enable output buffering in merge-recursive.,
2007-01-14), we had a problem: When the merge failed in a fatal way, all
regular output was swallowed because we called die() and did not get a
chance to drain the output buffers.
To fix this, several modifications were necessary:
The recursive merge machinery is supposed to be a library function, i.e.
it should return an error when it fails. Originally the functions were
part of the builtin "merge-recursive", though, where it was simpler to
call die() and be done with error handling.
The existing callers were already
While working on the patch series that avoids die()ing in recursive
merges, the issue came up that bug reports (i.e. die("BUG: ...")
constructs) should never be translated, as the target audience is the
Git developer community, not necessarily the current user, and hence
a translated message would
In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we
changed the code such that it prints the output in one go, to avoid
interfering with the progress output.
Let's make sure that the same holds true when outputting the commit
title: previously, we used several printf()
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 print out a
message in case the command failed fatally (read: with exit code 128).
As scripting
It can be puzzling to see that was_tracked() asks to get an index entry
by name, but does not take a negative return value for an answer.
The reason we have to do this is that cache_name_pos() only looks for
entries in stage 0, even if nobody asked for any stage in particular.
Let's rewrite the
Hi Junio,
On Wed, 27 Jul 2016, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I am not yet sure if it makes sense to mix both the regular output
> > and an error into the same buffer for the callers to process (your
> > "reason 1)" above), and this looks like a wrong
Guys,
further investigation shows, git bisect is broken from its core... really.
Let consider 3rd a bit more complicated scenario
#cd ..
#rm -rf bisect3
mkdir bisect3
cd bisect3
git init
git touch coffee
git commit -am "create coffee"
git branch tee
echo sugar >> coffee
git commit -am "add
Hi Junio,
first of all: Kevin & I are colleagues and I helped prepare this patch
series. I had the idea to have a two-level patch ID to help e.g. when an
alternate object store is hosted on a (slow) network drive.
On Fri, 29 Jul 2016, Junio C Hamano wrote:
> Kevin Willford
On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote:
> Christian Couder wrote:
> > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > wrote:
> > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > > [snip]
> > >>
Hi Junio,
On Fri, 29 Jul 2016, Junio C Hamano wrote:
> Kevin Willford writes:
>
> > This patch series is to remove the hand rolled hashmap in the patch_ids
> > and use the hashmap.h implementation. It also introduces the idea of having
> > a header only patch id so that
Hi Junio,
On Wed, 27 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 311cfa4..a16b150 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -2078,6 +2078,8 @@ int
Hi Junio,
On Wed, 27 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index a16b150..66e93e0 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -2069,6 +2069,7 @@ int
On Mon, Aug 01, 2016 at 01:59:29AM -0700, Josh Triplett wrote:
> On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote:
[snip]
> >
> > I'm not convinced another format/standard is needed besides the
> > email workflow we already use for git and kernel development.
>
> Not all projects use a
Hi Junio,
On Wed, 27 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The data structure passed to the recursive merge machinery has a feature
> > where the caller can ask for the output to be buffered into a strbuf, by
> > setting the field
Hi Junio,
On Wed, 27 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/merge-recursive.h b/merge-recursive.h
> > index d415724..340704c 100644
> > --- a/merge-recursive.h
> > +++ b/merge-recursive.h
> > @@ -13,7 +13,7 @@ struct
On Mon, Aug 01, 2016 at 10:57:02AM +0200, Jakub Narębski wrote:
> W dniu 01.08.2016 o 09:00, Eric Wong pisze:
> > "brian m. carlson" wrote:
> >> So it looks like this function splits on spaces but doesn't provide any
> >> escaping mechanism. Is there any case in
Negative lookahead/lookbehind with `git grep -P` considers the
surrounding lines of an otherwise positive match. This differs from
`grep -P` behavior. It does not repro for *positive*
lookahead/lookbehind.
Example:
$ echo -e 'Bar\nBar Baz\nBat' > test.txt && git add test.txt
$ git grep -P
Hi Junio,
On Wed, 27 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Let's make sure that the same holds true when outputting the commit
> > title: previously, we used several printf() statements to stdout and
> > speculated that stdout's buffer
On 07/29/2016 12:40 AM, Josh Triplett wrote:
I'd like to announce a project I've been working on for a while:
git-series provides a tool for managing patch series with git, tracking
the "history of history". git series tracks changes to the patch series
over time, including rebases and other
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 could be enhanced without risk of breaking parsers,
or having
On Sat, Jul 30, 2016 at 10:24 AM, Christian Couder
wrote:
> -static void read_patch_file(struct strbuf *sb, int fd)
> +static int read_patch_file(struct strbuf *sb, int fd)
> {
> if (strbuf_read(sb, fd, 0) < 0)
> - die_errno("git apply: failed
On Sat, Jul 30, 2016 at 08:18:31PM +0200, René Scharfe wrote:
> The result of st_mult() is the same no matter the order of its
> arguments. It invokes the macro unsigned_mult_overflows(), which
> divides the second parameter by the first one. Pass constants
> first to allow that division to be
On Sat, Jul 30, 2016 at 10:24 AM, Christian Couder
wrote:
> + * Try to apply a patch.
> + *
> + * Returns:
> + * -128 if a bad error happened (like patch unreadable)
> + * -1 if patch did not apply and user cannot deal with it
> + * 0 if the patch applied
> + *
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 even be possible that
> other systems adapt this "feature"?
>
> How about
>
On Sat, Jul 30, 2016 at 10:25 AM, Christian Couder
wrote:
> + /* This is to save some reporting routines */
some?
In case of a reroll could you be more specific?
Specifically mention that we use these for the
muting/when silence is requested.
e.g.
/* These
Jakub Narębski writes:
> Isn't `--reachable-commits` the same as existing `--ancestry-path`
> option to `git log` and friends (I wonder if passing log options to
> bisect, that is: `git bisect --ancestry-path ...` would work)?
Yes, I somehow missed it, but you are absolutely
On Sat, Jul 30, 2016 at 07:36:23PM +0200, René Scharfe wrote:
> Replace uses of strbuf_addf() for adding strings with more lightweight
> strbuf_addstr() calls.
>
> In http-push.c it becomes easier to see what's going on without having
> to verfiy that the definition of PROPFIND_ALL_REQUEST
Brian Henderson writes:
> ---
> contrib/diff-highlight/diff-highlight | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/diff-highlight/diff-highlight
> b/contrib/diff-highlight/diff-highlight
> index ffefc31..ec31356 100755
>
On Mon, Aug 1, 2016 at 12:02 PM, Oleg Taranenko wrote:
> Guys,
>
> further investigation shows, git bisect is broken from its core... really.
> Let consider 3rd a bit more complicated scenario
>
> #cd ..
> #rm -rf bisect3
> mkdir bisect3
> cd bisect3
> git init
> git
On Mon, Aug 01, 2016 at 01:43:03AM +, brian m. carlson wrote:
> On Mon, Aug 01, 2016 at 01:05:56AM +, Eric Wong wrote:
> > +static void setup_pager_env(struct argv_array *env)
> > +{
> > + const char *pager_env = stringify(PAGER_ENV);
> > +
> > + while (*pager_env) {
> > +
Jeff King writes:
> On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote:
>
>> I would propose the following then:
>>
>> - I'll write a patch adding a config option format.from, along with
>> documentation, without changing the default.
>> - The release notes for the
Jeff King writes:
>> So maybe we would have to put reset_ident_date() at the end of the
>> function instead, at least after git_committer_info() is called.
>
> Yes, although "reset and end" still feels a bit weird to me.
>
> I'd almost prefer to just have long-running programs
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 spool
>> all output and error to a
Christian Couder writes:
> Yes, and the reason is that all the ancestors of a good commit are
> considered good.
> That's because git bisect supposes that there is only one transition
> from good to bad.
> Otherwise we would need a more complex algorithm to find all
Junio C Hamano writes:
> Jeff King writes:
>
>>> So maybe we would have to put reset_ident_date() at the end of the
>>> function instead, at least after git_committer_info() is called.
>>
>> Yes, although "reset and end" still feels a bit weird to me.
>>
>> I'd
On Mon, Aug 01, 2016 at 07:46:34PM +0200, Duy Nguyen wrote:
> On Mon, Aug 1, 2016 at 3:05 AM, Eric Wong wrote:
> > From: Junio C Hamano
> >
> > Allowing PAGER_ENV to be set at build-time allows us to move
> > pager-specific knowledge out of our build.
Johannes Schindelin writes:
> Subject: Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors
s/merge_/merge-/; for this one alone.
> There are a couple of places where return values never indicated errors
> before, as wie simply died instead of returning.
On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> > I'd like to announce a project I've been working on for a while:
> >
> > git-series provides a tool for managing patch series with git, tracking
> > the "history of history". git
On Mon, Aug 01, 2016 at 10:49:12AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> So maybe we would have to put reset_ident_date() at the end of the
> >> function instead, at least after git_committer_info() is called.
> >
> > Yes, although "reset and end" still feels a
Jeff King writes:
> I'm not too worried about spaces here. This is a resurrection of an old
> discussion, and in all that time, I think the only realistic suggestions
> for built-in values have been pretty tame.
>
> If this were used to parse arbitrary user-provided runtime
> On 01 Aug 2016, at 00:19, Jakub Narębski wrote:
>
> W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze:
> [...]
>> +Please note that you cannot use an existing filter..clean
>> +or filter..smudge command as filter..process
>> +command.
>
> I think it would be more
On Mon, Aug 01, 2016 at 10:58:47AM -0700, Junio C Hamano wrote:
> diff --git a/commit.c b/commit.c
> index b02f3c4..db24013 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -1543,7 +1543,6 @@ int commit_tree_extended(const char *msg, size_t
> msg_len,
> }
>
> /* Person/date
On Mon, Aug 01, 2016 at 02:12:34PM -0400, Jeff King wrote:
> Before I switched to "reset at the beginning" in my original patch, I
> also noticed this issue, but decided the other way: to only reset after
> a successful creation.
>
> I think in most cases it wouldn't matter anyway, because the
Kirill Smelkov writes:
> Since 6b8fda2d (pack-objects: use bitmaps when packing objects) there
> are two codepaths in pack-objects: with & without using bitmap
> reachability index.
>
> However add_object_entry_from_bitmap(), despite its non-bitmapped
> counterpart
On Sat, Jul 30, 2016 at 11:12:46AM -0700, Josh Triplett wrote:
> > These tests follow a different style from the "--from" tests later in
> > the script (and your second patch does follow it, and puts its test
> > close there). Any reason not to have all of the "from" tests together,
> > and using
On Mon, Aug 01, 2016 at 08:01:13PM +0200, Duy Nguyen wrote:
> > If you are interested, I suggest you read the thread linked earlier:
> >
> > https://public-inbox.org/git/52D87A79.6060600%40rawbw.com/T/#u
> >
> > which discusses this and other issues. But basically, I think you cannot
> > really
Jeff King writes:
> I half-agree. Config that causes unpredictable behavior can break
> somebody else's script that you are running. If you say "oh, I guess I
> shouldn't set that config" and move on with your life, then the config
> hasn't really hurt anybody. If you complain to
Johannes Schindelin writes:
> Hi Junio,
>
> 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,
>> > - void
On Mon, Aug 01, 2016 at 10:35:22AM -0700, Junio C Hamano wrote:
> > I do have to admit that after reading through the "format.*" section of
> > git-config(1), there is quite a bit that is configurable in it. So
> > perhaps we do not need to be as careful about behavior changes as I
> > thought.
>
On Mon, Aug 1, 2016 at 3:05 AM, Eric Wong wrote:
> 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 a better default for FreeBSD where more(1)
On Sat, Jul 30, 2016 at 12:11:05PM -0700, Josh Triplett wrote:
> Josh Triplett (2):
> format-patch: Add a config option format.from to set the default for --from
> format-patch: Default to --from
By the way, I notice that the threading between your patches and cover
letter are broken. Since
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 print out a
> message in case the
On Mon, Aug 01, 2016 at 01:05:57AM +, Eric Wong wrote:
> This allows overriding the build-time PAGER_ENV variable
> at run-time.
>
> Inspired by part 1 of an idea from Kyle J. McKay at:
> https://public-inbox.org/git/62db6def-8b39-4481-ba06-245bf4523...@gmail.com/
This commit message is
On Sat, Jul 30, 2016 at 12:11:11PM -0700, Josh Triplett wrote:
> +enum from {
> + FROM_AUTHOR,
> + FROM_USER,
> + FROM_VALUE,
> +};
> +
> +static void set_from(enum from type, const char *value)
> +{
> + free(from);
> + switch (type) {
> + case FROM_AUTHOR:
> +
Johannes Schindelin writes:
>> This is of course a good change, but we need to assume that no
>> further output is made from the remainder of the function for the
>> change in the next hunk to remove the existing flush to be correct.
> ...
> But you made me realize
On Mon, Aug 1, 2016 at 7:52 PM, Jeff King wrote:
> On Mon, Aug 01, 2016 at 07:46:34PM +0200, Duy Nguyen wrote:
>
>> On Mon, Aug 1, 2016 at 3:05 AM, Eric Wong wrote:
>> > From: Junio C Hamano
>> >
>> > Allowing PAGER_ENV to be set at build-time
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):
>
> void
Christian Couder writes:
>> I think the "previous issue" was that we can ask the user to ask to
>> check one of 'x' or 'y' when given Good and Bad points in a graph like
>> this:
>>
>> x---y---y---o---B
>> \ /
>> x---G---o
>>
>>
On Mon, Aug 01, 2016 at 11:49:09PM +0200, Stefan Tauner wrote:
> > For instance, if I do:
> >
> > git init
> > echo content >file
> > git add file
> > git commit -m "$(perl -e 'print join(" ", 1..100)')"
> >
> > I get a commit message with one long unwrapped line, which I can view
> >
Junio C Hamano wrote:
> Eric Wong writes:
> > 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 a better default for FreeBSD where more(1)
> > is the same binary as
Junio C Hamano writes:
> Stefan Beller writes:
>
>> In cache.h we have a NO_THE_INDEX_COMPATIBILITY_MACROS,
>> and lots of
>> #define foo_bar(..) frob_bar(_index, (..))
>>
>> Could you operate on the raw functions that take pointers to _index
>> and
Josh Triplett writes:
> +static char *from;
> static const char *signature = git_version_string;
> static const char *signature_file;
> static int config_cover_letter;
> @@ -807,6 +808,17 @@ static int git_format_config(const char *var, const char
> *value, void *cb)
>
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 even be possible that
>> other systems
I am in a bit of a pickle. I deleted a remote repo that had a folder
that I belatedly realized I need. The deleted repo exists on a backup
which I restored. How do I extract the needed folder from that restored
repo. Not being a git expert I'm not sure what to do but I cannot find
any recognizable
On Mon, Aug 01, 2016 at 04:58:47PM -0400, Dennis Putnam wrote:
> I am in a bit of a pickle. I deleted a remote repo that had a folder
> that I belatedly realized I need. The deleted repo exists on a backup
> which I restored. How do I extract the needed folder from that restored
> repo. Not being
Michael Giuffrida writes:
> Is this expected behavior, and if so, why/where is this documented?
I do not think "git grep" was designed to do multi-line anything,
with or without lookahead. If you imagine that the implementation
attempts its matches line-by-line, does
Jeff King wrote:
> I don't recall offhand whether git-svn does line-wrapping or any other
> commit-message munging.
Definitely no line-wrapping. Munging is minimal:
it respects i18n.commitencoding, adds a trailing newline,
and "git-svn-id:" line.
--
To unsubscribe from this list:
On Mon, Aug 01, 2016 at 01:47:24PM -0400, Jeff King wrote:
> On Sat, Jul 30, 2016 at 12:11:05PM -0700, Josh Triplett wrote:
>
> > Josh Triplett (2):
> > format-patch: Add a config option format.from to set the default for
> > --from
> > format-patch: Default to --from
>
> By the way, I
Jeff King writes:
> On Sat, Jul 30, 2016 at 07:36:23PM +0200, René Scharfe wrote:
>
>> Replace uses of strbuf_addf() for adding strings with more lightweight
>> strbuf_addstr() calls.
>>
>> In http-push.c it becomes easier to see what's going on without having
>> to verfiy that
On Mon, Aug 01, 2016 at 02:00:46PM -0700, Junio C Hamano wrote:
> > Since multiplication is
> > commutative, it would be correct for st_mult() to just flip the order of
> > arguments it feeds to unsigned_mult_overflows().
> >
> > That may introduce the same inefficiency in other callsites, but I
Christian Couder writes:
> On Sat, Jul 30, 2016 at 7:24 PM, Christian Couder
> wrote:
>>
>> I will send a diff between this version and the previous one, as a
>> reply to this email.
>
> Here is the diff:
The "verbosity" bits, and also
On Mon, Aug 01, 2016 at 02:00:47PM -0400, Jeff King wrote:
> So at this point I think I'd lean towards programs which have multiple
> logical commit operations explicitly saying "I am starting a new
> operation". It may be that we end up attaching more to that in the long
> run than just
On Mon, Aug 1, 2016 at 9:51 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Yes, and the reason is that all the ancestors of a good commit are
>> considered good.
>> That's because git bisect supposes that there is only one transition
>>
Josh Triplett wrote:
> On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote:
> > Christian Couder wrote:
> > > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > > wrote:
> > > > On Thu, Jul 28, 2016 at
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
Jeff King writes:
>> *1* I have a slight suspicion that this is cultural, i.e. how
>> arithmetic is taught in grade schools. When an apple costs 30 yen
>> and I have 5 of them, I was taught to multiply 30x5 to arrive at
>> 150, not 5x30=150, and I am guessing that is because the
1 - 100 of 116 matches
Mail list logo