Michael Haggerty writes:
> Given that "git push --atomic" is one of the main new features of 2.4.0,
> it would be unfortunate for the release to contain this bug, plus the
> bug that atomic pushes can fail due to file descriptor exhaustion.
>
> Is this problem important enough to justify delaying
"new safer autocrlf handling":
Check if eols in a file are converted at commit, when the file has
CR (or CLLF) in the repo (technically speaking in the index).
Add a test-file repoMIX with mixed line-endings.
When converting LF->CRLF or CRLF->LF: check the warnings
checkout_files():
Chec
On 04/24/2015 01:35 PM, Michael Haggerty wrote:
> The old code locked all of the references in the first loop, leaving
> all of the lockfiles open until later loops. Since we might be
> updating a lot of references, this could cause file descriptor
> exhaustion.
>
> But there is no reason to keep
On Sat, Apr 25, 2015 at 3:57 PM, Chris wrote:
> Hello,
>
> Using git version 2.3.5 with kernel 3.19.3-3-ARCH #1 SMP PREEMPT x86_64 I
> see the following error message when pulling or cloning a repo over ssh:
>
> """
> git clone ssh://user@mydomain:/home/user/path/to/project.git
> Cloning into 'pro
Hello,
Using git version 2.3.5 with kernel 3.19.3-3-ARCH #1 SMP PREEMPT x86_64
I see the following error message when pulling or cloning a repo over ssh:
"""
git clone ssh://user@mydomain:/home/user/path/to/project.git
Cloning into 'project'...
ssh: Could not resolve hostname mydomain:: Name o
When using `-v` to add a unified diff to the commit message, this is
stripped and not a part of the commit message. This is not mentioned.
Add a note about this with the `-v` description and slightly modify
the description for the default `--cleanup` mode.
Signed-off-by: Fredrik Gustafsson
---
On Sat, Apr 25, 2015 at 01:00:58AM -0400, Jeff King wrote:
> A better solution to what I proposed earlier is perhaps:
>
> git config alias.debug '!gdb --quiet \
> -ex "break exit" \
> -ex "run" \
> -ex "bt full" \
> -ex "continue" \
> -ex "quit"
On Fri, Apr 24, 2015 at 09:23:16PM -0700, Junio C Hamano wrote:
> The proposals so far, including this one, assume that the bug
> reporter will first fail the operation with "normal" invocation
> of Git (e.g. without GIT_DIE_ABORT exported) and then retry the
> same operation in a different way (e
Fredrik Gustafsson writes:
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 617e29b..e31d828 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -180,8 +180,9 @@ OPTIONS
> +
> --
> strip::
> - Strip leading and trailing em
Eric Sunshine writes:
> On Fri, Apr 24, 2015 at 7:51 PM, Eloy Espinaco wrote:
>> Ok, now I found [this
>> thread](http://thread.gmane.org/gmane.comp.version-control.git/251376)
>> that seems abandoned, but implements this config, a --no-verbose that
>> disable it for one-time and the tests, but
Michael Haggerty writes:
> In ref_transaction_commit(), close the reference lockfiles immediately
> to avoid keeping too many file descriptors open at a time. This is
> pretty easy, because in the first loop (where we create the locks) we
> already know what, if anything, has to be written into t
Jeff King writes:
> So if anything, I think my inclination would be to make it easier to
> help people (and ourselves) get a backtrace from gdb.
>
> One can get a core for a running process with gcore, or trigger a
> coredump by killing with SIGABRT. But catching it at the exact moment of
> a die
On Fri, Apr 24, 2015 at 7:51 PM, Eloy Espinaco wrote:
> Ok, now I found [this
> thread](http://thread.gmane.org/gmane.comp.version-control.git/251376)
> that seems abandoned, but implements this config, a --no-verbose that
> disable it for one-time and the tests, but was not merged (don't know
> w
Ok, now I found [this
thread](http://thread.gmane.org/gmane.comp.version-control.git/251376)
that seems abandoned, but implements this config, a --no-verbose that
disable it for one-time and the tests, but was not merged (don't know
why)
This was the patch I've intended to attach:
On Fri, Apr 24, 2015 at 03:46:30PM -0700, Pete Harlan wrote:
> On Fri, Apr 24, 2015 at 3:28 PM, brian m. carlson
> wrote:
> > The git_connect function has code to handle plink and tortoiseplink
> > specially, as they require different command line arguments from
> > OpenSSH. However, the match wa
On Fri, Apr 24, 2015 at 3:28 PM, brian m. carlson
wrote:
> The git_connect function has code to handle plink and tortoiseplink
> specially, as they require different command line arguments from
> OpenSSH. However, the match was done by checking for "plink"
> case-insensitively in the string, whic
On Thu, Apr 23, 2015 at 03:27:23PM -0400, Jeff King wrote:
> +static int do_for_each_ref(struct ref_cache *refs, const char *base,
> +each_ref_fn fn, int trim, int flags, void *cb_data)
> +{
> + return do_for_each_ref_generic(refs, base, fn, NULL, trim, flags,
> cb_data
On Wed, Apr 22, 2015 at 05:52:09PM -0700, Stefan Beller wrote:
> So you're switching the code for a possible future
> In an earlier series/cover letter you wrote
>
> > The goal of this series to improve type-checking in the codebase and to
> > make it easier to move to a different hash function if
The git_connect function has code to handle plink and tortoiseplink
specially, as they require different command line arguments from
OpenSSH. However, the match was done by checking for "plink"
case-insensitively in the string, which led to false positives when
GIT_SSH contained "uplink". Improve
The code path used in git_connect pushed the majority of the SSH
connection code into an else block, even though the if block returns.
Simplify the code by eliminating the else block, as it is unneeded.
Signed-off-by: Jeff King
Signed-off-by: brian m. carlson
---
connect.c | 42
On 04/24/2015 11:51 PM, Eric Sunshine wrote:
> On Fri, Apr 24, 2015 at 7:35 AM, Michael Haggerty
> wrote:
>> Instead, work directly with update->flags. This has the advantage that
>> the REF_DELETING bit, set in the first loop, can be read in the third
>> loop instead of having to compute the sam
On Fri, Apr 24, 2015 at 7:35 AM, Michael Haggerty wrote:
> Instead, work directly with update->flags. This has the advantage that
> the REF_DELETING bit, set in the first loop, can be read in the third
> loop instead of having to compute the same expression again. Plus, it
> was kindof confusing h
On Fri, Apr 24, 2015 at 11:15:09PM +0200, Michael Haggerty wrote:
> > Hmm. I think this is losing the distinction of "flags the caller has
> > passed in to us" versus "flags we are using locally only during the
> > transaction_commit routine". If callers look at the flags in the
> > REF_TRANSACTIO
On 04/24/2015 07:30 PM, Jeff King wrote:
> On Fri, Apr 24, 2015 at 01:35:48PM +0200, Michael Haggerty wrote:
>
>> Instead, work directly with update->flags. This has the advantage that
>> the REF_DELETING bit, set in the first loop, can be read in the third
>> loop instead of having to compute the
On Fri, Apr 24, 2015 at 11:12:36AM -0700, Jonathan Nieder wrote:
> Actually, I wouldn't mind an environment variable that tells error()
> to include a backtrace if someone wants it. (See backtrace(3)
> for implementation hints if interested in doing that.)
Thanks, I didn't know about backtrace(3
On Fri, Apr 24, 2015 at 3:46 PM, Torsten Bögershausen wrote:
> "new safer autocrlf handling":
> Check if eols in a file are converted at commit, when the file has
> CR (or CLLF) in the repo (technically speaking in the index).
> Add a test-file repoMIX with mixed line-endings.
> When conve
When using `-v` to add a unified diff to the commit message, this is
stripped and not a part of the commit message. This is not mentioned.
Add a note about this with the `-v` description as well as description
for the default `--cleanup` mode.
Signed-off-by: Fredrik Gustafsson
---
Documentation
Eloy Espinaco writes:
> Hi,
>
> It is my first mail to the list, so "hello world".
Hi, and welcome to the list.
> I wanted to make a feature-request about a config setting to make the
> commit always verbose. I'm not the only one asking for that, there is an
> old question in [Stack Overflow][1
"new safer autocrlf handling":
Check if eols in a file are converted at commit, when the file has
CR (or CLLF) in the repo (technically speaking in the index).
Add a test-file repoMIX with mixed line-endings.
When converting LF->CRLF or CRLF->LF: check the warnings
checkout_files():
Chec
Hi,
It is my first mail to the list, so "hello world".
I wanted to make a feature-request about a config setting to make the
commit always verbose. I'm not the only one asking for that, there is an
old question in [Stack Overflow][1].
So I was thinking if it was possible to make a pull request f
On Fri, Apr 24, 2015 at 10:26 AM, Jeff King wrote:
> On Fri, Apr 24, 2015 at 01:35:44PM +0200, Michael Haggerty wrote:
>
>> In ref_transaction_commit(), close the reference lockfiles immediately
>> to avoid keeping too many file descriptors open at a time. This is
>> pretty easy, because in the fi
On Fri, Apr 24, 2015 at 11:12 AM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> I understood that you were talking about Could being capitalized.
>> Though it's distributed 30/70 which hints to me we do not care in
>> enough to explain the capitalized letters as slip-throughs on review
>> or
Stefan Beller wrote:
> I understood that you were talking about Could being capitalized.
> Though it's distributed 30/70 which hints to me we do not care in
> enough to explain the capitalized letters as slip-throughs on review
> or such, but it looks like the authors choice to me.
Lowercase, bri
On Fri, Apr 24, 2015 at 01:35:48PM +0200, Michael Haggerty wrote:
> Instead, work directly with update->flags. This has the advantage that
> the REF_DELETING bit, set in the first loop, can be read in the third
> loop instead of having to compute the same expression again. Plus, it
> was kindof co
On Fri, Apr 24, 2015 at 01:35:44PM +0200, Michael Haggerty wrote:
> In ref_transaction_commit(), close the reference lockfiles immediately
> to avoid keeping too many file descriptors open at a time. This is
> pretty easy, because in the first loop (where we create the locks) we
> already know wha
On Fri, Apr 24, 2015 at 09:16:28AM -0700, Stefan Beller wrote:
> I think it's a mistake to s/Could/could/g for all errors in the code base
> as it reduces the information provided in the error messages.
> Just 3 days ago ("Regular Rebase Failure"). I used different
> capitalization to get a better
On 04/24/2015 02:27 AM, Pete Harlan wrote:
> Junio writes:
>> Michael Haggerty writes:
>>
>>> Document `git status -v`, including its new doubled `-vv` form.
>>>
>>> Signed-off-by: Michael Haggerty
>>> ---
>>
>> Will queue on mg/status-v-v series, which did add description for
>> "commit -v", but
On Thu, Apr 23, 2015 at 6:37 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Thu, Apr 23, 2015 at 10:56 AM, Junio C Hamano wrote:
>>
+ int save_errno = errno;
+ error("Couldn't reopen %s", lock->lk->filename.buf);
>>>
>>> No need to change this line, b
I get an error if I misspell part of the path. For example, if I type
//depot/maain instead of //depot/main I will get the "no such files"
message you indicated. BUT using incorrect case like //depot/main
instead of //depot/Main doesn't return any error, but still completes
and creates an empty rep
On Fri, Apr 24, 2015 at 7:30 AM, SZEDER Gábor wrote:
> Hi,
>
> Quoting Marc Khouzam :
>>
>> Hi,
>>
>> I did notice the problem a while ago and had traced it back to the
>> fact that the bash completion scripts no longer adds the trailing '/'
>> at the end of directories.
>> Tcsh needs that '/' to
[ Please, don't top-post on this list ]
Scott Meyer writes:
> The site is local to my laptop. I am attempting to establish a
> development environment where I can view and test changes before
> moving to production.
OK, so you're doing web development, right?
Then, the problem is unrelated fr
The site is local to my laptop. I am attempting to establish a
development environment where I can view and test changes before
moving to production.
On Fri, Apr 24, 2015 at 8:50 AM, Matthieu Moy
wrote:
> Scott Meyer writes:
>
>> When I use my browser to bring up the site the change is not visi
Scott Meyer writes:
> When I use my browser to bring up the site the change is not visible.
Which site are you talking about?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
I used git in the following steps.
This is a local directory on a Mac, with Yosemite, using the latest
git version. The directory name is "development".
using eclipse I created a branch WO_1
I made a change to the file
eclipse indicates the change
I use the plus to add it to the Index
I commit t
Signed-off-by: Michael Haggerty
---
refs.c | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/refs.c b/refs.c
index 9b68aec..a55d541 100644
--- a/refs.c
+++ b/refs.c
@@ -2770,8 +2770,10 @@ static int rename_ref_available(const char *oldnam
The old code locked all of the references in the first loop, leaving
all of the lockfiles open until later loops. Since we might be
updating a lot of references, this could cause file descriptor
exhaustion.
But there is no reason to keep the lockfiles open after the first
loop:
* For references b
In ref_transaction_commit(), close the reference lockfiles immediately
to avoid keeping too many file descriptors open at a time. This is
pretty easy, because in the first loop (where we create the locks) we
already know what, if anything, has to be written into the lockfile.
So write it and close
This is the first step towards separating the checking and writing of
the new reference value to committing the change.
Signed-off-by: Michael Haggerty
---
refs.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 4f495bd..72dae21 1006
Signed-off-by: Michael Haggerty
---
refs.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index 72dae21..9b68aec 100644
--- a/refs.c
+++ b/refs.c
@@ -3052,16 +3052,9 @@ static int write_ref_to_lockfile(struct ref_lock *lock,
const
Instead, work directly with update->flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the third
loop instead of having to compute the same expression again. Plus, it
was kindof confusing having both update->flags and flags, which
sometimes had different
Hi,
Quoting Marc Khouzam :
Hi,
I did notice the problem a while ago and had traced it back to the
fact that the bash completion scripts no longer adds the trailing '/'
at the end of directories.
Tcsh needs that '/' to know not to add that annoying extra space.
Bash 3 needed to put it that trai
On Mon, Apr 06, 2015 at 10:21:37PM +0800, niu2x wrote:
> I'm a beginner.
> Please tell me the log of git commit is exist forever or 90 days
As long as a commit is (indirectly) referenced by a branch or tag, it will
be kept forever. Only if you rewrite history causing commits to be
unreferenced (fo
On 18/04/15 08:36, Mike Hommey wrote:
On Fri, Apr 17, 2015 at 11:44:00AM -0700, Junio C Hamano wrote:
So perhaps we should rip the case folding out altogether instead?
The entry for the change in the Release Notes may say:
* "git fast-import" incorrectly case-folded the paths recorded in
On 23/04/15 14:42, FusionX86 wrote:
Hi Luke,
I found a silly mistake I was making in the command I've been using.
The folder under the depot should have been capitalized, but it
wasn't. Also, I expected that if there was a problem with the command,
it would fail with some message instead of crea
54 matches
Mail list logo
