Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 29.03.2016 um 21:18 schrieb Johannes Sixt: Am 28.03.2016 um 17:14 schrieb Johannes Schindelin: The problem with your patch is that it does not account for backslashes in paths resulting in quoting. I am afraid that your patch will most likely *not* let the tests pass in Git for Windows SDK,

Re: [BUG?] retrying with "am -3" doesn't work anymore

On Wed, Mar 30, 2016 at 12:18:30PM +0800, Paul Tan wrote: > On Wed, Mar 30, 2016 at 10:15 AM, Jeff King wrote: > > I noticed that I could not get a patch from Junio to apply earlier > > today, and I think it is a regression in the builtin git-am > > implementation. I had trouble

Re: [ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase

On Tue, Mar 29, 2016 at 09:29:45PM -0400, Trevor Saunders wrote: > hm how? the workflow you use locally has basically nothingto do with how > pushes work. I work on several projects daily where everyone pushes to > trunk, but locally I use branches. You just need to fetch rebase then > either

Re: weird diff output?

On Tue, Mar 29, 2016 at 04:05:57PM -0700, Jacob Keller wrote: > > This is what we want in both cases. > > And I would argue it would appease many other kinds of text as well, because > > an empty line is usually a strong indicator for any text that a > > different thing comes along. > > (Other

Re: [BUG?] retrying with "am -3" doesn't work anymore

Hi Jeff, On Wed, Mar 30, 2016 at 10:15 AM, Jeff King wrote: > I noticed that I could not get a patch from Junio to apply earlier > today, and I think it is a regression in the builtin git-am > implementation. I had trouble reproducing with a basic test case, > though. > >

git alias quoting help

I've also tried to make this a plain bash script (w/o the function or if statements and am failing at the same place). The issue seems to be with the quoting in the filter-branch | ls-files bit. Also, the end goal here is to be able to move a directory from one repo and keep the history. While

Message.

My Name is Thomas Marr and currently work as a Branch Operations Manager at Lichfield Finance Trust Bank, I wish to propose/discuss a profitable business opportunity to the tune of £5,732,000.00GBP with you, do indicate your willingness to partner with me for more information. Regards, Thomas

Re: [PATCH v5] worktree: add: introduce --checkout option

Thanks for the review. Sorry for the patch churn, I wasn't quite familiar with working with mailing list. 2016-03-30 3:20 GMT+08:00 Eric Sunshine : > On Tue, Mar 29, 2016 at 6:11 AM, Ray Zhang wrote: >> By adding this option which defaults to true,

Cheap Solid Wood Beds For Sale Salford UK

Cheap Solid Wood Beds For Sale Salford UK. Find Solid Wood Bed suppliers at wewewe [dot] s o l i d w o o d b e d s [dot] c o [dot] u k -- View this message in context: http://git.661346.n2.nabble.com/Cheap-Solid-Wood-Beds-For-Sale-Salford-UK-tp7651989.html Sent from the git mailing list

[BUG?] retrying with "am -3" doesn't work anymore

I noticed that I could not get a patch from Junio to apply earlier today, and I think it is a regression in the builtin git-am implementation. I had trouble reproducing with a basic test case, though. Basically, I picked up the three patches from this sub-thread:

Re: [PATCH v4 2/3] pretty: enable --expand-tabs by default for selected pretty formats

On Tue, Mar 29, 2016 at 04:15:08PM -0700, Junio C Hamano wrote: > diff --git a/Documentation/pretty-options.txt > b/Documentation/pretty-options.txt > index 4fb5c76..23967b6 100644 > --- a/Documentation/pretty-options.txt > +++ b/Documentation/pretty-options.txt > @@ -43,10 +43,16 @@ people

Re: [ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase

On Mon, Mar 28, 2016 at 11:08:41AM +0300, Max Kirillov wrote: > Hello. > > I would like to announce git-push-update, a tool which emulates > server-side merge or rebase. > > The link: https://github.com/max630/git-push-update > > It is a bash script which fetches latest remote branch, creates >

Re: [PATCH 4/6] abbrev_sha1_in_line: don't leak memory

On Tue, Mar 29, 2016 at 09:30:38PM -0400, Eric Sunshine wrote: > On Tue, Mar 29, 2016 at 9:11 PM, Jeff King wrote: > > On Tue, Mar 29, 2016 at 05:38:51PM -0700, Stefan Beller wrote: > >> `split` is of type `struct strbuf **` and just before the new free, > >> we release the inner

Re: [PATCH 4/6] abbrev_sha1_in_line: don't leak memory

On Tue, Mar 29, 2016 at 9:11 PM, Jeff King wrote: > On Tue, Mar 29, 2016 at 05:38:51PM -0700, Stefan Beller wrote: >> `split` is of type `struct strbuf **` and just before the new free, >> we release the inner strbufs. Make sure to also release the memory >> containing the pointers

[PATCHv4 5/6] submodule update: test recursive path reporting from subdirectory

This patch is just a test and fixes no bug as there is currently no bug in the path handling of `submodule update`. In `submodule update` we make a call to `submodule--helper list --prefix "$wt_prefix"` which looks a bit brittle and likely to introduce a bug for the path handling. It is not a bug

[PATCHv4 6/6] t7407: make expectation as clear as possible

Not everyone (including me) grasps the sed expression in a split second as they would grasp the 4 lines printed as is. Signed-off-by: Stefan Beller --- t/t7407-submodule-foreach.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCHv4 3/6] submodule status: correct path handling in recursive submodules

The new test which is a replica of the previous test except that it executes from a sub directory. Prior to this patch the test failed by having too many '../' prefixed: --- expect2016-03-29 19:02:33.087336115 + +++ actual2016-03-29 19:02:33.359343311 + @@ -1,7 +1,7 @@

[PATCHv4 2/6] submodule update --init: correct path handling in recursive submodules

When calling `git submodule init` from a recursive instance of `git submodule update --recursive`, the reported path is wrong as it skips the nested submodules. The new test demonstrates a failure in the code prior to this patch. Instead of getting the expected Submodule 'submodule'

[PATCHv4 4/6] submodule update: align reporting path for custom command execution

In the predefined actions (merge, rebase, none, checkout), we use the display path, which is relative to the current working directory. Also use the display path when running a custom command. Signed-off-by: Stefan Beller --- git-submodule.sh| 4 ++--

[PATCHv4 1/6] submodule foreach: correct path display in recursive submodules

The `prefix` was put in front of the display path unconditionally. This is wrong as any relative path computation would need to be at the front, so include the prefix into the display path. The new test replicates the previous test with the difference of executing from a sub directory. By

[PATCHv4 0/6] Fix path bugs in submodule commands executed from sub dir

v4: * addressed Junios comments in patch 1&2, which is: 1) * reworded commit message * when writing the commit message I discovered a new way to fix the bug (fix the computation of the displaypath instead of its parameters wt_prefix and prefix.) The result is the

Re: [PATCH 6/6] credential-cache, send_request: close fd when done

On Tue, Mar 29, 2016 at 05:38:53PM -0700, Stefan Beller wrote: > No need to keep it open any further. > > Signed-off-by: Stefan Beller > --- > credential-cache.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/credential-cache.c b/credential-cache.c > index

Re: [PATCH 5/6] bundle: don't leak an fd in case of early return

On Tue, Mar 29, 2016 at 05:38:52PM -0700, Stefan Beller wrote: > In successful operation `write_pack_data` will close the `bundle_fd`, > but when we exit early, we need to take care of the file descriptor > ourselves. > > Signed-off-by: Stefan Beller > --- > bundle.c | 10

Re: [PATCH 3/6] notes: don't leak memory in git_config_get_notes_strategy

On Tue, Mar 29, 2016 at 05:38:50PM -0700, Stefan Beller wrote: > `value` is just a temporary scratchpad, so we need to make sure it doesn't > leak. It is xstrdup'd in `git_config_get_string_const` and > `parse_notes_merge_strategy` just compares the string against predefined > values, so no need

Re: [PATCH 3/6] notes: don't leak memory in git_config_get_notes_strategy

On Tue, Mar 29, 2016 at 8:38 PM, Stefan Beller wrote: > `value` is just a temporary scratchpad, so we need to make sure it doesn't > leak. It is xstrdup'd in `git_config_get_string_const` and > `parse_notes_merge_strategy` just compares the string against predefined > values,

Re: [PATCH 4/6] abbrev_sha1_in_line: don't leak memory

On Tue, Mar 29, 2016 at 05:38:51PM -0700, Stefan Beller wrote: > `split` is of type `struct strbuf **` and just before the new free, > we release the inner strbufs. Make sure to also release the memory > containing the pointers to the individual strbufs. > > Signed-off-by: Stefan Beller

Re: [PATCH 2/6] imap-send.c, cram: allocate enough memory for null terminated string

On Tue, Mar 29, 2016 at 05:38:49PM -0700, Stefan Beller wrote: > `strlen` returns the length of a string without the terminating null byte. > To make sure enough memory is allocated we need to pass `strlen(..) + 1` > to the allocation function. > > Signed-off-by: Stefan Beller

Re: git-apply does not work in a sub-directory of a Git repository

On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano wrote: The include/exclude mechanism does use wildmatch() but does not use the

Re: [PATCH 2/6] imap-send.c, cram: allocate enough memory for null terminated string

On Tue, Mar 29, 2016 at 8:38 PM, Stefan Beller wrote: > `strlen` returns the length of a string without the terminating null byte. > To make sure enough memory is allocated we need to pass `strlen(..) + 1` > to the allocation function. > > Signed-off-by: Stefan Beller

Re: [PATCH 2/6] submodule update --init: correct path handling in recursive submodules

On Tue, Mar 29, 2016 at 4:54 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> The new test demonstrates a failure in the code prior to this patch. >> Instead of getting the expected >> Submodule 'submodule' (${pwd}/submodule) registered for path

Re: [PATCH 1/6] path.c: allocate enough memory for string

Stefan Beller writes: > `strlen` returns the length of a string without the terminating null byte. > To make sure enough memory is allocated we need to pass `strlen(..) + 1` > to the allocation function. > > Signed-off-by: Stefan Beller > --- > path.c |

Re: [PATCH 1/6] path.c: allocate enough memory for string

On Tue, Mar 29, 2016 at 8:38 PM, Stefan Beller wrote: > `strlen` returns the length of a string without the terminating null byte. > To make sure enough memory is allocated we need to pass `strlen(..) + 1` > to the allocation function. > > Signed-off-by: Stefan Beller

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Wed, Mar 30, 2016 at 3:34 AM, Jeff King wrote: > On Tue, Mar 29, 2016 at 06:42:44AM -0500, Elliott Cable wrote: > >> So, I find this behaviour a little strange; I can't determine if it's >> a subtle bug, or intentionally undefined/‘fuzzy’ behaviour: >> >> $ cd a-repo/.git/

[PATCH 6/6] credential-cache, send_request: close fd when done

No need to keep it open any further. Signed-off-by: Stefan Beller --- credential-cache.c | 1 + 1 file changed, 1 insertion(+) diff --git a/credential-cache.c b/credential-cache.c index f4afdc6..86e21de 100644 --- a/credential-cache.c +++ b/credential-cache.c @@ -32,6 +32,7

[PATCH 4/6] abbrev_sha1_in_line: don't leak memory

`split` is of type `struct strbuf **` and just before the new free, we release the inner strbufs. Make sure to also release the memory containing the pointers to the individual strbufs. Signed-off-by: Stefan Beller --- wt-status.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 5/6] bundle: don't leak an fd in case of early return

