Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Thu, Sep 29, 2016 at 10:19 AM, Junio C Hamano wrote: > Jeff King writes: >> - "cat-file --batch-check" can show you the sha1 and type, but it >> won't abbreviate sha1s, and it won't show you commit/tag information >> >> - "log --stdin --no-walk" will

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Junio C Hamano writes: > Junio C Hamano writes: > >> There still are breakages seen in t5510 and t5526 that are about the >> verbose output of "git fetch". I'll stop digging at this point >> tonight, and welcome others who look into it ;-) > > OK, just

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 9:18 PM, Linus Torvalds wrote: > > There are probably other things like that. t5510-fetch.sh fails oddly, looks like the output is off by one character. not ok 77 - fetch aligned output It has a magic "cut -c 22-" that expects the

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Junio C Hamano writes: > There still are breakages seen in t5510 and t5526 that are about the > verbose output of "git fetch". I'll stop digging at this point > tonight, and welcome others who look into it ;-) OK, just before I leave the keyboard for the night... -- >8 --

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 9:10 PM, Junio C Hamano wrote: > > A quick and dirty fix for it may look like this. Crossed emails. Indeed, I just solved the builtin/rev-parse.c thing slightly differently. And you found another failure in the diff code similarly not liking the

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 8:54 PM, Junio C Hamano wrote: > > * The script uses "git rev-parse --short HEAD"; I suspect that it >says "ah, default_abbrev is -1 and minimum_abbrev is 4, so let's >try abbreviating to 4 hexdigits". Ahh, right you are. The logic there is

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Junio C Hamano writes: > Linus Torvalds writes: > >> So this patch may actually be "production ready" apart from the fact >> that some tests still fail (at least t2027-worktree-list.sh) because >> of different short SHA1 cases. > > t2027 has at

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Linus Torvalds writes: > So this patch may actually be "production ready" apart from the fact > that some tests still fail (at least t2027-worktree-list.sh) because > of different short SHA1 cases. t2027 has at least two problems. * "git worktree" does not read

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 12:06:23PM -0700, Linus Torvalds wrote: > On Thu, Sep 29, 2016 at 11:55 AM, Linus Torvalds > wrote: > > > > For the kernel, just the *math* right now actually gives 12 > > characters. For current git it actually seems to say that 8 is the > >

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:57 PM, Linus Torvalds wrote: > > Actually, all the other cases seem to be "parse a SHA1 with a known > length", so they really don't have a negative length. So this seems > ok, and is easier to verify than the "what all contexts might use

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:56 PM, Mike Hommey wrote: > > OTOH, how often does one refer to trees or blobs with abbreviated sha1s? > Most of the time, you'd use abbreviated sha1s for commits. And the number > of commits in git and the kernel repositories are much lower than the >

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:28 PM, Linus Torvalds wrote: > > To be fair, my original patch had a different worry that I didn't > bother with: what if one of the _other_ callers of "get_short_sha1()" > passed in -1 to it. I only handled the -1 case in th eone path

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:20 PM, Linus Torvalds wrote: > > As you say, my original patch had neither of those issues. To be fair, my original patch had a different worry that I didn't bother with: what if one of the _other_ callers of "get_short_sha1()" passed in

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 4:13 PM, Junio C Hamano wrote: > > One thing that worries me is if we are ready to start accessing the > object store in all codepaths when we ask for DEFAULT_ABBREV. Yes. That was my main worry too. I also looked at just doing an explicit if

Re: [PATCH v6 3/4] ls-files: pass through safe options for --recurse-submodules

