On 03/29/2016 10:12 PM, David Turner wrote:
> 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
On Tue, Mar 29, 2016 at 9:55 PM, Jeff King wrote:
> One thing I like to do when playing with new diff ideas is to pipe all
> of "log -p" for a real project through it and see what differences it
> produces.
>
Great idea!
> Below is a perl script that implements Stefan's heuristic. I checked its
On Tue, Mar 29, 2016 at 9:55 PM, Jeff King wrote:
> 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
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, w
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 reproducing with
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 mer
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 pro
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.
>
> Basically, I picked up
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 this
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 Ma
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, we can use the
>> corresponding --no-checkout to
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 archive
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:
http://thread.gmane.org/gmane.
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 using
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
>
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 strbufs. Make su
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 to the individu
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 a/t/t7407-submodule-foreach.sh b/t/t7407-
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
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 @@
b2
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' (${pwd}/su
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 ++--
t/t7406-submodule-update.sh | 2
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 executin
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 sam
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 f4afdc6..86e21de 100644
> -
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 --
> 1 file c
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 t
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, so no need to keep it
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
> ---
>
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
> ---
> imap-send
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 pathspec mechanism (it predates the pathspec machinery that was
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
> ---
> imap-send.c | 2 +-
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
>> '../super/submodule'
>> the `super` d
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 | 2 +-
> 1 file changed, 1 insertion(+), 1
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
> ---
> diff --git a/path.c
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/
>> $ pwd
>>
`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 deletion(-)
diff --git
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 a/bundle.c b/bundle.c
index
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 @@ static int send_r
`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 --git a/path.c b/pat
`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
---
builtin/not
`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(-)
diff --git a/imap-se
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
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 however does not work well in "git log", as
> we indent
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 good heuristic. Can we think of any examples w
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
> ---
> git-submodule.sh
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 2016-03-29 19:02:33.359343311
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
> Submodule 'submodule' (${p
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 "all" perhaps?
As t
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 :
惠轶群 writes:
> # Purpose
> The current implementation of send-email is based on perl an
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 | 2 +-
pretty.c
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 t
"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
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 front of them.
This should all
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 existingStuff1(..) {
>>> ...
>>> }
>>> +
>>> +
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
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 a/t/t7407-submodule-foreach.sh b/t/t7407-
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 ++--
t/t7406-submodule-update.sh | 2
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 @@
b2
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 '
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 exp
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
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 true, but it feels k
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
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
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 ++--
t/t7406-submodule-update.sh | 2
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 a/t/t7407-submodule-foreach.sh b/t/t7407-
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 @@
b2
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 exp
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 updat
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 '
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
> >
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 "cd
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 "are
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 in memory (memory bit
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 ind
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, is
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
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
> pull.rebase=true case.
>
> Add t
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.
>
> Introduce two functions test_r
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/
> >
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 quite broken. How would a user ever fix broken data in
>>
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 --is-inside-w
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
> the index then? I know the commit
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 could be used.
>
> Use test_i18
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 have these:
--
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 git-d
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 in these
discus
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 linkgit:git-checkout[1]
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 ensuring consistent conditi
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 implementation.
Sound like sensible
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
> > | cond
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 jk/check-repository-
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"
> '
>
> +! test_have_pr
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 explanation of *why* this cha
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 message to majord...@
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 you'd expect (f
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 autocrlf handlin
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 away with
> d5bc3cd2 (submodule: port init from shell to C,
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 sb/submodule-init topic and the whole block is r
1 - 100 of 168 matches
Mail list logo