In successful operation `write_pack_data` will close the `bundle_fd`, but when we exit early, we need to take care of the file descriptor ourselves. Signed-off-by: Stefan Beller --- bundle.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git

[PATCH 3/6] notes: don't leak memory in git_config_get_notes_strategy

`value` is just a temporary scratchpad, so we need to make sure it doesn't leak. It is xstrdup'd in `git_config_get_string_const` and `parse_notes_merge_strategy` just compares the string against predefined values, so no need to keep it around longer. Signed-off-by: Stefan Beller

[PATCH 1/6] path.c: allocate enough memory for string

`strlen` returns the length of a string without the terminating null byte. To make sure enough memory is allocated we need to pass `strlen(..) + 1` to the allocation function. Signed-off-by: Stefan Beller --- path.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 2/6] imap-send.c, cram: allocate enough memory for null terminated string

`strlen` returns the length of a string without the terminating null byte. To make sure enough memory is allocated we need to pass `strlen(..) + 1` to the allocation function. Signed-off-by: Stefan Beller --- imap-send.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/6] Some cleanups

One of my first patches to Git were cleanup patches, and I fell back to my old pattern here, while thinking on how to write better commit messages for the submodule bugfixes I currently have in flight. Just some one liners to not leak memory or file descriptors. They are bundled as a series, but