Brandon Williams writes: > +static void compile_submodule_options(const struct dir_struct *dir, int > show_tag) > +{ > + if (line_terminator == '\0') > + argv_array_push(_options, "-z"); > + if (show_tag) > + argv_array_push(_options, "-t"); >

Re: [PATCH v2] http: Control GSSAPI credential delegation.

On Wed, Sep 28, 2016 at 08:01:34PM +0200, Petr Stodulka wrote: > Delegation of credentials is disabled by default in libcurl since > version 7.21.7 due to security vulnerability CVE-2011-2192. Which > makes troubles with GSS/kerberos authentication when delegation > of credentials is required.

Re: [PATCH 1/3] add QSORT

Am 30.09.2016 um 01:21 schrieb René Scharfe: > Am 30.09.2016 um 00:36 schrieb Junio C Hamano: >> René Scharfe writes: >> >>> Add the macro QSORT, a convenient wrapper for qsort(3) that infers the >>> size of the array elements and supports the convention of initializing >>> empty

Re: Impossible to change working directory

Sebastian Feldmann writes: > the script fails because changing the current working directory fails. > If I echo the current working directory it always echoes the root repository > path > > Is this expected behavior? Yes, we always go to the top before doing

Re: [PATCH 1/3] add QSORT

Am 30.09.2016 um 00:36 schrieb Junio C Hamano: > René Scharfe writes: > >> Add the macro QSORT, a convenient wrapper for qsort(3) that infers the >> size of the array elements and supports the convention of initializing >> empty arrays with a NULL pointer, which we use in some

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Junio C Hamano writes: > Linus Torvalds writes: > >> The advantage of the >> previous patch was that it got the object counting right almost >> automatically, this actually has its own new object counting code and >> maybe I screwed it up. I

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Linus Torvalds writes: > Somebody should really double-check my heuristics, to see that I did > the pack counting etc right. It doesn't do alternate loose file > counting at all, and maybe it could matter. The advantage of the > previous patch was that it got the

Re: [PATCH 1/3] add QSORT

René Scharfe writes: > Add the macro QSORT, a convenient wrapper for qsort(3) that infers the > size of the array elements and supports the convention of initializing > empty arrays with a NULL pointer, which we use in some places. > > Calling qsort(3) directly with a NULL pointer

Re: [RFC/PATCH 0/2] place cherry pick line below commit title

Jonathan Tan writes: > This is somewhat of a follow-up to my previous e-mail with subject > "[PATCH] sequencer: support folding in rfc2822 footer" [1], in which I > proposed relaxing the definition of a commit message footer to allow > multiple-line field bodies (as

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 12:45 PM, Junio C Hamano wrote: > > I think that is a reasonable way to go. > > #define DEFAULT_ABBREV get_default_abbrev() > > would help. So something like this that replaces the previous patch? Somebody should really double-check my heuristics, to

[PATCH v6 2/4] ls-files: optionally recurse into submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Use top-level --super-prefix option to pass a path to the submodule which it can use to prepend to

[PATCH v6 4/4] ls-files: add pathspec matching for submodules

Pathspecs can be a bit tricky when trying to apply them to submodules. The main challenge is that the pathspecs will be with respect to the superproject and not with respect to paths in the submodule. The approach this patch takes is to pass in the identical pathspec from the superproject to the

[PATCH v6 1/4] git: make super-prefix option

Add a super-prefix environment variable 'GIT_INTERNAL_SUPER_PREFIX' which can be used to specify a path from above a repository down to its root. When such a super-prefix is specified, the paths reported by Git are prefixed with it to make them relative to that directory "above". The paths given

[PATCH v6 3/4] ls-files: pass through safe options for --recurse-submodules

Pass through some known-safe options when recursing into submodules. (--cached, --stage, -v, -t, -z, --debug, --eol) Other options are compiled into an argv_array but if an unsafe option is given the caller will be errored out. Signed-off-by: Brandon Williams ---

Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation

Jakub Narębski writes: > W dniu 29.09.2016 o 19:05, Junio C Hamano pisze: >> Vasco Almeida writes: >> >>> On the other hand, would it make sense to translate these commands? If >>> so, we would mark for translation the commands name of @cmd in >>>

Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation

W dniu 29.09.2016 o 19:05, Junio C Hamano pisze: > Vasco Almeida writes: > >> On the other hand, would it make sense to translate these commands? If >> so, we would mark for translation the commands name of @cmd in >> main_loop(). >> >> sub main_loop { >> - my @cmd

Re: [PATCH v8 00/11] Git filter protocol

Lars Schneider writes: > We discussed that issue in v4 and v6: > http://public-inbox.org/git/20160803225313.pk3tfe5ovz4y3...@sigill.intra.peff.net/ > http://public-inbox.org/git/xmqqbn0a3wy3@gitster.mtv.corp.google.com/ > > My impression was that you don't want Git

Re: [PATCH v2 01/11] i18n: add--interactive: mark strings for translation

W dniu 26.09.2016 o 00:52, Junio C Hamano pisze: > Vasco Almeida writes: >> my $status_fmt = '%12s %12s %s'; >> -my $status_head = sprintf($status_fmt, 'staged', 'unstaged', 'path'); >> +my $status_head = sprintf($status_fmt, __('staged'), __('unstaged'), >>

Re: [PATCH v8 00/11] Git filter protocol

Jeff King writes: > I don't necessarily agree, though, that the timing of filter-process > cleanup needs to be part of the public interface. So in your list: > >> 3) Git waits until the filter process finishes. > > That seems simple and elegant, but I can think of reasons we

Re: [PATCH v8 00/11] Git filter protocol

Jakub Narębski writes: > Or even better: make filter driver write its pid to pidfile, and then > "wait $(cat rot13-filter.pid)". That's what we do in lib-git-daemon.sh > (I think). I am not sure if "wait"ing on a random process that is not a direct child is a reasonable thing

Re: [PATCH v8 00/11] Git filter protocol

Lars Schneider writes: > A pragmatic approach: > > I could drop the "STOP" message that the filter writes to the log > on exit and everything would work as is. We could argue that this > is OK because Git doesn't care anyways if the filter process has > stopped or

Re: [PATCH 2/4] t13xx: do not assume system config is empty

Jeff King writes: > Good description. > > Signed-off-by: Jeff King > > of course. > >> @@ -1304,6 +1315,7 @@ test_expect_success '--show-origin with --get-regexp' ' >> file:$HOME/.gitconfig user.global true >> file:.git/config

Re: [PATCH 2/4] t13xx: do not assume system config is empty

On Thu, Sep 29, 2016 at 02:03:39PM -0700, Junio C Hamano wrote: > > - git config --show-origin --get-regexp "user\.[g|l].*" >output && > > + git config --show-origin --get-regexp "user\.[g|l|s].*" >output && > > test_cmp expect output > > ' > > Makes sense modulo you inherited useless

[PATCH v2 7/9] t1300: be explicit in local configuration tests

Many tests in this script prepare variable settings in the repository local configuration and expects "--list" to report only the ones from the repository local configuration. This happened to work while we were running out tests under GIT_CONFIG_NOSYSTEM and/or with an empty system-wide

[PATCH v2 5/9] t1300: disable system-wide config for tests that wants to read from -c

This test wants to do git -c x.two=2 config --get-regexp ^x\.* and see x.two that came from the one-shot configuration in its output. This form cannot be limited with "--local", as it limits the input to the local configuration file and makes these one-shot settings ignored. At this

[PATCH v2 9/9] core.abbrev: raise the default abbreviation to 12 hexdigits

As Peff said, responding in a thread started by Linus's suggestion to raise the default abbreviation to 12 hexdigits: I actually think "12" might be sane for a long time. That's 48 bits of sha1, so we'd expect a 50% chance of a single collision at 2^24, or 16 million. The biggest

[PATCH v2 8/9] worktree: honor configuration variables

The command accesses default_abbrev (defined in environment.c and is updated via core.abbrev configuration), but never makes any call to git_config(). The output from "worktree list" ignores the abbrev setting for this reason. Make a call to git_config() to read the default set of configuration

[PATCH v2 4/9] t1300: check also system-wide configuration file in --show-origin tests

From: Jeff King Because we used to run our tests with GIT_CONFIG_NOSYSTEM, these did not test that the system-wide configuration file is also read and shown as one of the origins. Create a custom/fake system-wide configuration file and make sure it appears in the output, using

[PATCH v2 6/9] t1300: take contents of system-wide configuration into account in "--list" test

One of the "git config" test tries to see that the command run without a valid repository still shows non-repository specific configuration. As we are planning to later make the system-wide file non-empty, prepare for the change by expecting to see the contents from it. Signed-off-by: Junio C

[PATCH v2 2/9] t1300: always compare expect to actual

The two arguments to the test_cmp helper should always have the expected output first and then the actual one, so that an unmet expectation would appear as -what we wanted to see +what we actually saw in its output. Signed-off-by: Junio C Hamano ---

[PATCH v2 1/9] config: allow customizing /etc/gitconfig location with an environment

We introduced GIT_CONFIG_NOSYSTEM environment variable at ab88c363 ("allow suppressing of global and system config", 2008-02-06), primarily to protect our tests from random set of configuration variables the system administrators would put in /etc/gitconfig file. Introduce a new environment

[PATCH v2 3/9] t1308: ignore system-wide config in the iteration test

We do not want to keep track of the exact contents of the fake system-wide t/gitconfig-for-test configuration file. Keep ignoring it as we used to. Signed-off-by: Junio C Hamano --- t/t1308-config-set.sh | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 0/9] allow customizing /etc/gitconfig location with an environment

This ended up growing quite a bit, and I mostly hate it. - Patch 1 introduces GIT_CONFIG_SYSTEM_PATH environment variable that lets you point at a file other than /etc/gitconfig to pretend that your file is the system-wide configuration. - Patch 2 is a small bugfix. - Patches 3-7 are

Re: [PATCH v8 00/11] Git filter protocol

W dniu 29.09.2016 o 13:57, Torsten Bögershausen pisze: > On 29/09/16 12:28, Lars Schneider wrote: >> This is what happens: >> >> 1) Git exits >> 2) The filter process receives EOF and prints "STOP" to the log >> 3) t0021 checks the content of the log >> >> Sometimes 3 happened before 2 which

