Re: [BUG] add_again() off-by-one error in custom format

On Wed, Jun 14, 2017 at 08:24:25PM +0200, René Scharfe wrote: > > I think the real question is how likely people use more than one > > occurrence of the same thing in their custom format, and how deeply > > they care that --format='%h %h' costs more than --format='%h'. The > > cost won't of

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

On Thu, Jun 15, 2017 at 01:03:29AM +0200, René Scharfe wrote: > Am 14.06.2017 um 23:04 schrieb Johannes Schindelin: > > On Wed, 14 Jun 2017, René Scharfe wrote: > > > >> Does someone actually expect %z to show time zone names instead of > >> offsets on Windows? > > > > Not me ;-) > > > > I

Re: [PATCH] git-svn: document special options for commit-diff

Andreas Heiduk wrote: > Some options specific for `git svn commit-diff` where not documented > so far. > > Signed-off-by: Andreas Heiduk Thanks again. It's been a while since "commit-diff" :) Signed-off and pushed for Junio: The following changes

Subject: [PATCH] config: mark a file-local symbol as static

Signed-off-by: Ramsay Jones --- Hi Sahil, If you need to re-roll your 'sd/branch-copy' branch, could you please squash this into the relevant patch (commit 37af9c71b6, "config: create a function to format section headers", 13-06-2017). Also, I note that another

Re: Minor missing features in worktree compare to new-workdir

>> 2. worktree doesn't seem to support multiple worktree on the same >> branch. > > I think this is a very good thing about worktrees as opposed to > workdirs. > > In a situation where I may want multiple worktrees pointing to the same > commit I just check out the SHA rather than the branch: you

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Am 14.06.2017 um 23:04 schrieb Johannes Schindelin: > On Wed, 14 Jun 2017, René Scharfe wrote: > >> Does someone actually expect %z to show time zone names instead of >> offsets on Windows? > > Not me ;-) > > I cannot speak for anyone else, as I lack that information, though. Before the patch

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Hi, On Wed, 14 Jun 2017, René Scharfe wrote: > Does someone actually expect %z to show time zone names instead of > offsets on Windows? Not me ;-) I cannot speak for anyone else, as I lack that information, though. Ciao, Dscho

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Hi Phillip, On Wed, 14 Jun 2017, Phillip Wood wrote: > From: Phillip Wood > > I've revised the second two tests as Johannes suggested to drop the > sed script. The first one is unchanged. This iteration looks pretty good to me! Ciao, Johannes

Re: [ANNOUNCE] Git for Windows 2.13.1

Hi, On Wed, 14 Jun 2017, Rong Jie wrote: > I am getting crash (return code: c005) when running git diff. Rollback > to 2.13.0 fixes the issue. Please use Git for Windows' bug tracker to report bugs, after making sure that the bug has not yet been reported already:

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Am 14.06.2017 um 13:10 schrieb Jeff King: On Wed, Jun 14, 2017 at 12:57:06PM +0200, Johannes Schindelin wrote: But even then, it fails in t0006 on Windows with this error: -- snip -- ++ eval 'diff -u "$@" ' +++ diff -u expect actual --- expect 2017-06-14 10:53:40.126136900 + +++

Re: [PATCH] diff.c: color moved lines differently

On Tue, Jun 13, 2017 at 3:51 PM, Jonathan Tan wrote: > On Wed, 31 May 2017 17:24:29 -0700 > Stefan Beller wrote: > >> When a patch consists mostly of moving blocks of code around, it can >> be quite tedious to ensure that the blocks are moved

Re: What's cooking in git.git (Jun 2017, #03; Mon, 5)

On Wed, Jun 14, 2017 at 2:54 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> The color experts agreed that (3) might be the best solution >> as this gives most flexibility: >> >> "I would be happy as I can configure the bounds highlighting >>

Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

On 14.06.17 09:42, Lars Schneider wrote: > >> * ls/filter-process-delayed (2017-06-01) 5 commits >> - convert: add "status=delayed" to filter process protocol >> - convert: move multiple file filter error handling to separate function >> - t0021: write "OUT" only on success >> - t0021: make