Re: [PATCH v4 1/3] pretty: expand tabs in indented logs to make things line up properly

On Tue, Mar 29, 2016 at 7:15 PM, Junio C Hamano wrote: > From: Linus Torvalds > > A commit log message sometimes tries to line things up using tabs, > assuming fixed-width font with the standard 8-place tab settings. > Viewing such a commit

Re: weird diff output?

Jacob Keller writes: > On Tue, Mar 29, 2016 at 11:16 AM, Stefan Beller wrote: >> ... >> To find a heuristic, which appeals both the C code >> and the shell code, we could take the empty line >> as a strong hint for the divider: > > This seems like a

Re: [PATCH 4/6] submodule update: align reporting path for custom command execution

Stefan Beller writes: > In the predefined actions (merge, rebase, none, checkout), we use > the display path, which is relative to the current working directory. > Also use the display path when running a custom command. Very sensible. > Signed-off-by: Stefan Beller

Re: [PATCH 3/6] submodule status: correct path handling in recursive submodules

Stefan Beller writes: > The new test which is a replica of the previous test except > that it executes from a sub directory. Prior to this patch > the test failed by having too many '../' prefixed: > > --- expect 2016-03-29 19:02:33.087336115 + > +++ actual

Re: [PATCH 2/6] submodule update --init: correct path handling in recursive submodules