Re: [PATCH v8 00/11] Git filter protocol

> On 29 Sep 2016, at 18:57, Junio C Hamano wrote: > > Torsten Bögershausen writes: > >>> 1) Git exits >>> 2) The filter process receives EOF and prints "STOP" to the log >>> 3) t0021 checks the content of the log >>> >>> Sometimes 3 happened before 2 which

Re: [PATCH 2/4] t13xx: do not assume system config is empty

Jeff King writes: > I just don't see it being a problem. Adding core.abbrev for the whole > test suite is just about not having a big flag day where we change all > the tests. Changing one or two tests (and again, I'd be surprised if we > even have to do that) doesn't seem like a

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Linus Torvalds writes: > But you could easily also just instead have it do something like > > if (default_abbrev < 0) > default_abbrev = initialize_abbrev(); > > at startup time if "abbrev_commit" is set, and just do it once and for > all rather

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 12:16 PM, Jeff King wrote: > > Hmm. So at length 7, we expect collisions at 2^14, which is 16384. That > seems really low. I mean, by the birthday paradox that's where expect > a 50% chance of a collision. But that's a single collision. We > definitely don't

Impossible to change working directory

Hi there, I have a problem executing a pre-commit hook. The hook script has to change the working directory to work and if I use plain git commit it works as expected, the script executes without errors, but if I use git commit —only file.x file.y the script fails because changing the current