Re: [PATCH v5 7/7] fsmonitor: add a performance test

Ben Peart writes: >> Having said all that, I think you are using this ONLY on windows; >> perhaps it is better to drop #ifdef GIT_WINDOWS_NATIVE from all of >> the above and arrange Makefile to build test-drop-cache only on that >> platform, or something? > > I didn't find

Re: [PATCH] sub-process: fix comment about api-sub-process.txt

Christian Couder wrote: > Subject: sub-process: fix comment about api-sub-process.txt nit: this one-line description doesn't describe what was wrong and is being fixed. I think something like sub-process: correct path to API docs in comment would be easier to understand in "git log"

Re: [BUG] add_again() off-by-one error in custom format

Am 13.06.2017 um 23:20 schrieb Junio C Hamano: > René Scharfe writes: > >> The difference is about the same as the one between: >> >> $ time git log --format="" >/dev/null >> >> real0m0.463s >> user0m0.448s >> sys 0m0.012s >> >> and: >> >> $

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Johannes Schindelin writes: > Hold on. Have you tried to build this branch? > > -- snip -- > CC date.o > date.c:63:36: error: unknown type name ‘timestamp_t’ > static struct tm *time_to_tm_local(timestamp_t time) > ^ > date.c:

[PATCH v3 1/6] config: create config.h

Move all config related declarations from cache.h to a new config.h header file. This makes cache.h smaller and allows for the opportunity in a following patch to only include config.h when needed. Signed-off-by: Brandon Williams --- cache.h | 190

[PATCH v3 3/6] config: don't include config.h by default

Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams --- advice.c | 1 + alias.c | 1 + apply.c

[PATCH v3 2/6] config: remove git_config_iter

Since there is no implementation of the function 'git_config_iter', let's stop exporting it and remove the prototype from config.h. Signed-off-by: Brandon Williams --- config.h | 1 - 1 file changed, 1 deletion(-) diff --git a/config.h b/config.h index f7f8b66c5..c70599bd5

[PATCH v3 4/6] setup: teach discover_git_directory to respect the commondir

Currently 'discover_git_directory' only looks at the gitdir to determine if a git directory was discovered. This causes a problem in the event that the gitdir which was discovered was in fact a per-worktree git directory and not the common git directory. This is because the repository config,

[PATCH v3 6/6] config: don't implicitly use gitdir or commondir

'git_config_with_options()' takes a 'config_options' struct which contains feilds for 'git_dir' and 'commondir'. If those feilds happen to be NULL the config machinery falls back to querying global repository state. Let's change this and instead use these fields in the 'config_options' struct

[PATCH v3 5/6] config: respect commondir

Worktrees present an interesting problem when it comes to the config. Historically we could assume that the per-repository config lives at 'gitdir/config', but since worktrees were introduced this isn't the case anymore. There is currently no way to specify per-worktree configuration, and as such

[PATCH v3 0/6] config.h

Changes in v3: * tweaked the discover_git_directory function's API based on Peff's feedback * reordered the last three patches so that they flowed a bit better * renamed 'git_config_with_options' * rebased ontop of v4 of Dscho's alias series

Re: [PATCH 1/2] add: warn when adding an embedded repository

On Tue, Jun 13, 2017 at 11:36 PM, Jeff King wrote: > On Tue, Jun 13, 2017 at 10:07:43AM -0700, Stefan Beller wrote: > >> > I also waffled on whether we should ask the submodule code >> > whether it knows about a particular path. Technically: >> > >> > git config

Re: [PATCH v3] Configure Git contribution guidelines for github.com

Lars Schneider wrote: > Many open source projects use github.com for their contribution process. > Although we mirror the Git core repository to github.com [1] we do not > use any other github.com service. This is unknown/unexpected to a > number of (potential) contributors and consequently they

Re: [BUG] add_again() off-by-one error in custom format