Stefan Beller writes: > The new test demonstrates a failure in the code prior to this patch. > Instead of getting the expected > Submodule 'submodule' (${pwd}/submodule) registered for path > '../super/submodule' > the `super` directory is omitted and you get >

Re: [PATCH 1/6] submodule foreach: correct path display in recursive submodules

Stefan Beller writes: > The new test replicates the previous test with the difference of executing > from a sub directory. By executing from a sub directory all we would > expect all displayed paths to be prefixed by '../'. -ECANTPARSE on the last sentence. Remove the first

Re: [GSoC] A late proposal: a modern send-email

On Tue, Mar 29, 2016 at 6:17 AM, 惠轶群 wrote: > 2016-03-29 0:49 GMT+08:00 Ævar Arnfjörð Bjarmason : >> On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 wrote: >>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano : 惠轶群

[PATCH v4 3/3] pretty: allow tweaking tabwidth in --expand-tabs

When the local convention of the project is to use tab width that is not 8, it may make sense to allow "git log --expand-tabs=" to tweak the output to match it. Signed-off-by: Junio C Hamano --- Documentation/pretty-options.txt | 10 ++ commit.h

[PATCH v4 0/3] Expanding tabs in "git log" output

So here is the fourth try. Previous round are at $gmane/289694, $gmane/289166, and $gmane/288987. I didn't quite find a good order to build this progressively, so this series: - First adds the internal machinery and explicit --expand-tabs. This keeps Linus's authorship, but is different in

[PATCH v4 2/3] pretty: enable --expand-tabs by default for selected pretty formats

