While commit 9f673f9 (gc: config option for running --auto in
background - 2014-02-08) helps reduce some complaints about 'gc
--auto' hogging the terminal, it creates another set of problems.
The latest in this set is, as the result of daemonizing, stderr is
closed and all warnings are lost. This
While commit 9f673f9 (gc: config option for running --auto in
background - 2014-02-08) helps reduce some complaints about 'gc
--auto' hogging the terminal, it creates another set of problems.
The latest in this set is, as the result of daemonizing, stderr is
closed and all warnings are lost. This
On Sat, Sep 19, 2015 at 9:21 AM, Duy Nguyen wrote:
> Even if you disable gc --auto and run it periodically (with
> cron or something), it will write gc.pid.
Ignore this sentence. Of course you can run manual gc using a
different user and with write access.
--
Duy
--
To unsubscribe from this list
On Thu, Sep 17, 2015 at 11:54 PM, Joakim Tjernlund
wrote:
> On Thu, 2015-09-17 at 20:18 +0700, Duy Nguyen wrote:
>> On Mon, Sep 14, 2015 at 10:37 PM, Joakim Tjernlund
>> wrote:
>> > On Mon, 2015-08-31 at 16:56 +0700, Duy Nguyen wrote:
>> > > On Fri, Aug 21, 2015 at 6:36 PM, Joakim Tjernlund
>> >
On Fri, Sep 18, 2015 at 06:47:20PM -0400, Eric Sunshine wrote:
> Makes sense (again). Thanks for the explanation.
No problem. Thanks for the review.
--
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:
On Fri, Sep 18, 2015 at 6:42 PM, Brian Norris
wrote:
> On Fri, Sep 18, 2015 at 06:25:24PM -0400, Eric Sunshine wrote:
>> Thanks, makes sense. I wonder if moving the check to the point where
>> $smtp_auth is actually used (despite the noisier diff) would be cleaner,
>
> By moving the patch into the
On Fri, Sep 18, 2015 at 06:25:24PM -0400, Eric Sunshine wrote:
> On Fri, Sep 18, 2015 at 03:12:50PM -0700, Brian Norris wrote:
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -1136,7 +1136,7 @@ sub smtp_auth_maybe {
> >
> > # Check mechanism naming as defined in:
> > #
On Fri, Sep 18, 2015 at 03:12:50PM -0700, Brian Norris wrote:
> On the latest version of git-send-email, I see this error just before
> running SMTP auth (I didn't provide any --smtp-auth= parameter):
>
> Use of uninitialized value $smtp_auth in pattern match (m//) at
> /usr/local/google/home/b
On the latest version of git-send-email, I see this error just before
running SMTP auth (I didn't provide any --smtp-auth= parameter):
Use of uninitialized value $smtp_auth in pattern match (m//) at
/usr/local/google/home/briannorris/git/git/git-send-email.perl line 1139.
Signed-off-by: Brian
Dear Git users,
it is my pleasure to announce that Git for Windows 2.5.3 can be downloaded from
https://git-for-windows.github.io/.
I would like to take this opportunity to thank everybody who contributes to
this project (and you will see below that there have been quite a few changes
since re
On Fri, Sep 18, 2015 at 03:24:37PM -0400, Eric Sunshine wrote:
> > fprintf(stderr, "updating '%s'", ref->name);
> > if (strcmp(ref->name, ref->peer_ref->name))
> > fprintf(stderr, " using '%s'", ref->peer_ref->name);
> > - fprin
On Fri, Sep 18, 2015 at 05:01:50PM +0200, Matthieu Moy wrote:
> The behavior of command-line options with optional arguments is
> documented in gitcli(7), but it is easy for users to miss, and hard for
> the same user to understand why e.g. "git status -u no" does not work.
>
> Document this expl
On Tue, Sep 15, 2015 at 12:06 PM, Jeff King wrote:
> In some cases where we strcpy() the result of sha1_to_hex(),
> there's no need; the result goes directly into a printf
> statement, and we can simply pass the return value from
> sha1_to_hex() directly.
>
> Signed-off-by: Jeff King
> ---
> diff
On Fri, Sep 18, 2015 at 05:01:48PM +0200, Matthieu Moy wrote:
> Signed-off-by: Matthieu Moy
> ---
> Documentation/git-cherry-pick.txt | 4 ++--
> Documentation/git-revert.txt | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
Hmm, grepping for `key-id` turns up quite a few more h
Git devs,
Can I get a confirmation that someone has confirmed this as a bug?
And that it is in a queue somewhere for eventual fixing?
Thanks,
John Medema
Systems Administrator
United Drugs, a Subsidiary of AAP (American Associated Pharmacies)
john.med...@uniteddrugs.com
7243 N 16th Street, Phoen
Stefan Beller writes:
> On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moy
> wrote:
>> Jacob Keller writes:
>>
>>> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
>>> wrote:
I'm getting it even if there's a tag and/or a branch pointing to the
same commit.
Any idea what's going on
On Fri, Sep 18, 2015 at 02:54:11PM -0400, Eric Sunshine wrote:
> > @@ -224,12 +227,18 @@ int color_parse_mem(const char *value, int value_len,
> > char *dst)
> > goto bad;
> > }
> >
> > +#define OUT(x) do { \
> > + if (dst == end) \
> > + die("B
On Tue, Sep 15, 2015 at 12:07 PM, Jeff King wrote:
> Our color parsing is designed to never exceed COLOR_MAXLEN
> bytes. But the relationship between that hand-computed
> number and the parsing code is not at all obvious, and we
> merely hope that it has been computed correctly for all
> cases.
>
On Fri, Sep 18, 2015 at 02:43:56PM -0400, Eric Sunshine wrote:
> On Tue, Sep 15, 2015 at 12:10 PM, Jeff King wrote:
> > To generate "--keep=receive-pack $pid on $host", we write
> > progressively into a single buffer, which requires keeping
> > track of how much we've written so far. But since th
On Tue, Sep 15, 2015 at 12:10 PM, Jeff King wrote:
> To generate "--keep=receive-pack $pid on $host", we write
> progressively into a single buffer, which requires keeping
> track of how much we've written so far. But since the result
> is destined to go into our argv array, we can simply use
> ar
On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moy
wrote:
> Jacob Keller writes:
>
>> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
>> wrote:
>>> I'm getting it even if there's a tag and/or a branch pointing to the
>>> same commit.
>>>
>>> Any idea what's going on?
>>
>> Any chance you accidentally
Jacob Keller writes:
> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
> wrote:
>> I'm getting it even if there's a tag and/or a branch pointing to the
>> same commit.
>>
>> Any idea what's going on?
>
> Any chance you accidentally made a branch or tag named HEAD?
Nice try ;-), but no:
$ git sta
On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
wrote:
> I'm getting it even if there's a tag and/or a branch pointing to the
> same commit.
>
> Any idea what's going on?
>
Any chance you accidentally made a branch or tag named HEAD?
Regards,
Jake
--
To unsubscribe from this list: send the line "u
Hi,
I did a "git checkout --detached", and now I get:
$ git status
HEAD detached at HEAD
nothing to commit, working directory clean
$ git branch
* (HEAD detached at HEAD)
master
The "HEAD detached at HEAD" is not very helpful. I thought there was an
abbreved sha1 here before, but I'
On Thu, Sep 17, 2015 at 6:05 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Thu, Sep 17, 2015 at 2:44 PM, Junio C Hamano wrote:
>>
>>> Hmm, you are relying on the fact that a valid pid can never be 0, so
>>> you can just use pp->children[i].child.pid to see if a "slot" is
>>> occupied
Karthik Nayak writes:
> About the issue at hand, we should probably squash this in
Looks good to me.
--
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
More majordomo info at
On Fri, Sep 18, 2015 at 9:00 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Fri, Sep 18, 2015 at 8:49 PM, Matthieu Moy
>> wrote:
>>> Karthik Nayak writes:
>>>
Not sure this is much of a problem with regards to "--[no-]merged"
I mean isn't the square brackets self-explanatory?
Karthik Nayak writes:
> On Fri, Sep 18, 2015 at 8:49 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> Not sure this is much of a problem with regards to "--[no-]merged"
>>> I mean isn't the square brackets self-explanatory?
>>
>> Well, usually --no-foo means "cancel the effect of --foo
Subject: ... use 'keyid' consistantly
Sorry, should s/consistantly/consistently/. Will resend.
--
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
More majordomo info at http://v
On Fri, Sep 18, 2015 at 8:49 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Not sure this is much of a problem with regards to "--[no-]merged"
>> I mean isn't the square brackets self-explanatory?
>
> Well, usually --no-foo means "cancel the effect of --foo", ie. "git
> command --foo --no-f
Karthik Nayak writes:
> Not sure this is much of a problem with regards to "--[no-]merged"
> I mean isn't the square brackets self-explanatory?
Well, usually --no-foo means "cancel the effect of --foo", ie. "git
command --foo --no-foo" is equivalent to "git command".
Here, --no-merged=some-ref
Signed-off-by: Matthieu Moy
---
Documentation/git-cherry-pick.txt | 4 ++--
Documentation/git-revert.txt | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index 1147c71..83b3cc2 100644
--- a/Documen
The first patch is essentially to make the last one look good. The
second is a real documentation bug. The last one may be controversial
as it re-documents something already documented in gitcli, but I think
it's a good thing.
Matthieu Moy (3):
Documentation: use 'keyid' consistantly, not 'key-i
The behavior of command-line options with optional arguments is
documented in gitcli(7), but it is easy for users to miss, and hard for
the same user to understand why e.g. "git status -u no" does not work.
Document this explicitly in the documentation of each short option having
an optional argum
On Fri, Sep 18, 2015 at 2:12 PM, John Keeping wrote:
> On Fri, Sep 18, 2015 at 09:10:08AM +0200, Matthieu Moy wrote:
>> Junio C Hamano writes:
>>
>> > John Keeping writes:
>> >
>> >>> +--[no-]merged []::
>> >>
>> >> We prefer to write --[no-]* as:
>> >>
>> >>--option::
>> >>--no-option::
Since the argument of -O, --open-file-in-pager is optional, it must be
stuck to the command. Reflect this in the documentation.
Signed-off-by: Matthieu Moy
---
Documentation/git-grep.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-grep.txt b/Document
Hi,
>> #: git-am.sh:512
>> msgid "Please make up your mind. --skip or --abort?"
>> -msgstr "Bitte werden Sie sich klar. --skip oder --abort?"
>> +msgstr "Bitte entscheiden Sie sich. --skip oder --abort?"
>>
>
> This string has been removed in 40147ec (l10n: de.po: translate 123
> new messages
worktree.c contains functions to work with and get information from
worktrees. This introduction moves functions related to worktrees
from branch.c into worktree.c
Signed-off-by: Michael Rappazzo
---
Makefile| 1 +
branch.c| 79 +-
The worktree structure provided for an individual worktree includes the
absolute path, the location of the git dir, the head ref (if not
detached), the head revision sha1, whether or not head is detached, and
whether or not the worktree is a bare repo.
Signed-off-by: Michael Rappazzo
---
worktre
'git worktree list' iterates through the worktree list, and outputs
details of the worktree including the path to the worktree, the currently
checked out revision and branch, and if the work tree is bare. There is
also porcelain format option available.
Signed-off-by: Michael Rappazzo
---
Docum
Changes from v7[1]:
- Reworked history to try to maintain blame from moving functions
from branch.c
- Removed the worktree_list struct (linked list) and instead return
return an array of worktrees. An alternative was also proposed to
include a `next
Refactoring will help transition this code to provide additional useful
worktree functions.
Signed-off-by: Michael Rappazzo
---
worktree.c | 86 ++
1 file changed, 64 insertions(+), 22 deletions(-)
diff --git a/worktree.c b/worktree.c
Hi Stefan,
[sorry that your mail to the git-for-windows Google Group got rejected; I want
to try to keep this list subscribers-only as long as possible so as not to
waste precious time on moderating 20+ spam mails per day, as we used to do with
msysgit's mailing list.]
On 2015-09-17 21:27, Ste
Hi,
the 'git remote show ' command shows the default branch among
other things.
The default branch being the branch that a clone will have immediately
after cloning.
Is it possible to run a command that only shows that default branch
for a given remote?
Also, I tried finding out whether I can us
John Keeping writes:
> On Fri, Sep 18, 2015 at 09:10:08AM +0200, Matthieu Moy wrote:
>
>> The `commit` may be omitted and defaults to HEAD if this is the final
>> argument.
>
> I find that slightly confusing, although that might just be me. It's
> slightly longer, but I would write:
>
> Th
Phillip Sz wrote:
> just 2 strings I think we could translate better.
Thanks!
>
> Signed-off-by: Phillip Sz
> ---
> po/de.po | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> #: git-am.sh:512
> msgid "Please make up your mind. --skip or --abort?"
> -msgstr "Bitte werden Sie s
On Fri, Sep 18, 2015 at 09:10:08AM +0200, Matthieu Moy wrote:
> Junio C Hamano writes:
>
> > John Keeping writes:
> >
> >>> +--[no-]merged []::
> >>
> >> We prefer to write --[no-]* as:
> >>
> >>--option::
> >>--no-option::
> >>
> >> although this may be the first instance that we see th
Hello,
Attached is a simple script exposing a possible bug when git alias is
combined with git commands in script. It should be pretty self-explanatory.
Check what it does and execute it. On my Linux and OSX, both with git 2.5.1
behave the same, ie. git add fails even the file "test" is in $PWD.
Hello,
Attached is a simple script exposing a possible bug when git alias is
combined with git commands in script. It should be pretty self-explanatory.
Check what it does and execute it. On my Linux and OSX, both with git 2.5.1
behave the same, ie. git add fails even the file "test" is in $PWD.
On Thu, Sep 17, 2015 at 03:08:25PM -0700, Junio C Hamano wrote:
> That is, for most people, linking with -lcrypto was sufficient, but
> some people needed to grab things from -lssl when they need to do
> so, because things in -lcrypto referred to what was only in -lssl.
Oh I see what you mean, I m
Junio C Hamano writes:
> John Keeping writes:
>
>>> +--[no-]merged []::
>>
>> We prefer to write --[no-]* as:
>>
>> --option::
>> --no-option::
>>
>> although this may be the first instance that we see this combination
>> with an argument.
>>
>> I also found the "[]" syntax confusing a
51 matches
Mail list logo