Re: [PATCH 3/3] Documentation: make explicit that optional arguments must be stuck

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

Announcing Git for Windows 2.5.3

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

default remote branch

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

Re: [PATCH] Makefile: Change library order for static linking

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

Re: git status -u is mildly astonishing

Jeff King writes: > On Thu, Sep 17, 2015 at 04:27:39PM +0200, Matthieu Moy wrote: > >> > Therefore I would argue that -u is behaving differently from other >> > arguments (especially when considered across all git subcommands) >> >> This is because you have options with

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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. >> >>

BUG: git_work_tree issue with git alias and scripting

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.

Re: [PATCH] l10n: de.po: better language for 2 strings

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [PATCH 54/67] color: add overflow checks for parsing colors

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

Re: [PATCH 54/67] color: add overflow checks for parsing colors

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) \ > > +

Re: [BUG?] HEAD detached at HEAD

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

Re: [PATCH 53/67] drop strcpy in favor of raw sha1_to_hex

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); > > -

Re: Bug Report: git gui clones non-master default branch as master

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,

Re: [PATCH 1/3] Documentation: use 'keyid' consistantly, not 'key-id'

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`

Re: [PATCH 53/67] drop strcpy in favor of raw sha1_to_hex

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

Re: [PATCH 57/67] receive-pack: simplify keep_arg computation

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

[PATCH v5] gc: save log from daemonized gc --auto and print it next time

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

[Alt. PATCH v5] gc: save log from daemonized gc --auto and print it next time

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

Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied

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

Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied

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:

[PATCH] send-email: fix uninitialized var warning for $smtp_auth

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

Re: [PATCH] send-email: fix uninitialized var warning for $smtp_auth

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 >

Re: [PATCH] send-email: fix uninitialized var warning for $smtp_auth

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: > > #

Re: [PATCH] send-email: fix uninitialized var warning for $smtp_auth

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

Re: [PATCH] send-email: fix uninitialized var warning for $smtp_auth

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, >

Windows patches roadmap, was Re: On a personal note

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,

Re: [PATCH] l10n: de.po: better language for 2 strings

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

[PATCH 3/3] Documentation: make explicit that optional arguments must be stuck

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

[PATCH 2/3] Documentation/grep: fix documentation of -O

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

[PATCH v8 3/4] worktree: add functions to get worktree details

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

[PATCH v8 4/4] worktree: add 'list' command

'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

[PATCH v8 0/4] worktree: list functions and command

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

[PATCH v8 1/4] worktree: add top-level worktree.c

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

[PATCH v8 2/4] worktree: refactor find_linked_symref function

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

BUG: git_work_tree issue with git alias and scripting

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.

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [PATCH 03/10] run-command: add an asynchronous parallel child processor

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

[BUG?] HEAD detached at HEAD

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

Re: [PATCH 57/67] receive-pack: simplify keep_arg computation

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

[PATCH 0/3] Clarify the documentation of options with optional arguments

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

[PATCH 1/3] Documentation: use 'keyid' consistantly, not 'key-id'

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

Re: [PATCH 1/3] Documentation: use 'keyid' consistantly, not 'key-id'

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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".

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [BUG?] HEAD detached at HEAD

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

Re: [BUG?] HEAD detached at HEAD

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

Re: [BUG?] HEAD detached at HEAD

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