"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats. Add --no-expand-tabs option to override the new default. The change alone breaks a test in t4201 that runs

[PATCH v4 1/3] pretty: expand tabs in indented logs to make things line up properly

From: Linus Torvalds A commit log message sometimes tries to line things up using tabs, assuming fixed-width font with the standard 8-place tab settings. Viewing such a commit however does not work well in "git log", as we indent the lines by prefixing 4 spaces in

Re: weird diff output?

On Tue, Mar 29, 2016 at 11:16 AM, Stefan Beller wrote: > On Tue, Mar 29, 2016 at 10:54 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> I thought this is an optimization for C code where you have a diff like: >>> >>> int

[PATCH 5/6] submodule update: test recursive path reporting from subdirectory

This patch is just a test and fixes no bug as there is currently no bug in the path handling of `submodule update`. In `submodule update` we make a call to `submodule--helper list --prefix "$wt_prefix"` which looks a bit brittle and likely to introduce a bug for the path handling. It is not a bug

[PATCH 6/6] t7407: make expectation as clear as possible

Not everyone (including me) grasps the sed expression in a split second as they would grasp the 4 lines printed as is. Signed-off-by: Stefan Beller --- t/t7407-submodule-foreach.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH 4/6] submodule update: align reporting path for custom command execution

In the predefined actions (merge, rebase, none, checkout), we use the display path, which is relative to the current working directory. Also use the display path when running a custom command. Signed-off-by: Stefan Beller --- git-submodule.sh| 4 ++--

[PATCH 3/6] submodule status: correct path handling in recursive submodules

The new test which is a replica of the previous test except that it executes from a sub directory. Prior to this patch the test failed by having too many '../' prefixed: --- expect2016-03-29 19:02:33.087336115 + +++ actual2016-03-29 19:02:33.359343311 + @@ -1,7 +1,7 @@

[PATCH 2/6] submodule update --init: correct path handling in recursive submodules

The new test demonstrates a failure in the code prior to this patch. Instead of getting the expected Submodule 'submodule' (${pwd}/submodule) registered for path '../super/submodule' the `super` directory is omitted and you get Submodule 'submodule' (${pwd}/submodule) registered for path

[PATCH 1/6] submodule foreach: correct path display in recursive submodules

The new test replicates the previous test with the difference of executing from a sub directory. By executing from a sub directory all we would expect all displayed paths to be prefixed by '../'. Prior to this patch the test would report Entering 'nested1/nested2/../nested3' instead of the

[PATCHv3 0/6] Fix path bugs in submodule commands executed from sub dir

v3: Resending without `test_pause` in the last test. v2: The first 3 commits are * Test and bugfix in one commit each * better explained than before The expansion of an expected test result moved to the back of the series. There are two new commits * one being another bugfix of the display path

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

Jeff King writes: > $ echo content >../file > $ GIT_WORK_TREE=$(cd ..; pwd) GIT_DIR=$(pwd) git add file > fatal: pathspec 'file' did not match any files > > I'd expect that to work, and it doesn't, because we pass ".git/" as the > "prefix" to cmd_add(). Which I guess is

Re: [PATCHv2 0/6] Fix path bugs in submodule commands executed from sub dir

Please ignore this series; it was sent out prematurely. :( -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] submodule update: test recursive path reporting from subdirectory

This patch is just a test and fixes no bug as there is currently no bug in the path handling of `submodule update`. In `submodule update` we make a call to `submodule--helper list --prefix "$wt_prefix"` which looks a bit brittle and likely to introduce a bug for the path handling. It is not a bug

[PATCH 3/6] submodule status: correct path handling in recursive submodules

The new test which is a replica of the previous test except that it executes from a sub directory. Prior to this patch the test failed by having too many '../' prefixed: --- expect2016-03-29 19:02:33.087336115 + +++ actual2016-03-29 19:02:33.359343311 + @@ -1,7 +1,7 @@

[PATCH 5/6] submodule update: align reporting path for custom command execution