Am 14.06.2017 um 00:24 schrieb SZEDER Gábor: [sorry for double post, forgot the mailing list...] To throw in a fourth option, this one adjusts the expansions' cached offsets when the magic makes it necessary. It's not necessary for '%-', because it only makes a difference when the expansion is

Re: [PATCH v3 6/6] Use the early config machinery to expand aliases

On 06/14, Johannes Schindelin wrote: > Hi Peff & Brandon, > > On Wed, 14 Jun 2017, Jeff King wrote: > > > On Tue, Jun 13, 2017 at 11:26:06AM -0700, Brandon Williams wrote: > > > > > So because I've been looking at the config machinery lately, I've > > > noticed a lot of issues with how things

Re: [PATCH v2 5/6] setup: teach discover_git_directory to respect the commondir

On 06/14, Jeff King wrote: > On Tue, Jun 13, 2017 at 02:03:20PM -0700, Brandon Williams wrote: > > > Currently 'discover_git_directory' only looks at the gitdir to determine > > if a git directory was discovered. This causes a problem in the event > > that the gitdir which was discovered was in

Re: [PATCH v2 4/6] config: don't implicitly use gitdir

On 06/14, Jeff King wrote: > On Tue, Jun 13, 2017 at 02:38:15PM -0700, Brandon Williams wrote: > > > > The same comments as before still apply: > > > > > > - this changes API to make opts->git_dir mandatory, which is error prone > > > and easily avoidable, e.g. by making git_dir an argument to

[PATCH] sub-process: fix comment about api-sub-process.txt