Re: [PATCH 2/4] t13xx: do not assume system config is empty

On Thu, Sep 29, 2016 at 12:06:15PM -0700, Junio C Hamano wrote: > I think it deserves a separate patch and the result is more > understandable. I've queued this for now (on top of a revised 1/4 > that uses GIT_CONFIG_SYSTEM_PATH instead). Thanks, makes sense (and I like the new variable name

[RFC/PATCH 2/2] sequencer: allow origin line below commit title

When git cherry-pick -x is invoked, a "(cherry picked from commit ...)" line is appended to the footer of a commit message that Git interprets to contain a footer; otherwise it is appended at the end as a new paragraph, preceded by a blank line. This behavior may appear inconsistent, especially to

[RFC/PATCH 0/2] place cherry pick line below commit title

This is somewhat of a follow-up to my previous e-mail with subject "[PATCH] sequencer: support folding in rfc2822 footer" [1], in which I proposed relaxing the definition of a commit message footer to allow multiple-line field bodies (as described in RFC2822), but its strictness was deemed

[RFC/PATCH 1/2] sequencer: refactor message and origin appending

Move the appending of the commit message and origin information into its own function, in preparation for a subsequent patch. Signed-off-by: Jonathan Tan --- sequencer.c | 46 -- 1 file changed, 28 insertions(+), 18

Re: [PATCH 2/4] t13xx: do not assume system config is empty

