Re: [PATCH] wt-status: use separate variable for result of shorten_unambiguous_ref

On Sat, Jul 8, 2017 at 3:51 AM, René Scharfe wrote: > Store the pointer to the string allocated by shorten_unambiguous_ref in > a dedicated variable, short_base, and keep base unchanged. A non-const > variable is more appropriate for such an object. It avoids having to > cast

Re: [PATCH] sha1_file: add slash once in for_each_file_in_obj_subdir()

Jeff King writes: > ... And you could even drop origlen by > replacing it with "baselen - 3" at the end. But somehow doing the > computation on the fly actually seems more complicated to me (from the > perspective of a reader who is trying to make sure all is correct). True

Re: [PATCH] sha1_file: add slash once in for_each_file_in_obj_subdir()

On Sun, Jul 09, 2017 at 09:41:51AM -0700, Junio C Hamano wrote: > > On the plus side, this moves an invariant out of the loop. On the minus > > side, it has to introduce an extra variable for "length we add on to" > > versus "dir length to pass to the subdir_cb". That's not rocket science, > >

Bug - Dirty submodule differences between OSX/Ubuntu

Referencing: https://gitlab.com/python-mode-devs/python-mode/issues/36 I reported a bug because when adding the python-mode repo as a submodule in my project, it shows as "dirty". The maintainers of that module reported back that my bug cannot be reproduced. I upgraded my local install to

[PATCH/RFC] rebase: make resolve message clearer for inexperienced users

The git UI can be improved by addressing the error messages to those they help: inexperienced and casual git users. To this intent, it is helpful to make sure the terms used in those messages can be understood by this segment of users, and that they guide them to resolve the problem. In

Call to developers with access to Windows XP

Hi all, it has been a while since Windows XP support has been dropped from Git for Windows (v2.10.0 was the last version to support it), mainly due to the code changes inherited from Cygwin's code base, which discontinued supporting Windows XP after version 2.5.2 (because it became way too

Re: enhancement request : If 2 commits to be squashed together do have the same title and comment ...

On 07/09/2017 08:52 PM, Junio C Hamano wrote: > In the form, it is valid---sending a message to git@vger.kernel.org > is the right way to describe a problem and ask for a help (or better > yet, propose a solution ;-). > > I am guessing that you are talking about "squash" in "rebase -i" > command?

Re: "Branch exists" error while trying to rename a non-existing branch to an existing one

Kaartic Sivaraam writes: > I recently got the following error message by change as a result of the > command, > > $ git branch -m no-branch master > fatal: A branch named 'master' already exists. > > Note: no-branch is an hypothetical branch that doesn't

Re: [PATCH 1/2] commit-template: remove outdated notice about explicit paths

Kaartic Sivaraam writes: > It just recently dawned on me that the message, > > Explicit paths specified without -i or -o; assuming --only paths.. > > is translated and "git grep" shows it's presence in the files present > in the 'po' directory. What should be

Re: enhancement request : If 2 commits to be squashed together do have the same title and comment ...

Toralf Förster writes: > ... then jast squsash them w/o questioning. > > Is this a valid RFE ? In the form, it is valid---sending a message to git@vger.kernel.org is the right way to describe a problem and ask for a help (or better yet, propose a solution ;-). I am

"Branch exists" error while trying to rename a non-existing branch to an existing one

Hello all, I recently got the following error message by change as a result of the command, $ git branch -m no-branch master fatal: A branch named 'master' already exists. Note: no-branch is an hypothetical branch that doesn't exist. Shouldn't I get a 'no-branch' doesn't exist before

Re: [PATCH 1/2] commit-template: remove outdated notice about explicit paths

On Fri, 2017-06-30 at 17:42 +0530, Kaartic Sivaraam wrote: > The notice that "git commit " default to "git commit > --only " was there since 756e3ee0 ("Merge branch > 'jc/commit'", 2006-02-14).  Back then, existing users of Git > expected the command doing "git commit --include ", and > after the

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

René Scharfe writes: > I wonder when we can begin to target C99 in git's source, though. :) Let's get the ball rolling by starting to use some of the useful features like designated initializers, perhaps, in a small, critical and reasonably stable part of the system that anybody

Re: [PATCH v2 3/7] log: do not free parents when walking reflog