In the predefined actions (merge, rebase, none, checkout), we use the display path, which is relative to the current working directory. Also use the display path when running a custom command. Signed-off-by: Stefan Beller --- git-submodule.sh| 4 ++--

[PATCH 4/6] t7407: make expectation as clear as possible

Not everyone (including me) grasps the sed expression in a split second as they would grasp the 4 lines printed as is. Signed-off-by: Stefan Beller --- t/t7407-submodule-foreach.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH 1/6] submodule foreach: correct path display in recursive submodules

The new test replicates the previous test with the difference of executing from a sub directory. By executing from a sub directory all we would expect all displayed paths to be prefixed by '../'. Prior to this patch the test would report Entering 'nested1/nested2/../nested3' instead of the

[PATCHv2 0/6] Fix path bugs in submodule commands executed from sub dir

The first 3 commits are * Test and bugfix in one commit each * better explained than before The expansion of an expected test result moved to the back of the series. There are two new commits * one being another bugfix of the display path for `submodule update` * another test for `submodule

[PATCH 2/6] submodule update --init: correct path handling in recursive submodules

The new test demonstrates a failure in the code prior to this patch. Instead of getting the expected Submodule 'submodule' (${pwd}/submodule) registered for path '../super/submodule' the `super` directory is omitted and you get Submodule 'submodule' (${pwd}/submodule) registered for path

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 11:00:03PM +0100, John Keeping wrote: > > We seem to get that wrong. I'm also not sure if it would make sense if > > you explicitly set the two to be equal, like: > > > > # checking in your own refs? > > GIT_WORK_TREE=$(pwd) GIT_DIR=$(pwd) git add refs packed-refs > >

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 11:00:03PM +0100, John Keeping wrote: > On Tue, Mar 29, 2016 at 05:21:43PM -0400, Jeff King wrote: > > On Tue, Mar 29, 2016 at 09:52:08PM +0100, John Keeping wrote: > > > > > > Yeah, I think this is a bug. Presumably what is happening is that we are > > > > too eager to

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 05:21:43PM -0400, Jeff King wrote: > On Tue, Mar 29, 2016 at 09:52:08PM +0100, John Keeping wrote: > > > > Yeah, I think this is a bug. Presumably what is happening is that we are > > > too eager to "cd $GIT_WORK_TREE" inside git-rev-parse, and by the time > > > we ask

Re: [PATCH v2 03/17] index-helper: new daemon for caching index and related stuff

On Tue, 2016-03-29 at 09:31 +0700, Duy Nguyen wrote: > On Sat, Mar 19, 2016 at 8:04 AM, David Turner < > dtur...@twopensource.com> wrote: > > From: Nguyễn Thái Ngọc Duy > > > > Instead of reading the index from disk and worrying about disk > > corruption, the index is cached

Re: [PATCH 00/19] index-helper, watchman

On Tue, 2016-03-29 at 19:09 +0200, Torsten Bögershausen wrote: > On 2016-03-09 19.36, David Turner wrote: > > This is a rebase and extension of Duy's work on git index-helper > > and > > watchman support. > > > Somewhere we need to tweak something: > t7900 do all fail under Mac OS, because the

Re: [PATCH v2 08/17] read-cache: invalidate untracked cache data when reading WAMA

On Tue, 2016-03-29 at 09:50 +0700, Duy Nguyen wrote: > On Sat, Mar 19, 2016 at 8:04 AM, David Turner < > dtur...@twopensource.com> wrote: > > @@ -1407,10 +1472,24 @@ static int read_watchman_ext(struct > > index_state *istate, const void *data, > > ewah_each_bit(bitmap, mark_no_watchman,

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 09:52:08PM +0100, John Keeping wrote: > > Yeah, I think this is a bug. Presumably what is happening is that we are > > too eager to "cd $GIT_WORK_TREE" inside git-rev-parse, and by the time > > we ask "are we in a work tree", the answer has become yes. But the > > caller

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

On Tue, Mar 29, 2016 at 9:30 AM, Mehul Jain wrote: > "--[no-]autostash" option for git-pull is only valid in rebase mode. > That is, either --rebase is used or pull.rebase=true. Existing tests > already check the cases when --rebase is used but fails to check for >

Re: [PATCH 4/5] t/t5520: modify tests to reduce common code

On Tue, Mar 29, 2016 at 9:29 AM, Mehul Jain wrote: > t/t5520: modify tests to reduce common code As this is indeed a patch, "modify" is implied. Perhaps: t5520: factor out common code > There exist three groups of tests which have repetitive lines of code. > >

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 04:34:25PM -0400, Jeff King wrote: > On Tue, Mar 29, 2016 at 06:42:44AM -0500, Elliott Cable wrote: > > > So, I find this behaviour a little strange; I can't determine if it's > > a subtle bug, or intentionally undefined/‘fuzzy’ behaviour: > > > > $ cd a-repo/.git/ >

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

Junio C Hamano writes: > Junio C Hamano writes: > >> Torsten Bögershausen writes: >> >>> If we had made the CRLF -> LF conversion, yes. But we don't do that. >>> crlf_to_git() returns without touching the line endings. >> >> That sounds

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 06:42:44AM -0500, Elliott Cable wrote: > So, I find this behaviour a little strange; I can't determine if it's > a subtle bug, or intentionally undefined/‘fuzzy’ behaviour: > > $ cd a-repo/.git/ > $ pwd > /path/to/a-repo/.git > $ git rev-parse

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

Junio C Hamano writes: > Torsten Bögershausen writes: > >> If we had made the CRLF -> LF conversion, yes. But we don't do that. >> crlf_to_git() returns without touching the line endings. > > That sounds quite broken. How would a user ever fix broken data in >

Re: [PATCH 3/5] t/t5520: use test_i18ngrep instead of test_cmp

On Tue, Mar 29, 2016 at 9:29 AM, Mehul Jain wrote: > t/t5520: use test_i18ngrep instead of test_cmp As mentioned for earlier patches, this is too low-level, whereas it should be giving a high-level overview. > test_cmp is used for error checking when test_i18ngrep

Re: [PATCH v5] worktree: add: introduce --checkout option

John Keeping writes: > Having gone looking, I can't find a reference but I for some reason I > was convinced the separate version was preferred in the option > descriptions. The one that is similar that came back to my mind while reading your response was that we used to

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 12:56:41PM -0700, Junio C Hamano wrote: > >> So it is a misconfiguration if you only set GIT_WORK_TREE without > >> setting GIT_DIR. > > > > Hmm. I have frequently done this when my cwd is a git repository (e.g., > > a bare one), and it works as you'd expect (find the

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

Torsten Bögershausen writes: > If we had made the CRLF -> LF conversion, yes. But we don't do that. > crlf_to_git() returns without touching the line endings. That sounds quite broken. How would a user ever fix broken data in the index then? I know the commit that often appears

Re: [PATCH v5] worktree: add: introduce --checkout option

On Tue, Mar 29, 2016 at 02:04:38PM -0400, Eric Sunshine wrote: > On Tue, Mar 29, 2016 at 6:54 AM, John Keeping wrote: > > On Tue, Mar 29, 2016 at 10:11:01AM +, Ray Zhang wrote: > >> With `add`, detach HEAD in the new working tree. See "DETACHED HEAD" > >> in

Re: [PATCH 2/5] t/t5520: explicitly unset rebase.autostash

On Tue, Mar 29, 2016 at 9:29 AM, Mehul Jain wrote: > t/t5520: explicitly unset rebase.autostash As with patch 1/5, this subject is written at too low a level, talking about details of the patch rather than giving a high-level overview. What the patch is really doing is

Re: [PATCH 4/5] t/t5520: modify tests to reduce common code

Mehul Jain writes: > There exist three groups of tests which have repetitive lines of code. > > Introduce two functions test_rebase_autostash() and > test_rebase_no_autostash() to reduce the number of lines. Also introduce > loops to futher reduce the current

Re: [PATCH] Fix http-backend reading till EOF, ignoring CONTENT_LENGTH, violating rfc3875 -- WAS: Problem with git-http-backend.exe as iis cgi

On Tue, Mar 29, 2016 at 10:38:23AM +, Florian Manschwetus wrote: > > | A request-body is supplied with the request if the CONTENT_LENGTH is > > | not NULL. The server MUST make at least that many bytes available > > | for the script to read. The server MAY signal an end-of-file > > |

Re: [PATCH 00/21] replacement for dt/refs-backend-lmdb v7 patch 04/33

On Sun, 2016-03-27 at 07:22 +0200, Michael Haggerty wrote: > On 03/24/2016 07:47 AM, David Turner wrote: > > [...] > > I incorporated your changes into the lmdb backend. To make merging > > later more convenient, I rebased on top of pu -- I think this > > mainly > > depends on

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Johannes Sixt writes: > This part of your 45bf3297 (t1300: fix the new --show-origin tests on > Windows) > > @@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing > per > "die q(badrename) if ((stat(q(.git/config)))[2] & 0) != 0600" > ' > >

Re: [PATCH 1/5] t/t5520: change rebase.autoStash to rebase.autostash

On Tue, Mar 29, 2016 at 9:29 AM, Mehul Jain wrote: > t/t5520: change rebase.autoStash to rebase.autostash This subject is written at too low a level, talking about details of the patch rather than giving a high-level overview. A further shortcoming is that there's no

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

Torsten Bögershausen writes: > # Here the lines are not going to be normalized at the next commit. > # They stay CRLF. Isn't that the real source of the problem? Why don't we fix that then? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

Jeff King writes: > On Tue, Mar 29, 2016 at 08:08:29AM -0700, Junio C Hamano wrote: > >> So it is a misconfiguration if you only set GIT_WORK_TREE without >> setting GIT_DIR. > > Hmm. I have frequently done this when my cwd is a git repository (e.g., > a bare one), and it works as

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

On 29.03.16 19:21, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen >> >> git blame reports lines as not "Not Committed Yet" when they have >> CRLF in the index, CRLF in the worktree and e.g. core.autocrlf is true. >> >> Since commit c48053 "new safer

Re: [PATCH 4/7] submodule update --init: correct path handling in recursive submodules

On Tue, Mar 29, 2016 at 12:46 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> This fixes the test introduced by the parent commit. >> >> Signed-off-by: Stefan Beller >> --- > > The first hunk in this patch touches lines that goes

Re: [PATCH 4/7] submodule update --init: correct path handling in recursive submodules

Stefan Beller writes: > This fixes the test introduced by the parent commit. > > Signed-off-by: Stefan Beller > --- The first hunk in this patch touches lines that goes away with d5bc3cd2 (submodule: port init from shell to C, 2016-03-14) on your

Re: [PATCH v1 5/7] CRLF: unify the "auto" handling

On Tue, Mar 29, 2016 at 9:25 AM, wrote: > Make .gitattributes "* text=auto eol=crlf" to do the same as > setting core.autocrlf=true and "* text=auto eol=crlf" the same > as core.autocrlf=input > > Signed-off-by: Torsten Bögershausen > --- > diff --git

Re: `git rev-parse --is-inside-work-tree` and $GIT_WORK_TREE

On Tue, Mar 29, 2016 at 08:08:29AM -0700, Junio C Hamano wrote: > So it is a misconfiguration if you only set GIT_WORK_TREE without > setting GIT_DIR. Hmm. I have frequently done this when my cwd is a git repository (e.g., a bare one), and it works as you'd expect (find the git-dir in the

Re: [PATCH v1 1/7] Make it possible to get sha1 for a path from the index

On Tue, Mar 29, 2016 at 9:25 AM, wrote: > Factor out the retrival of the sha1 for a given path in s/retrival/retrieval/ > read_blob_data_from_index() into the function get_sha1_from_index(). > > This will be used in the next commit, when convert.c can do the analyze > for

  1   2   >