On Thu, Sep 29, 2016 at 11:57:02AM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> "either" meaning "we do not need to add --local and we do not need > >> GIT_CONFIG_NOSYSTEM"? > > > > Yes. I didn't test it with your core.abbrev patch 4/4, but I _didn't_ > > have to touch

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:55:46AM -0700, Linus Torvalds wrote: > I think the patch can speak for itself, but the basic core is this > section in get_short_sha1(): > > + if (len < 16 && !status && (flags & GET_SHA1_AUTOMATIC)) { > + unsigned int expect_collision = 1 <<

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:55 AM, Linus Torvalds wrote: > > For the kernel, just the *math* right now actually gives 12 > characters. For current git it actually seems to say that 8 is the > correct number. For small projects, you'll still see 7. Sorry, the git

Re: [PATCH 2/4] t13xx: do not assume system config is empty

Jeff King writes: > On Thu, Sep 29, 2016 at 11:13:45AM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > I think anytime you would use GIT_CONFIG_NOSYSTEM over --local, it is an >> > indication that the test is trying to check how multiple sources >> >

Re: [PATCH 2/4] t13xx: do not assume system config is empty

Jeff King writes: >> "either" meaning "we do not need to add --local and we do not need >> GIT_CONFIG_NOSYSTEM"? > > Yes. I didn't test it with your core.abbrev patch 4/4, but I _didn't_ > have to touch their expected output after pointing them at a non-empty > etc-gitconfig file

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:37 AM, Linus Torvalds wrote: > > I'm playing with an early patch to make the default more dynamic. > Let's see how well it works in practice, but it looks fairly > promising. Let me test a bit more and send out an RFC patch.. Ok, this is

Re: [PATCH/RFC] git log --oneline alternative with dates, times and initials

Jeff King writes: > But I also buy the argument that contrib/ is simply a hassle. This > script can live in its own repository somewhere, and handle > announcements and patches on the list. I think the output of this script is largely personal preference, which can be made to a

Re: [PATCH v5 1/4] git: make super-prefix option

On 09/29, Jeff King wrote: > On Wed, Sep 28, 2016 at 02:50:40PM -0700, Brandon Williams wrote: > > > Add a super-prefix environment variable 'GIT_INTERNAL_SUPER_PREFIX' > > which can be used to specify a path from above a repository down to its > > root. The immediate use of this option is by

Re: [PATCH v5 1/4] git: make super-prefix option

On Wed, Sep 28, 2016 at 02:50:40PM -0700, Brandon Williams wrote: > Add a super-prefix environment variable 'GIT_INTERNAL_SUPER_PREFIX' > which can be used to specify a path from above a repository down to its > root. The immediate use of this option is by commands which have a >

Re: [PATCH v8 00/11] Git filter protocol

Am 29.09.2016 um 20:18 schrieb Torsten Bögershausen: I would agree that Git should not wait for the filter. But does the test suite need to wait for the filter ? We have fixed a test case on Windows recently where a process hung around too long (5babb5bd). So, yes, the test suite has to wait

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:05 AM, Junio C Hamano wrote: > > Yes, "git log --oneline" looks somewhat different and strange for > me, too ;-) I'm playing with an early patch to make the default more dynamic. Let's see how well it works in practice, but it looks fairly promising.

Re: [PATCH 5/5] log: add --commit-header option

On Thu, Sep 29, 2016 at 10:49:04AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > This lets you stick a header right before a commit, but > > suppresses headers that are duplicates. This means you can > > do something like: > > > > git log --graph --author-date-order

Re: [PATCH/RFC] git log --oneline alternative with dates, times and initials

On Thu, Sep 29, 2016 at 10:38:14AM -0700, Junio C Hamano wrote: > > I have no problem taking this in contrib or whatever, until a point when > > Git is capable of doing the same thing itself. I just hoped to trick you > > into working on Git. :) > > I thought we stopped adding random things to

Re: [PATCH 2/4] t13xx: do not assume system config is empty

On Thu, Sep 29, 2016 at 11:13:45AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I think anytime you would use GIT_CONFIG_NOSYSTEM over --local, it is an > > indication that the test is trying to check how multiple sources > > interact. And the right thing to do for them

Re: [PATCH v8 00/11] Git filter protocol

On 29/09/16 19:57, Lars Schneider wrote: On 29 Sep 2016, at 18:57, Junio C Hamano wrote: Torsten Bögershausen writes: 1) Git exits 2) The filter process receives EOF and prints "STOP" to the log 3) t0021 checks the content of the log Sometimes 3 happened

Re: [PATCH 2/4] t13xx: do not assume system config is empty

Jeff King writes: > I think anytime you would use GIT_CONFIG_NOSYSTEM over --local, it is an > indication that the test is trying to check how multiple sources > interact. And the right thing to do for them is to set GIT_ETC_GITCONFIG > to some known quantity. We just couldn't do

Re: Two bugs in --pretty with %C(auto)

