Johannes Sixt writes:
> Oh! This is a typo. You meant to check s2 for NULL.
>
> And the declaration for s2 should remain, of course.
Yeah, the moral of the story is don't try to do something you do not
usually do X-<.
The second try (the log message is the same).
I do not know if we want to wo
Eric Wong writes:
> Yay! This finally introduces the Linux kernel linked list
> into git. I'm not sure if it's worth the effort to introduce
> cleanup commits to start using it in places where we already
> have doubly-linked list implementations:
>
> (+Cc Nicolas and Lukas)
> * sha1_file.c delt
Am 05.08.2016 um 07:36 schrieb Johannes Sixt:
Am 05.08.2016 um 00:39 schrieb Junio C Hamano:
@@ -955,12 +955,10 @@ void **nedpindependent_comalloc(nedpool *p,
size_t elems, size_t *sizes, void **
*/
char *strdup(const char *s1)
{
-char *s2 = 0;
-if (s1) {
-size_t len = strlen
Am 05.08.2016 um 00:39 schrieb Junio C Hamano:
@@ -955,12 +955,10 @@ void **nedpindependent_comalloc(nedpool *p, size_t elems,
size_t *sizes, void **
*/
char *strdup(const char *s1)
{
- char *s2 = 0;
- if (s1) {
- size_t len = strlen(s1) + 1;
- s2 = ma
On Thu, Sep 10, 2015 at 11:39:49AM -0700, Junio C Hamano wrote:
> The problem with "empty commit trick" is that it is a commit whose
> sole purpose is to describe the series, and its presence makes it
> clear where the series ends, but the topology does not tell where
> the series begins, so it is
On Thu, Sep 10, 2015 at 02:03:48PM -0700, Jacob Keller wrote:
> On Thu, Sep 10, 2015 at 1:09 PM, Philip Oakley wrote:
> > From: "Jacob Keller"
> >>
> >> On Thu, Sep 10, 2015 at 11:44 AM, Junio C Hamano
> >> wrote:
> >>>
> >>> Jacob Keller writes:
> >>>
> I hadn't thought of separating the
On Thu, Aug 04, 2016 at 04:32:02PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > On Thu, Aug 04, 2016 at 03:28:55PM -0700, Junio C Hamano wrote:
> >> * mh/connect (2016-06-06) 10 commits
> >> - connect: [host:port] is legacy for ssh
> >> ...
> >> - connect: document why we sometimes
Junio C Hamano wrote:
> [Graduated to "master"]
> * ew/http-walker (2016-07-18) 4 commits
> (merged to 'next' on 2016-07-18 at a430a97)
> + list: avoid incompatibility with *BSD sys/queue.h
> (merged to 'next' on 2016-07-13 at 8585c03)
> + http-walker: reduce O(n) ops with doubly-linked lis
"Philip Oakley" writes:
>> Updates in 4/8 ("give headings") is reported to break formatting?
>> cf. <57913c97.1030...@xiplink.com>
>
> Just to say I haven't forgotten.
OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
Mike Hommey writes:
> On Thu, Aug 04, 2016 at 03:28:55PM -0700, Junio C Hamano wrote:
>> * mh/connect (2016-06-06) 10 commits
>> - connect: [host:port] is legacy for ssh
>> ...
>> - connect: document why we sometimes call get_port after get_host_and_port
>>
>> Rewrite Git-URL parsing routine
On Tue, Aug 2, 2016 at 11:00 PM, Junio C Hamano wrote:
> 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)
From: "Junio C Hamano"
* po/range-doc (2016-07-20) 8 commits
- doc: revisions - clarify reachability examples
- doc: revisions - define `reachable`
- doc: gitrevisions - clarify 'latter case' is revision walk
- doc: gitrevisions - use 'reachable' in page description
- doc: give headings for th
On Thu, Aug 04, 2016 at 03:28:55PM -0700, Junio C Hamano wrote:
> * mh/connect (2016-06-06) 10 commits
> - connect: [host:port] is legacy for ssh
> - connect: move ssh command line preparation to a separate function
> - connect: actively reject git:// urls with a user part
> - connect: change t
On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
> 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.
Let's try it this way. How about this as a replacement?
-- >8 --
From: Johannes Schindelin
Date: Thu, 4 Aug 2016 18:07:08 +0200
Subject: [PATCH] nedmalloc: work around overzealous GCC 6 warning
With GCC 6, the strdup() function is declared with the "nonnull"
attribute, stating that it is not al
René Scharfe writes:
> This version of strdup() is only compiled if nedmalloc is used instead
> of the system allocator. That means we can't rely on strdup() being
> able to take NULL -- some (most?) platforms won't like it. Removing
> the NULL check would be a more general and overall easier w
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.
Many topics in "Cooking" section t
On Thu, Aug 4, 2016 at 11:54 AM, Michael Giuffrida
wrote:
> On Mon, Aug 1, 2016 at 2:35 PM, Junio C Hamano wrote:
>> 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 t
Am 04.08.2016 um 18:07 schrieb Johannes Schindelin:
With GCC 6, the strdup() function is declared with the "nonnull"
attribute, stating that it is not allowed to pass a NULL value as
parameter.
In nedmalloc()'s reimplementation of strdup(), Postel's Law is heeded
and NULL parameters are handled
Jeff King writes:
> I wondered if that would then let us drop set_warn_routine(), but it
> looks like there are other warning() calls it cares about. So that would
> invalidate the last paragraph here, though I still think converting the
> trace errors to warning() is a reasonable thing to do.
Y
On Thu, Aug 04, 2016 at 01:45:11PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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_PAC
On Thu, Aug 04, 2016 at 01:41:02PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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
Jeff King writes:
> Like you, I have occasionally been bitten by Junio doing a fixup, and
> then I end up re-rolling, and lose that fixup.
... which usually is caught when I receive the reroll, as I try to
apply to the same base and compare the result with the previous
round.
> But I think such
= SUMMARY ===
My public git.git is available here[1]. I regularly keep pushing my work so
anyone interested can track me there. Feel free to participate in the
discussions going on PRs with my mentors. Your comments are valuable.
INTRODUCTION
Jeff King writes:
> 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
Jeff King writes:
> I think it would be nicer to still to print:
>
> warning: first line
> warning: second line
>
> etc. We do that for "advice:", but not the rest of the vreportf
> functions. It might be nice to do that, but we'd have to go back to
> printing into a buffer (since we can't brea
Jeff King writes:
> 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" debugg
Stefan Beller wrote:
> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> wrote:
> > I guess I have no really good idea yet, either, how to retain the ease of
> > access of sending mails to the list, yet somehow keep a strong tie with
> > the original data stored in Git.
>
> Does it have to b
Jeff King writes:
> But now if I limit to "a.t", I get no output at all:
>
> $ git log --format='%m %s' --boundary a..c -- a.t
>
> whereas I would have expected "- a" to show the boundary.
>
> Is this a bug, or are my expectations wrong?
In a range a..c, there is nothing that touches the path,
On Thu, Aug 04, 2016 at 03:40:43PM -0400, Jeff King wrote:
> That makes sense to me. We omit "c" because it doesn't touch "b.t", and
> obviously include "b", which does. We _do_ include the boundary commit,
> even though it doesn't touch the path, which makes sense to me. It
> remains a boundary w
On Thu, Aug 04, 2016 at 12:54:51PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Not that you probably need more random cases of C code, but I happened
> > to be looking at a diff in git.git today, b333d0d6, which is another
> > regression for the compaction heuristic.
>
> Wow, that on
Jeff King writes:
> Not that you probably need more random cases of C code, but I happened
> to be looking at a diff in git.git today, b333d0d6, which is another
> regression for the compaction heuristic.
Wow, that one is _really_ bad. Does it have something to do with
the removal being at the
Michael Haggerty writes:
I agree with Peff about "comment on the voodoo upfront".
> +#define START_OF_FILE_BONUS 9
> +#define END_OF_FILE_BONUS 46
> +#define TOTAL_BLANK_WEIGHT 4
> +#define PRE_BLANK_WEIGHT 16
> +#define RELATIVE_INDENT_BONUS -1
> +#define RELATIVE_INDENT_HAS_BLANK_BONUS 15
> +#
Tests consisting of one line each can be consolidated to have fewer tests
to run as well as fewer lines of code.
When having just a few git commands, do not create a new shell but
use the -C flag in Git to execute in the correct directory.
Signed-off-by: Stefan Beller
---
t/t7408-submodule-refe
Allow users to pass in multiple references, just as clone accepts multiple
references as well.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--he
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 14 +-
git-submodule.sh| 10 ++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index b6f297b..707f201 100644
--- a/builtin/submo
No functional change intended. This commit only changes formatting
to the style we recently use, e.g. starting the body of a test with a
single quote on the same line as the header, and then having the test
indented in the following lines.
Whenever we change directories, we do that in subshells.
Allow the user to pass in multiple references to update_clone.
Currently this is only internal API, but once the shell script is
replaced by a C version, this is needed.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 14 +-
git-submodule.sh| 2 +-
2 files
When giving a --reference while also giving --recurse, the alternates
for the submodules are assumed to be in the superproject as well.
In case they are not, we error out when cloning the submodule.
However the update command succeeds as usual (with no alternates).
Signed-off-by: Stefan Beller
-
Currently when cloning a superproject with --recursive and --reference
only the superproject learns about its alternates. The submodules are
cloned independently, which may incur lots of network costs.
Assume that the reference repository has the submodules at the same
paths as the to-be-clo
Stefan Beller writes:
> I have just reread the scoring function and I think you could pull out the
> `score=indent` assignment (it is always assigned except for indent <0)
>
> if (indent == -1)
>score = 0;
> else
>score = indent;
> ... lots
Let's say I have a simple repo with three paths:
git init -q repo
cd repo
for i in a b c
do
echo content >$i.t
git add $i.t
git commit -qm $i &&
git tag $i
done
If I ask for the top 2 commits,
Michael Haggerty writes:
>>> + }
>>> + /*
>>> +* We have reached the end of the line without finding any non-space
>>> +* characters; i.e., the whole line consists of trailing spaces,
>>> which we
>>> +* are not interested in.
>>> +*/
>>> + retur
On Mon, Aug 1, 2016 at 2:35 PM, Junio C Hamano wrote:
> 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
> a
Michael Haggerty writes:
> This makes it easier to detect whether shifting is possible, and will
> also make the next change easier.
I can see the code keeping track of earliest_end but the above does
not make it clear what the new "continue" is about.
... easier to detect whether shifting is p
Michael Haggerty writes:
> There is no reason for it to take an array and index as argument, as it
> only accesses a single element of the array.
Yup, I think I am partly guilty. The result looks much nicer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
Michael Haggerty writes:
> 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.
I had to read the first sentence three times as "incorrectly forgot"
was a b
Jeff King writes:
> On Thu, Aug 04, 2016 at 12:00:29AM +0200, Michael Haggerty wrote:
>
>> * ix -> i
>> * ixo -> io
>> * ixs -> start
>> * grpsiz -> groupsize
>
> After your change, I immediately understand three of them. But what is
> "io"?
I had the same reaction.
--
To unsubscribe from this
Johannes Schindelin writes:
> 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.
OK. Even thoug
Johannes Schindelin writes:
> 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.
> ...
> diff --git a/merge-recursive.c b/merge-recursive.c
> index ec50932..9e527de 100
Johannes Schindelin writes:
> 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 change
Johannes Schindelin writes:
> 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-recurs
On Thu, Aug 04, 2016 at 05:29:52PM +0200, Johannes Schindelin wrote:
> So my idea was to introduce a new --reword= option to `git commit`
> that would commit an empty patch and let the user edit the commit message,
> later replacing the original one with the new one. This is not *quite* as
> nice
On Thu, Aug 4, 2016 at 10:50 AM, Ed Greenberg wrote:
> On 08/04/2016 01:28 PM, Junio C Hamano wrote:
>>
>> ... indicates that you are not pushing to update the remote
>> repository correctly. Once you get that part working correctly,
>> after you push at the end of the session, you should be able
On Thu, Aug 04, 2016 at 11:34:10AM +, Eric Wong wrote:
> > > --- a/config.mak.uname
> > > +++ b/config.mak.uname
> > > @@ -209,6 +209,7 @@ ifeq ($(uname_S),FreeBSD)
> > > HAVE_PATHS_H = YesPlease
> > > GMTIME_UNRELIABLE_ERRORS = UnfortunatelyYes
> > > HAVE_BSD_SYSCTL = YesPlease
> > > +
Johannes Schindelin writes:
> With GCC 6, the strdup() function is declared with the "nonnull"
> attribute, stating that it is not allowed to pass a NULL value as
> parameter.
>
> In nedmalloc()'s reimplementation of strdup(), Postel's Law is heeded
> and NULL parameters are handled gracefully. G
Ed Greenberg writes:
> Hi, Thanks for reading my question.
>
> I have two copies of code checked out at the same branch. Desktop and
> remote server.
>
> I use an IDE that automatically SFTP transfers each save from the
> desktop to the remote server, so I can run my changes on the server
> envir
Johannes Schindelin writes:
> The newly-added test case wants to commit a file "c.t" (note the lower
> case) when a previous test case already committed a file "C.t". This
> confuses Git to the point that it thinks "c.t" was not staged when "git
> add c.t" was called.
>
> Simply make the naming o
Hey Junio,
On Thu, Aug 4, 2016 at 10:20 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> Hey Junio,
>>
>> On Thu, Aug 4, 2016 at 9:15 PM, Junio C Hamano wrote:
>>> Pranit Bauva writes:
>>>
> Also you do not seem to check the error from the function to smudge
> the "result" you are
On Thu, Aug 4, 2016 at 12:56 AM, Jeff King wrote:
> On Thu, Aug 04, 2016 at 12:00:36AM +0200, Michael Haggerty wrote:
>
>> This table shows the number of diff slider groups that were positioned
>> differently than the human-generated values, for various repositories.
>> "default" is the default "g
Pranit Bauva writes:
> Hey Junio,
>
> On Thu, Aug 4, 2016 at 9:15 PM, Junio C Hamano wrote:
>> Pranit Bauva writes:
>>
Also you do not seem to check the error from the function to smudge
the "result" you are returning from this function.
>>>
>>> Yes I should combine the results from e
On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
wrote:
>
>> If we were to change our workflows drastically, I'd propose to
>> go a way[1] similar to notedb in Gerrit, or git-series,
>
> Gerrit is a huge, non-distributed system. Complex, too. If we change the
> patch submission process, we shou
Andrew Keller writes:
> In summary, I think I prefer #2 from a usability point of view, however I’m
> having
> trouble proving that #1 is actually *bad* and should be disallowed.
Yeah, I agree with your argument from the usability and safety point
of view.
> Any thoughts? Would it be better f
Jeff King writes:
> 2. It calls check_pipe(), which will turn EPIPE into death-by-SIGPIPE
> (in case you had for some reason ignored SIGPIPE).
> ...
>
> Thinking about (2), I'd go so far as to say that the trace actually
> should just be using:
>
> if (write_in_full(...) < 0)
> war
Jeff King writes:
> The cost of write() may vary on other platforms, but the cost of memcpy
> generally shouldn't. So I'm inclined to say that it is not really worth
> micro-optimizing the interface.
>
> I think the other issue is that format_packet() only lets you send
> string data via "%s", so
Johannes Schindelin writes:
>> > Something like this will make the test more consistent with the rest of
>> > the file:
>> >
>> > diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
>> > index 5f29664..e5bbbd8 100755
>> > --- a/t/t5533-push-cas.sh
>> > +++ b/t/t5533-push-cas.sh
>> > @@ -220,7
Hey Junio,
On Thu, Aug 4, 2016 at 9:15 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>>> Also you do not seem to check the error from the function to smudge
>>> the "result" you are returning from this function.
>>
>> Yes I should combine the results from every removal.
>>
>>> Isn't unlink_
With GCC 6, the strdup() function is declared with the "nonnull"
attribute, stating that it is not allowed to pass a NULL value as
parameter.
In nedmalloc()'s reimplementation of strdup(), Postel's Law is heeded
and NULL parameters are handled gracefully. GCC 6 complains about that
now because it
While working on some local setup to allow my poor little laptop to
build and test the Windows-specific patches of Git for Windows on top of
the upstream branches, my development environment updated to use GCC 6,
and these patches were required.
Johannes Schindelin (2):
nedmalloc: fix misleadin
Some code in nedmalloc is indented in a funny way that could be
misinterpreted as if a line after a for loop was included in the loop
body, when it is not.
GCC 6 complains about this in DEVELOPER=YepSure mode.
Signed-off-by: Johannes Schindelin
---
compat/nedmalloc/nedmalloc.c | 8
1 f
Jeff King writes:
> 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
>> > does nothing else than shelling out to a comman
Hi Stefan,
On Wed, 3 Aug 2016, Stefan Beller wrote:
> On Wed, Aug 3, 2016 at 9:07 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 3 Aug 2016, Junio C Hamano wrote:
> >
> >> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
> >> wrote:
> >> >
> >> > I disagree, however, with the suggestion to
On Wed, Aug 3, 2016 at 9:07 PM, Junio C Hamano wrote:
> 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 read
Pranit Bauva writes:
>> Also you do not seem to check the error from the function to smudge
>> the "result" you are returning from this function.
>
> Yes I should combine the results from every removal.
>
>> Isn't unlink_or_warn() more correct helper to use here?
>
> The shell code uses rm -f whi
Pranit Bauva writes:
>>> + res = fprintf(fp, "%s\n%s\n", bad, good);
>>> + res |= fclose(fp);
>>> + return (res < 0) ? -1 : 0;
>>> +}
>>
>> If fprintf(3) were a function that returns 0 on success and negative
>> on error (like fclose(3) is), the pattern to cascade the error
>> return
Hi Peff,
On Wed, 3 Aug 2016, Jeff King wrote:
> On Wed, Aug 03, 2016 at 09:53:18AM -0700, Junio C Hamano wrote:
>
> > > Leaving aside Dscho's questions of whether pulling patches from email is
> > > convenient for most submitters (it certainly is for me, but I recognize
> > > that it is not for
Hi, Thanks for reading my question.
I have two copies of code checked out at the same branch. Desktop and
remote server.
I use an IDE that automatically SFTP transfers each save from the
desktop to the remote server, so I can run my changes on the server
environment.
At the end of the sess
Hi Junio,
On Wed, 3 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > ---
> > Published-As:
> > https://github.com/dscho/git/releases/tag/import-tars-hardlink-v1
>
> A link to a page that lets you download entire source tarball is not
> very useful to most people, except for
---
contrib/diff-highlight/diff-highlight | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/diff-highlight/diff-highlight
b/contrib/diff-highlight/diff-highlight
index ec31356..9364423 100755
--- a/contrib/diff-highlight/diff-highlight
+++ b/contrib/diff-highlight/diff-highlight
@@ -
The newly-added test case wants to commit a file "c.t" (note the lower
case) when a previous test case already committed a file "C.t". This
confuses Git to the point that it thinks "c.t" was not staged when "git
add c.t" was called.
Simply make the naming of the test commits consistent with the pr
Hi Lars & John,
On Thu, 4 Aug 2016, Lars Schneider wrote:
> > On 04 Aug 2016, at 13:32, John Keeping wrote:
> >
> > On Thu, Aug 04, 2016 at 10:03:39AM +0200, Lars Schneider wrote:
> >>
> >>> * jk/push-force-with-lease-creation (2016-07-26) 3 commits
> >>> - push: allow pushing new branches wit
Hi Junio,
On Wed, 3 Aug 2016, Junio C Hamano wrote:
> 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
> > b
> On 04 Aug 2016, at 13:32, John Keeping wrote:
>
> On Thu, Aug 04, 2016 at 10:03:39AM +0200, Lars Schneider wrote:
>>
>>>
>>> * jk/push-force-with-lease-creation (2016-07-26) 3 commits
>>> - push: allow pushing new branches with --force-with-lease
>>> - push: add shorthand for --force-with-le
On 08/03/2016 05:36 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
From: Jeff Hostetler
diff --git a/wt-status.h b/wt-status.h
index 2023a3c..a859a12 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -43,6 +43,15 @@ struct wt_status_change_data {
unsigned new_submodule_commits : 1;
On 08/03/2016 05:28 PM, Junio C Hamano wrote:
Signed-off-by: Jeff Hostetler
Signed-off-by: Jeff Hostetler
Hmm, are these physically the same people? If so, which one do you
want to be known as?
Yes, these are both my addresses. Still struggling a little
with some SMTP issues. Please u
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 pretends not to
understand ANSI color escapes if the MORE environment variable
is left empty, but accepts the same variables as
On Thu, Aug 04, 2016 at 10:03:39AM +0200, Lars Schneider wrote:
>
> >
> > * jk/push-force-with-lease-creation (2016-07-26) 3 commits
> > - push: allow pushing new branches with --force-with-lease
> > - push: add shorthand for --force-with-lease branch creation
> > - Documentation/git-push: fix pl
Jeff King wrote:
> 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 PA
[Some of this answer might have been invalidated by v4;
I might be away from computer for a few days, so I won't be reviewing]
W dniu 03.08.2016 o 15:10, 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:
[...]
Good day!
Software.informer.com would like to inform you that your product GIT by github
2.9.2 has been reviewed by our editors and your program got "100% Clean Award"
http://git.software.informer.com/.
We would be grateful if you place our award with a link to our review on your
website. On o
>
> * jk/push-force-with-lease-creation (2016-07-26) 3 commits
> - push: allow pushing new branches with --force-with-lease
> - push: add shorthand for --force-with-lease branch creation
> - Documentation/git-push: fix placeholder formatting
>
> "git push --force-with-lease" already had enough l
On Thu, Aug 04, 2016 at 12:00:36AM +0200, Michael Haggerty wrote:
> This table shows the number of diff slider groups that were positioned
> differently than the human-generated values, for various repositories.
> "default" is the default "git diff" algorithm. "compaction" is Git 2.9.0
> with the
On Thu, Aug 04, 2016 at 12:00:28AM +0200, Michael Haggerty wrote:
> 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) {
> + $s
On Thu, Aug 04, 2016 at 12:00:31AM +0200, Michael Haggerty wrote:
> 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.
I'd usually complain that there is too much "what" in you
On Thu, Aug 04, 2016 at 12:00:33AM +0200, Michael Haggerty wrote:
> 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
On Thu, Aug 04, 2016 at 12:00:29AM +0200, Michael Haggerty wrote:
> * ix -> i
> * ixo -> io
> * ixs -> start
> * grpsiz -> groupsize
After your change, I immediately understand three of them. But what is
"io"?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
On Wed, Aug 03, 2016 at 04:50:46PM -0700, Stefan Beller wrote:
> I was not asking for undoing these, but giving short cryptic answers myself.
> ;)
> While I agree the variable names are way better than before, the use of while
> instead of for (and then doing another final ++ after the loop) exte
97 matches
Mail list logo