Jeff King writes: > On Fri, Jul 07, 2017 at 10:10:54AM -0700, Junio C Hamano wrote: > >> > diff --git a/builtin/log.c b/builtin/log.c >> > index 8ca1de9894..9c8bb3b5c3 100644 >> > --- a/builtin/log.c >> > +++ b/builtin/log.c >> > @@ -374,9 +374,9 @@ static int cmd_log_walk(struct

enhancement request : If 2 commits to be squashed together do have the same title and comment ...

... then jast squsash them w/o questioning. Is this a valid RFE ? -- Toralf PGP C4EACDDE 0076E94E

Re: [PATCH] sha1_file: add slash once in for_each_file_in_obj_subdir()

Jeff King writes: > On Sat, Jul 08, 2017 at 10:59:06AM +0200, René Scharfe wrote: > >> Add the slash between loose object subdirectory and file name just once >> outside the loop instead of overwriting it with each readdir call. >> Redefine baselen as the length with that slash,

Re: git-2.13.2: color.branch.local problem

Leo Razoumov writes: > On Sun, Jul 9, 2017 at 5:57 AM, Jeff King wrote: >> On Sun, Jul 09, 2017 at 05:28:34AM -0400, Jeff King wrote: >> >>> On Sat, Jul 08, 2017 at 03:13:04PM -0400, Leo Razoumov wrote: >>> >>> > When I updated from git-2.10.2 to git-2.13.2

Re: git-2.13.2: color.branch.local problem

On Sun, Jul 9, 2017 at 5:57 AM, Jeff King wrote: > On Sun, Jul 09, 2017 at 05:28:34AM -0400, Jeff King wrote: > >> On Sat, Jul 08, 2017 at 03:13:04PM -0400, Leo Razoumov wrote: >> >> > When I updated from git-2.10.2 to git-2.13.2 my 'color.branch.local' >> > config setting gets

Re: [PATCH] use DIV_ROUND_UP

On 9 July 2017 at 16:01, René Scharfe wrote: > Am 09.07.2017 um 15:25 schrieb Martin Ågren: >> On 8 July 2017 at 12:35, René Scharfe wrote: >>> Convert code that divides and rounds up to use DIV_ROUND_UP to make the >>> intent clearer and reduce the number of magic

Re: [PATCH] use DIV_ROUND_UP

Am 09.07.2017 um 15:25 schrieb Martin Ågren: > On 8 July 2017 at 12:35, René Scharfe wrote: >> Convert code that divides and rounds up to use DIV_ROUND_UP to make the >> intent clearer and reduce the number of magic constants. > ... >> diff --git a/sha1_name.c b/sha1_name.c >> index

Re: [PATCH] sha1_file: add slash once in for_each_file_in_obj_subdir()

Am 09.07.2017 um 13:00 schrieb Jeff King: On Sat, Jul 08, 2017 at 10:59:06AM +0200, René Scharfe wrote: Add the slash between loose object subdirectory and file name just once outside the loop instead of overwriting it with each readdir call. Redefine baselen as the length with that slash, and

Re: [PATCH] use DIV_ROUND_UP

On 8 July 2017 at 12:35, René Scharfe wrote: > Convert code that divides and rounds up to use DIV_ROUND_UP to make the > intent clearer and reduce the number of magic constants. ... > diff --git a/sha1_name.c b/sha1_name.c > index e7f7b12ceb..8c513dbff6 100644 > --- a/sha1_name.c >

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 09.07.2017 um 14:37 schrieb Andreas Schwab: On Jul 09 2017, René Scharfe wrote: [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html You are using an old revision. OK, the final draft of C11 [3] says "The implementation shall behave as if it reads the

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

On Jul 09 2017, René Scharfe wrote: > [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html You are using an old revision. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 09.07.2017 um 00:29 schrieb Junio C Hamano: René Scharfe writes: Am 08.07.2017 um 13:08 schrieb Ramsay Jones: On 08/07/17 09:58, René Scharfe wrote: Avoid running over the end of another -- a C string whose length we don't know -- by using strcmp(3) instead of memcmp(3) for

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 08.07.2017 um 15:38 schrieb Andreas Schwab: On Jul 08 2017, René Scharfe wrote: Am 08.07.2017 um 13:08 schrieb Andreas Schwab: On Jul 08 2017, René Scharfe wrote: Avoid running over the end of another -- a C string whose length we don't know -- by using

Re: Fetching new refs gets progressively slower

On Sun, Jul 09, 2017 at 01:25:06PM +0300, s...@kazlauskas.me wrote: > I have a weird issue where fetching a large number of refs will start off > with lines like these: > > * [new ref] refs/pull/1/head -> origin/pr/1 > * [new ref] refs/pull/10001/head ->

Re: [PATCH] sha1_file: add slash once in for_each_file_in_obj_subdir()

On Sat, Jul 08, 2017 at 10:59:06AM +0200, René Scharfe wrote: > Add the slash between loose object subdirectory and file name just once > outside the loop instead of overwriting it with each readdir call. > Redefine baselen as the length with that slash, and add dirlen for the > length without

Fetching new refs gets progressively slower

I have a weird issue where fetching a large number of refs will start off with lines like these: * [new ref] refs/pull/1/head -> origin/pr/1 * [new ref] refs/pull/10001/head -> origin/pr/10001 going fairly fast, and then progressively getting slower and

Re: [PATCH v2 3/7] log: do not free parents when walking reflog

On Fri, Jul 07, 2017 at 10:10:54AM -0700, Junio C Hamano wrote: > > diff --git a/builtin/log.c b/builtin/log.c > > index 8ca1de9894..9c8bb3b5c3 100644 > > --- a/builtin/log.c > > +++ b/builtin/log.c > > @@ -374,9 +374,9 @@ static int cmd_log_walk(struct rev_info *rev) > > if

Re: [PATCH v2 6/7] reflog-walk: stop using fake parents

On Fri, Jul 07, 2017 at 11:54:05AM -0400, Kyle Meyer wrote: > Jeff King writes: > > > Prior to this commit, we show both entries with > > identical reflog messages. After this commit, we show > > only the "comes back" entry. See the update in t3200 > > which

[PATCH 3/3] branch: set remote color in ref-filter branch immediately

We set the current and local branch colors at the top of the build_format() function. Let's do the same for the remote color. This saves a little bit of repetition, but more importantly it puts all of the color-setting in the same place. That makes it easier to see that we are coloring all

[PATCH 2/3] branch: use BRANCH_COLOR_LOCAL in ref-filter format

Since 949af0684 (branch: use ref-filter printing APIs, 2017-01-10), git-branch's output is generated by passing a custom format to the ref-filter code. This format forgot to pass BRANCH_COLOR_LOCAL, meaning that local branches (besides the current one) were never colored at all. We can add it in

[PATCH 1/3] branch: only perform HEAD check for local branches

When assembling the ref-filter format to show "git branch" output, we put the "%(if)%(HEAD)" conditional at the start of the overall format. But there's no point in checking whether a remote branch matches HEAD, as it never will. The check should go inside the local conditional; we assemble that

Re: git-2.13.2: color.branch.local problem

On Sun, Jul 09, 2017 at 05:28:34AM -0400, Jeff King wrote: > On Sat, Jul 08, 2017 at 03:13:04PM -0400, Leo Razoumov wrote: > > > When I updated from git-2.10.2 to git-2.13.2 my 'color.branch.local' > > config setting gets ignored. Corresponding 'remote' or 'current' > > settings are honored and

Re: git-2.13.2: color.branch.local problem

On Sat, Jul 08, 2017 at 03:13:04PM -0400, Leo Razoumov wrote: > When I updated from git-2.10.2 to git-2.13.2 my 'color.branch.local' > config setting gets ignored. Corresponding 'remote' or 'current' > settings are honored and work as expected Looks like this is a regression from the switch to

Re: [PATCH 1/4] Doc/config.txt: explain repeated sections

Junio C Hamano writes: >> +Multiple occurrences of the same section are all logically merged. (There's >> +no special treatment for variables defined multiple times across physically >> +different sections, the variable is simply made multivalued.) >> + > > Looks correct;

Re: What's cooking in git.git (Jul 2017, #02; Fri, 7)

On Sat, 2017-07-08 at 15:33 -0700, Junio C Hamano wrote: > That is how a message that is BCC'ed to you is supposed to look > like, isn't it? May be not. rfc5322 (Internet Message Format) seems to clear the confusion, There are three ways in which the "Bcc:" field is used. In the first case,