Am 17.09.2016 um 20:25 schrieb René Scharfe: > diff --git a/pretty.c b/pretty.c > index 9788bd8..493edb0 100644 > --- a/pretty.c > +++ b/pretty.c > @@ -1072,6 +1072,8 @@ static size_t format_commit_one(struct strbuf *sb, /* > in UTF-8 */ > case 'C': > if

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Johannes Sixt writes: > Am 29.09.2016 um 01:30 schrieb Junio C Hamano: >> As Peff said, responding in a thread started by Linus's suggestion >> to raise the default abbreviation to 12 hexdigits: > > This is waayy too large for a new default. The vast majority of > repositories is

Re: [PATCH v8 00/11] Git filter protocol

On Thu, Sep 29, 2016 at 09:57:57AM -0700, Junio C Hamano wrote: > > +wait_for_filter_termination () { > > + while ! grep "STOP" LOGFILENAME >/dev/null > > + do > > + echo "Waiting for /t0021/rot13-filter.pl to finish..." > > + sleep 1 > > + done > > +} > > Running "ps"

Re: [PATCH v8 00/11] Git filter protocol

> On 29 Sep 2016, at 18:57, Junio C Hamano wrote: > > Torsten Bögershausen writes: > >>> 1) Git exits >>> 2) The filter process receives EOF and prints "STOP" to the log >>> 3) t0021 checks the content of the log >>> >>> Sometimes 3 happened before 2 which

Re: [PATCH 5/5] log: add --commit-header option

Jeff King writes: > This lets you stick a header right before a commit, but > suppresses headers that are duplicates. This means you can > do something like: > > git log --graph --author-date-order --commit-header='== %as ==' > > to get a marker in the graph whenever the day

Re: [PATCH 1/4] config: allow customizing /etc/gitconfig location

Junio C Hamano writes: > Jakub Narębski writes: > >> W dniu 29.09.2016 o 01:30, Junio C Hamano pisze: >>> With a new environment variable GIT_ETC_GITCONFIG, the users can >>> specify a file that is used instead of /etc/gitconfig to read (and >>> write) the

Re: [PATCH/RFC] git log --oneline alternative with dates, times and initials

Jeff King writes: >> Those patches are missing some of the features like showing root commits, >> handling two letter initials, showing the weekday, inserting a break where >> needed to avoid parent-child confusion in graph output and properly handling >> Duy's initials. :) > >

Re: [PATCH 2/5] pretty: allow formatting names as initials

On Thu, Sep 29, 2016 at 10:31:30AM -0700, Junio C Hamano wrote: > > When I first tested it with "git log --format=%aS" I had to wonder "who > > the heck is ntnd?". So using only the first-and-last would match the git > > project's practice better, at least. > > And there is also "isalpha() good

Re: [PATCH 2/5] pretty: allow formatting names as initials

Jeff King writes: > Initials are shorter and often unique enough in a > per-project setting, so they can be used to give a more > informative version of --oneline. > > The 'S' in the placeholder is for "short" (and 's' is > already taken by DATE_SHORT), but obviously that's pretty

Re: [PATCH 1/4] config: allow customizing /etc/gitconfig location

Jakub Narębski writes: > W dniu 29.09.2016 o 01:30, Junio C Hamano pisze: >> With a new environment variable GIT_ETC_GITCONFIG, the users can >> specify a file that is used instead of /etc/gitconfig to read (and >> write) the system-wide configuration. > > Why it is named

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

Jeff King writes: >> $ git rev-parse --disambiguate-list=b2e1 >> b2e1196 tag v2.8.0-rc1 >> b2e11d1 tree >> b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options' >> b2e1759 blob >> b2e18954 blob >> b2e1895c blob > > I think the "right" way to do this is pipe the list

Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation

Vasco Almeida writes: > On the other hand, would it make sense to translate these commands? If > so, we would mark for translation the commands name of @cmd in > main_loop(). > > sub main_loop { > - my @cmd = ([ 'status', \_cmd, ], > - [ 'update',

Re: [PATCH v8 00/11] Git filter protocol

Torsten Bögershausen writes: >> 1) Git exits >> 2) The filter process receives EOF and prints "STOP" to the log >> 3) t0021 checks the content of the log >> >> Sometimes 3 happened before 2 which makes the test fail. >> (Example: https://travis-ci.org/git/git/jobs/162660563 ) >>

[PATCH 1/3] add QSORT

Add the macro QSORT, a convenient wrapper for qsort(3) that infers the size of the array elements and supports the convention of initializing empty arrays with a NULL pointer, which we use in some places. Calling qsort(3) directly with a NULL pointer is undefined -- even with an element count of

[PATCH 3/3] remove unnecessary check before QSORT

Add a semantic patch for removing checks similar to the one that QSORT already does internally and apply it to the code base. Signed-off-by: Rene Scharfe --- builtin/fmt-merge-msg.c| 10 -- contrib/coccinelle/qsort.cocci | 18 ++ sh-i18n--envsubst.c

[PATCH 2/3] use QSORT

Apply the semantic patch contrib/coccinelle/qsort.cocci to the code base, replacing calls of qsort(3) with QSORT. The resulting code is shorter and supports empty arrays with NULL pointers. Signed-off-by: Rene Scharfe --- Freshly generated using coccicheck, compiles, survives make

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Thu, Sep 29, 2016 at 07:36:27AM -0700, Kyle J. McKay wrote: > On Sep 29, 2016, at 06:24, Jeff King wrote: > > > > If you are doing "git show 235234" it should pick the tag (if it > > > peels to a > > > committish) because Git has already set a precedent of preferring > > > tags over > > >

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Sep 29, 2016, at 06:24, Jeff King wrote: If you are doing "git show 235234" it should pick the tag (if it peels to a committish) because Git has already set a precedent of preferring tags over commits when it disambiguates ref names and otherwise pick the commit. I'm not convinced

Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation

A Dom, 25-09-2016 às 15:54 -0700, Junio C Hamano escreveu: > >  sub status_cmd { > > @@ -1573,14 +1573,14 @@ sub quit_cmd { > >  } > >   > >  sub help_cmd { > > - print colored $help_color, <<\EOF ; > > -status    - show paths with changes > > + print colored $help_color, __( > >

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Thu, Sep 29, 2016 at 06:01:51AM -0700, Kyle J. McKay wrote: > But perhaps it makes sense to actually pick one if there's only one > disambiguation of the type you're looking for. > > For example given: > > 235234a blob > 2352347 tag > 235234f tree > 2352340 commit > > If you are doing "git

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Thu, Sep 29, 2016 at 04:46:19AM -0700, Kyle J. McKay wrote: > This hint: information is excellent. There needs to be a way to show it on > demand. > > $ git rev-parse --disambiguate=b2e1 > b2e11962c5e6a9c81aa712c751c83a743fd4f384 > b2e11d1bb40c5f81a2f4e37b9f9a60ec7474eeab >

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Sep 26, 2016, at 09:36, Linus Torvalds wrote: On Mon, Sep 26, 2016 at 5:00 AM, Jeff King wrote: This patch teaches get_short_sha1() to list the sha1s of the objects it found, along with a few bits of information that may help the user decide which one they meant. This

Re: Changing the default for "core.abbrev"?

On Sep 25, 2016, at 18:39, Linus Torvalds wrote: The kernel, these days, is at roughly 5 million objects, and while the seven hex digits are still often enough for uniqueness (and git will always add digits *until* it is unique), it's long been at the point where I tell people to do git

Re: [PATCH/RFC] git log --oneline alternative with dates, times and initials

On Thu, Sep 29, 2016 at 04:00:06AM -0700, Kyle J. McKay wrote: > > Each of those commits[1] needs some minor polish, and as I'm not really > > that interested in fancy log output myself, I don't plan on working on > > them further. I was mostly curious just how close we were. But if you'd > >

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

Quoting Jeff King : On Thu, Sep 29, 2016 at 04:44:00AM +0200, SZEDER Gábor wrote: > So 12 seems reasonable, and the only downside for it (or for "13", for > that matter) is a few extra bytes. I dunno, maybe people will really > hate that, but I have a feeling these

Re: [PATCH v8 00/11] Git filter protocol

On 29/09/16 12:28, Lars Schneider wrote: On 28 Sep 2016, at 23:49, Junio C Hamano wrote: I suspect that you are preparing a reroll already, but the one that is sitting in 'pu' seems to be flaky in t/t0021 and I seem to see occasional failures from it. I didn't trace where

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Sep 26, 2016, at 05:00, Jeff King wrote: $ git rev-parse b2e1 error: short SHA1 b2e1 is ambiguous hint: The candidates are: hint: b2e1196 tag v2.8.0-rc1 hint: b2e11d1 tree hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit- options' hint: b2e1759 blob hint:

  1   2   >