Signed-off-by: Christian Couder --- sub-process.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sub-process.h b/sub-process.h index 7d451e1cde..d9a45cd359 100644 --- a/sub-process.h +++ b/sub-process.h @@ -7,7 +7,7 @@ /* * Generic

[PATCH] builtin/clone: get rid of 'value' strbuf

This makes the code simpler by removing a few lines, and getting rid of one variable. Signed-off-by: Christian Couder --- builtin/clone.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index

Re: [PATCH v5 7/7] fsmonitor: add a performance test

On 6/12/2017 6:04 PM, Junio C Hamano wrote: Ben Peart writes: diff --git a/t/helper/test-drop-caches.c b/t/helper/test-drop-caches.c new file mode 100644 index 00..80830d920b --- /dev/null +++ b/t/helper/test-drop-caches.c @@ -0,0 +1,107 @@ +#include

Re: git-gui ignores core.hooksPath

Dear Johannes, thanks for following up, > Indeed. Why don't you give it a try? Actually, I already did: https://github.com/patthoyts/git-gui/pull/12 You might want to post your analysis and patch there as well... cu, Philipp signature.asc Description: OpenPGP digital signature

Re: [PATCH] respect core.hooksPath, falling back to .git/hooks

Hi Philipp, On Fri, 2 Jun 2017, Philipp Gortan wrote: > Signed-off-by: Philipp Gortan I just saw this. I made sure that the thread to which I just replied did not have any news from you, but you simply started a new thread ;-) This commit message needs a little bit of

Re: git-gui ignores core.hooksPath

Hi, On Fri, 2 Jun 2017, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 2, 2017 at 3:41 PM, Philipp Gortan wrote: > > > I've been unhappy for quite a while that I had to configure the hooks > > manually for each of my repos - until I found out recently that there > > is the

[PATCH v5 10/10] rebase -i: rearrange fixup/squash lines using the rebase--helper

This operation has quadratic complexity, which is especially painful on Windows, where shell scripts are *already* slow (mainly due to the overhead of the POSIX emulation layer). Let's reimplement this with linear complexity (using a hash map to match the commits' subject lines) for the common

[PATCH v5 09/10] t3415: test fixup with wrapped oneline

The `git commit --fixup` command unwraps wrapped onelines when constructing the commit message, without wrapping the result. We need to make sure that `git rebase --autosquash` keeps handling such cases correctly, in particular since we are about to move the autosquash handling into the

[PATCH v5 08/10] rebase -i: skip unnecessary picks using the rebase--helper

In particular on Windows, where shell scripts are even more expensive than on MacOSX or Linux, it makes sense to move a loop that forks Git at least once for every line in the todo list into a builtin. Note: The original code did not try to skip unnecessary picks of root commits but punts instead

[PATCH v5 07/10] rebase -i: check for missing commits in the rebase--helper

In particular on Windows, where shell scripts are even more expensive than on MacOSX or Linux, it makes sense to move a loop that forks Git at least once for every line in the todo list into a builtin. Signed-off-by: Johannes Schindelin --- builtin/rebase--helper.c

[PATCH v5 04/10] rebase -i: do not invent onelines when expanding/collapsing SHA-1s

To avoid problems with short SHA-1s that become non-unique during the rebase, we rewrite the todo script with short/long SHA-1s before and after letting the user edit the script. Since SHA-1s are not intuitive for humans, rebase -i also provides the onelines (commit message subjects) in the

[PATCH v5 05/10] rebase -i: also expand/collapse the SHA-1s via the rebase--helper

This is crucial to improve performance on Windows, as the speed is now mostly dominated by the SHA-1 transformation (because it spawns a new rev-parse process for *every* line, and spawning processes is pretty slow from Git for Windows' MSYS2 Bash). Signed-off-by: Johannes Schindelin

[PATCH v5 06/10] t3404: relax rebase.missingCommitsCheck tests

These tests were a bit anal about the *exact* warning/error message printed by git rebase. But those messages are intended for the *end user*, therefore it does not make sense to test so rigidly for the *exact* wording. In the following, we will reimplement the missing commits check in the

[PATCH v5 01/10] t3415: verify that an empty instructionFormat is handled as before

An upcoming patch will move the todo list generation into the rebase--helper. An early version of that patch regressed on an empty rebase.instructionFormat value (the shell version could not discern between an empty one and a non-existing one, but the C version used the empty one as if that was

[PATCH v5 03/10] rebase -i: remove useless indentation

The commands used to be indented, and it is nice to look at, but when we transform the SHA-1s, the indentation is removed. So let's do away with it. For the moment, at least: when we will use the upcoming rebase--helper to transform the SHA-1s, we *will* keep the indentation and can reintroduce

[PATCH v5 02/10] rebase -i: generate the script via rebase--helper

The first step of an interactive rebase is to generate the so-called "todo script", to be stored in the state directory as "git-rebase-todo" and to be edited by the user. Originally, we adjusted the output of `git log ` using a simple sed script. Over the course of the years, the code became more

[PATCH v5 00/10] The final building block for a faster rebase -i

This patch series reimplements the expensive pre- and post-processing of the todo script in C. And it concludes the work I did to accelerate rebase -i so far. I am still unwilling to replace a compile-time safe way to pass the options to the revision machinery by the alternative (which I am

Re: Small issue with "add untracked" option of 'git add -i'

On Mon, 2017-06-12 at 10:59 -0700, Junio C Hamano wrote: > Together with your other wishes, perhaps something like this is what > you have in mind.  The original tried to throw in a blank line as a > separator to help interactive users to more easily tell the boundary > of blocks of text, but it

Re: [PATCH 2/3] rebase: Add tests for console output

Hi Phillip, On Wed, 7 Jun 2017, Phillip Wood wrote: > On 01/06/17 13:56, Johannes Schindelin wrote: > > > > On Wed, 31 May 2017, Phillip Wood wrote: > > > >> From: Phillip Wood > >> > >> Check the console output when using --autostash and the stash applies > >>

Re: Minor missing features in worktree compare to new-workdir

On Wed, 2017-06-14 at 08:31 -0400, Yichao Yu wrote: > 1. the branch name in new-workdir has the same behavior as checkout, > i.e. when it matches a remote branch name a local branch tracking that > remote branch will be created and checked out. worktree gives an error > in this case. This is very

Minor missing features in worktree compare to new-workdir

Hi, I've just learnt recently that the new-workdir script has finally got a builtin version, i.e. worktree. I've given it a short try and for the most part it works as good or better than new-workdir. However, there's few minor features that I use in new-workdir that doesn't seem to be supported

[ANNOUNCE] Git Rev News edition 28

Hi everyone, The 28th edition of Git Rev News is now published: https://git.github.io/rev_news/2017/06/14/edition-28/ Thanks a lot to all the contributors and helpers! Enjoy, Christian, Thomas, Jakub and Markus.

[PATCH v4 4/6] t1308: relax the test verifying that empty alias values are disallowed

We are about to change the way aliases are expanded, to use the early config machinery. This machinery reports errors in a slightly different manner than the cached config machinery. Let's not get hung up by the precise wording of the message mentioning the line number. It is really sufficient

[PATCH v4 6/6] Use the early config machinery to expand aliases

Instead of discovering the .git/ directory, reading the config and then trying to painstakingly reset all the global state if we did not find a matching alias, let's use the early config machinery instead. It may look like unnecessary work to discover the .git/ directory in the early config

[PATCH v4 3/6] help: use early config when autocorrecting aliases

Git has this feature which suggests similar commands (including aliases) in case the user specified an unknown command. This feature currently relies on a side effect of the way we expand aliases right now: when a command is not a builtin, we use the regular config machinery (meaning: discovering

[PATCH v4 5/6] t7006: demonstrate a problem with aliases in subdirectories

When expanding aliases, the git_dir is set during the alias expansion (by virtue of running setup_git_directory_gently()). This git_dir may be relative to the current working directory, and indeed often is simply ".git/". When the alias expands to a shell command, we restore the original working

[PATCH v4 2/6] config: report correct line number upon error

When get_value() parses a key/value pair, it is possible that the line number is decreased (because the \n has been consumed already) before the key/value pair is passed to the callback function, to allow for the correct line to be attributed in case of an error. However, when git_parse_source()

[PATCH v4 1/6] discover_git_directory(): avoid setting invalid git_dir

When discovering a .git/ directory, we take pains to ensure that its repository format version matches Git's expectations, and we return NULL otherwise. However, we still appended the invalid path to the strbuf passed as argument. Let's just reset the strbuf to the state before we appended the

[PATCH v4 0/6] Avoid problem where git_dir is set after alias expansion

When expanding an alias in a subdirectory, we setup the git_dir (gently), read the config, and then restore the "env" (e.g. the current working directory) so that the command specified by the alias can run correctly. What we failed to reset was the git_dir, meaning that in the most common case,

Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

On Wed, Jun 14, 2017 at 12:57:06PM +0200, Johannes Schindelin wrote: > Hi Junio, > > On Tue, 13 Jun 2017, Junio C Hamano wrote: > > > * rs/strbuf-addftime-zZ (2017-06-10) 2 commits > > - date: use localtime() for "-local" time formats > > - strbuf: let strbuf_addftime handle %z and %Z itself

Re: [PATCH] configure.ac: loosen FREAD_READS_DIRECTORIES test program

On 2017-06-14 01:30:18, Jeff King wrote: > On Wed, Jun 14, 2017 at 01:15:44AM -0400, Jeff King wrote: > > Actually, I'm not sure if configure.ac is wrong, or the new uses of > > FREAD_READS_DIRECTORIES. Because the test configure.ac actually > > checks: > > Poking around more, I think the best

[PATCH v2 2/2] t: move "git add submodule" into test blocks

Some submodule tests do some setup outside of a test_expect block. This is bad because we won't actually check the outcome of those commands. But it's doubly so because "git add submodule" now produces a warning to stderr, which is not suppressed by the test scripts in non-verbose mode. This

[PATCH v2 1/2] add: warn when adding an embedded repository

It's an easy mistake to add a repository inside another repository, like: git clone $url git add . The resulting entry is a gitlink, but there's no matching .gitmodules entry. Trying to use "submodule init" (or clone with --recursive) doesn't do anything useful. Prior to v2.13, such an entry

rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Hi Junio, On Tue, 13 Jun 2017, Junio C Hamano wrote: > * rs/strbuf-addftime-zZ (2017-06-10) 2 commits > - date: use localtime() for "-local" time formats > - strbuf: let strbuf_addftime handle %z and %Z itself > > As there is no portable way to pass timezone information to > strftime, some

[PATCH v2 0/2] warn when adding an embedded repository

On Wed, Jun 14, 2017 at 02:36:14AM -0400, Jeff King wrote: > > This patch looks good to me, apart from the perceived wording nits. > > Thanks. I'll re-roll with a few tweaks based on your feedback. Here it is. It just changes the wording and fixes the test as you suggested. [1/2]: add: warn

[PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

From: Phillip Wood I've revised the second two tests as Johannes suggested to drop the sed script. The first one is unchanged. Phillip Wood (3): rebase -i: Add test for reflog message rebase: Add regression tests for console output rebase: Add more regression

[PATCH v2 2/3] rebase: Add regression tests for console output

From: Phillip Wood Check the console output when using --autostash and the stash applies cleanly is what we expect. The test is quite strict but should catch any changes to the console output from the various rebase flavors. Thanks-to: Johannes Schindelin

Re: [PATCH v3 6/6] Use the early config machinery to expand aliases

Hi Peff & Brandon, On Wed, 14 Jun 2017, Jeff King wrote: > On Tue, Jun 13, 2017 at 11:26:06AM -0700, Brandon Williams wrote: > > > So because I've been looking at the config machinery lately, I've > > noticed a lot of issues with how things are handled with respect to > > gitdir vs commondir.

[PATCH v2 1/3] rebase -i: Add test for reflog message

From: Phillip Wood Check that the reflog message written to the branch reflog when the rebase is completed is correct Signed-off-by: Phillip Wood --- t/t3404-rebase-interactive.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v2 3/3] rebase: Add more regression tests for console output

From: Phillip Wood Check the console output when using --autostash and the stash does not apply is what we expect. The test is quite strict but should catch any changes to the console output from the various rebase flavors. Thanks-to: Johannes Schindelin

Re: [PATCH v2] Configure Git contribution guidelines for github.com

> On 14 Jun 2017, at 12:01, Junio C Hamano wrote: > > Lars Schneider writes: > >>> On 13 Jun 2017, at 11:04, Jeff King wrote: >>> >>> On Tue, Jun 13, 2017 at 10:18:07AM +0200, Lars Schneider wrote: >>> changes since v1:

Re: [PATCH v3 6/6] Use the early config machinery to expand aliases

Hi Peff, On Wed, 14 Jun 2017, Jeff King wrote: > On Tue, Jun 13, 2017 at 09:21:30AM -0700, Junio C Hamano wrote: > > > > alias.c | 31 --- > > > git.c| 55 > > > --- > > > t/t7006-pager.sh |

Re: [PATCH v3 6/6] Use the early config machinery to expand aliases

Hi Junio, On Tue, 13 Jun 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Instead of discovering the .git/ directory, read the config and then > > trying to painstakingly reset all the global state if we did not find a > > matching alias, let's use

Re: [PATCH 2/3] rebase: Add tests for console output

On 09/06/17 17:39, Junio C Hamano wrote: > Phillip Wood writes: > >> I'm confused by this as my script does not use the escape sequence "\r" >> out of portability concerns. It has a literal carriage return as you get >> from typing Ctrl-Q Ctrl-M in emacs or Ctrl-V

Re: [PATCH 0/2] Fix a refname trimming problem in `log --bisect`

Michael Haggerty writes: > The code for `git log --bisect` was calling > `for_each_ref_in_submodule()` with prefix set to "refs/bisect/bad", > which is the actual name of the reference that it wants. This resulted > in the refname being trimmed completely away and the empty

Re: [PATCH 1/2] for_each_bisect_ref(): don't trim refnames

Jeff King writes: >> Since we obviously don't have even a single test for "--bisect", that >> might be worth adding. > > It turns out we do, but none that actually check that we use the default > refnames. So maybe squash this in? Sounds sensible. Thanks. > > diff --git

Re: [PATCH v2 7/8] alias_lookup(): optionally return top-level directory

Hi Junio, On Tue, 13 Jun 2017, Junio C Hamano wrote: > Jeff King writes: > > > On Tue, Jun 13, 2017 at 01:42:02PM +0200, Johannes Schindelin wrote: > > > >> > As you probably guessed, I had tried that first and then figured that if > >> > I needed to keep the

Re: [PATCH v2] Configure Git contribution guidelines for github.com

Lars Schneider writes: >> On 13 Jun 2017, at 11:04, Jeff King wrote: >> >> On Tue, Jun 13, 2017 at 10:18:07AM +0200, Lars Schneider wrote: >> >>> changes since v1: >>> * mention submitGit >>> * link to mailing list address instead of mailing list

Re: [PATCH 8/8] t0012: test "-h" with builtins

On Tue, Jun 13, 2017 at 04:08:03PM -0700, Jonathan Nieder wrote: > > +test_expect_success 'generate builtin list' ' > > + git --list-builtins >builtins > > +' > > + > > +while read builtin > > +do > > + test_expect_success "$builtin can handle -h" ' > > + test_expect_code 129 git

Re: What's cooking in git.git (Jun 2017, #03; Mon, 5)

Stefan Beller writes: > The color experts agreed that (3) might be the best solution > as this gives most flexibility: > > "I would be happy as I can configure the bounds highlighting > to not exist, it would degenerate to a pure Zebra, which is > very simple to

Re: [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch

On Tue, Jun 13, 2017 at 05:48:16PM -0700, Jonathan Nieder wrote: > > The reason for this is that the initial fetch is not a fully fledged > > 'git fetch' but a bunch of direct calls into the fetch/transport > > machinery with clone's own refs-to-refspec matching logic, which > > bypasses parts of

[PATCH] doc: git-reset: clarify the --keep usage example

The example doesn't work as provided (you get an error) when the 'edit' and 'commit' steps affect the same files. Add a note and reference the DISCUSSION to that effect. Signed-off-by: Štěpán Němec --- Documentation/git-reset.txt | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH] doc: git-reset: fix a trivial typo

Signed-off-by: Štěpán Němec --- Documentation/git-reset.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 8a21198..70f3753 100644 --- a/Documentation/git-reset.txt +++

[PATCH] git-svn: document special options for commit-diff

Some options specific for `git svn commit-diff` where not documented so far. Signed-off-by: Andreas Heiduk --- Documentation/git-svn.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index

Re: [PATCH 1/2] for_each_bisect_ref(): don't trim refnames

On Wed, Jun 14, 2017 at 05:22:56AM -0400, Jeff King wrote: > > refs.c | 12 > > refs.h | 5 - > > revision.c | 2 +- > > 3 files changed, 17 insertions(+), 2 deletions(-) > > The change itself looks fine to me. > > Since we obviously don't have even a single test for

Re: [PATCH 1/2] for_each_bisect_ref(): don't trim refnames

On Wed, Jun 14, 2017 at 11:07:26AM +0200, Michael Haggerty wrote: > `for_each_bisect_ref()` is called by `for_each_bad_bisect_ref()` with > a term "bad". This used to make it call `for_each_ref_in_submodule()` > with a prefix "refs/bisect/bad". But the latter is the name of the > reference that

Re: [PATCH 0/2] Fix a refname trimming problem in `log --bisect`

On Wed, Jun 14, 2017 at 11:07:25AM +0200, Michael Haggerty wrote: > Fix the problem in two orthogonal ways: > > 1. Add a new function, `for_each_fullref_in_submodule()`, that doesn't >trim the refnames that it passes to callbacks, and us that instead. >I *think* that this is a strict

Re: [BUG] b9c8e7f2fb6e breaks git bisect visualize

On Wed, Jun 14, 2017 at 10:36:43AM +0200, Michael Haggerty wrote: > The code for `git log --bisect` is questionable. It calls > `for_each_ref_in_submodule()` with prefix "refs/bisect/bad", which is > the actual name (not a prefix) of the reference that it is interested > in. So the callback is

[PATCH 1/2] for_each_bisect_ref(): don't trim refnames

`for_each_bisect_ref()` is called by `for_each_bad_bisect_ref()` with a term "bad". This used to make it call `for_each_ref_in_submodule()` with a prefix "refs/bisect/bad". But the latter is the name of the reference that is being sought, so the empty string was being passed to the callback as the

[PATCH 0/2] Fix a refname trimming problem in `log --bisect`

The code for `git log --bisect` was calling `for_each_ref_in_submodule()` with prefix set to "refs/bisect/bad", which is the actual name of the reference that it wants. This resulted in the refname being trimmed completely away and the empty string being passed to the callback. That became

[PATCH 2/2] prefix_ref_iterator_advance(): relax the check of trim length

Before the previous commit, `for_each_bad_bisect_ref()` called `for_each_fullref_in_submodule()` in such a way as to trim the whole refname away. This is a questionable use of the API, but is not ipso facto dangerous, so tolerate it in case there are other callers relying on this behavior. But

Re: [BUG] b9c8e7f2fb6e breaks git bisect visualize

On 06/14/2017 02:06 AM, Øyvind A. Holm wrote: > Commit b9c8e7f2fb6e ("prefix_ref_iterator: don't trim too much") breaks > git bisect visualize, this reproduces the bug: > > $ git bisect start > $ git bisect bad > $ git bisect good HEAD^^ > $ git bisect visualize > fatal: BUG: attempt

Re: [PATCH 3/3] branch: add a --copy (-c) option to go with --move (-m)

On Tue, Jun 13, 2017 at 7:30 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Sahil Dua writes: >> >>> Add the ability to --copy a branch and its reflog and configuration, >>> this uses the same underlying machinery as the

Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

> On 13 Jun 2017, at 23:40, Junio C Hamano wrote: > > > * ls/github (2017-06-13) 1 commit > - Configure Git contribution guidelines for github.com > > Help contributors that visit us at GitHub. > > Will merge to 'next'. I just pushed v3. If possible, please use it for

Re: [PATCH v3] Configure Git contribution guidelines for github.com

On Wed, Jun 14, 2017 at 09:35:36AM +0200, Lars Schneider wrote: > changes since v2: > * removed mailing list address, added link with mailing list explanations > * fixed grammar nits Thanks, this one looks good to me. -Peff

[PATCH v3] Configure Git contribution guidelines for github.com

Many open source projects use github.com for their contribution process. Although we mirror the Git core repository to github.com [1] we do not use any other github.com service. This is unknown/unexpected to a number of (potential) contributors and consequently they create Pull Requests against

Re: [PATCH v2] Configure Git contribution guidelines for github.com

> On 13 Jun 2017, at 11:04, Jeff King wrote: > > On Tue, Jun 13, 2017 at 10:18:07AM +0200, Lars Schneider wrote: > >> changes since v1: >> * mention submitGit >> * link to mailing list address instead of mailing list archive > > You might want to link to

[PATCH v4] doc: do not use `rm .git/index` when normalizing line endings

When illustrating how to normalize the line endings, the documentation in gitattributes tells the user to `rm .git/index`. This is incorrect for two reasons: - Users shouldn't be instructed to mess around with the internal implementation of Git using raw file system tools like `rm`. -

Re: [PATCH 1/2] add: warn when adding an embedded repository

On Tue, Jun 13, 2017 at 10:16:15AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I also waffled on whether we should ask the submodule code > > whether it knows about a particular path. Technically: > > > > git config submodule.foo.path foo > > git config

Re: [PATCH 1/2] add: warn when adding an embedded repository

On Tue, Jun 13, 2017 at 10:07:43AM -0700, Stefan Beller wrote: > > I also waffled on whether we should ask the submodule code > > whether it knows about a particular path. Technically: > > > > git config submodule.foo.path foo > > git config submodule.foo.url git://... > > git add foo > > >

  1   2   >