Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

On 02/15/2017 03:26 PM, SZEDER Gábor wrote: > On Tue, Feb 14, 2017 at 10:24 PM, wrote: > >> + *) >> + __git_complete_tree_file "$ref" "$cur" >> + ;; > > There is one more caveat here. > > Both our

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

already been given. If you think that this would be desirable, find a revised version below. Otherwise drop it. On 02/15/2017 04:11 AM, SZEDER Gábor wrote: > On Tue, Feb 14, 2017 at 10:24 PM, <cornelius.w...@tngtech.com> wrote: >> From: Cornelius Weig <cornelius.w...@tngtech.com

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

On 02/14/2017 10:31 PM, Junio C Hamano wrote: > cornelius.w...@tngtech.com writes: > >> From: Cornelius Weig <cornelius.w...@tngtech.com> >> >> Git-checkout completes words starting with '--' as options and other >> words as refs. Even after specifyi

[PATCH v2 2/2] completion: checkout: complete paths when ref given

From: Cornelius Weig <cornelius.w...@tngtech.com> Git-checkout completes words starting with '--' as options and other words as refs. Even after specifying a ref, further words not starting with '--' are completed as refs, which is invalid for git-checkout. This commit ensures that

[PATCH v2 1/2] completion: extract utility to complete paths from tree-ish

From: Cornelius Weig <cornelius.w...@tngtech.com> The function __git_complete_revlist_file understands how to complete a path such as 'topic:ref'. In that case, the revision (topic) and the path component (ref) are both part of the same word. However, some cases require that the re

Re: [PATCH] completion: complete modified files for checkout with '--'

On 02/14/2017 01:50 AM, SZEDER Gábor wrote: > On Tue, Feb 14, 2017 at 12:33 AM, <cornelius.w...@tngtech.com> wrote: >> From: Cornelius Weig <cornelius.w...@tngtech.com> >> >> The command line completion for git-checkout bails out when seeing '--' >> as

[PATCH] completion: complete modified files for checkout with '--'

From: Cornelius Weig <cornelius.w...@tngtech.com> The command line completion for git-checkout bails out when seeing '--' as an isolated argument. For git-checkout this signifies the start of a list of files which are to be checked out. Checkout of files makes only sense for modified

[PATCH] completion: teach to complete git-subtree

From: Cornelius Weig <cornelius.w...@tngtech.com> Git-subtree is a contrib-command without completion, making it cumbersome to use. Teach bash completion to complete the subcommands of subtree (add, merge, pull, push, split) and options thereof. For subcommands supporting it (add, push

Re: [PATCH 6/7] completion: teach remote subcommands option completion

On 02/02/2017 02:37 AM, SZEDER Gábor wrote: > The 'set-head' subcommand has '--auto' and '--delete' options, and > 'set-branches' has '--add'. Oops. Thanks for spotting this.. >> __git_complete_remote_or_refspec >> ;; >> -update) >> +update,*) > > The

Re: Request re git status

On 02/07/2017 01:45 AM, Phil Hord wrote: > On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote: > Do you mean you almost pushed some changed history with "--force" > which would have lost others' changes? Use of this option is > discouraged on shared branches for this very reason.

[PATCH v5] tag: generate useful reflog message

From: Cornelius Weig <cornelius.w...@tngtech.com> When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For e

Re: [PATCH v4] tag: generate useful reflog message

On 02/08/2017 10:28 PM, Junio C Hamano wrote: > cornelius.w...@tngtech.com writes: > >> From: Cornelius Weig <cornelius.w...@tngtech.com> >> >> When tags are created with `--create-reflog` or with the option >> `core.logAllRefUpdates` set to 'always', a r

Re: [PATCH 1/2] pathspec magic: add '^' as alias for '!'

As Duy pointed out, the glossary needs an update too. For this one, the cange can be minimal I think: diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 8ad29e6..f127fe9 100644 --- a/Documentation/glossary-content.txt +++

Re: [PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns

Again, as Duy pointed out this should be documented. How about something like this: diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index f127fe9..781cde3 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -387,7

Re: [RFC] mailmap.blob overrides default .mailmap

On 02/07/2017 08:28 PM, Jeff King wrote: > > I think it was mostly that I had to define _some_ order. This made sense > to me as similar to things like attributes or excludes, where we prefer > clone-specific data over in-history data (so .git/info/attributes takes > precedence over

Re: ``git clean -xdf'' and ``make clean''

On 02/07/2017 03:17 PM, Hongyi Zhao wrote: > Hi all, > > In order to delete all of the last build stuff, does the following two > methods equivalent or not? > > ``git clean -xdf'' and ``make clean'' No, it is not equivalent. * `make clean` removes any build-related files (assuming that the

[RFC] mailmap.blob overrides default .mailmap

Hi, I was reading into the mailmap handling today and I'm a bit puzzled by the overriding behavior. This is what the documentation says about precedence (emphasis mine): - mailmap.file The location of an augmenting mailmap file. The default mailmap, located in the root of

[PATCH v4] tag: generate useful reflog message

From: Cornelius Weig <cornelius.w...@tngtech.com> Thanks for taking a look at my last version. > On the other hand, it's not like failing to describe the tagged > commit in the reflog is such a grave error. If we can get away with > being vague on a tag that points at an object

[PATCH v4] tag: generate useful reflog message

From: Cornelius Weig <cornelius.w...@tngtech.com> When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For e

Re: [PATCH] tag: generate useful reflog message

On 02/06/2017 12:25 AM, Junio C Hamano wrote: > cornelius.w...@tngtech.com writes > For a tag, I would imagine something like "tag: tagged 4e59582ff7 > ("Seventh batch for 2.12", 2017-01-23)" would be more appropriate. Yes, I agree that this is much clearer. The revised version v3 implements

[PATCH v3] tag: generate useful reflog message

From: Cornelius Weig <cornelius.w...@tngtech.com> When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For e

[PATCH v2] tag: generate useful reflog message

From: Cornelius Weig <cornelius.w...@tngtech.com> When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For e

[PATCH] tag: generate useful reflog message

From: Cornelius Weig <cornelius.w...@tngtech.com> When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For e

Re: [PATCH 1/2] doc: add doc for git-push --recurse-submodules=only

Shouldn't this be part of v2.12-rc0? I just checked but it's not there. Cheers, Cornelius

Re: BUG: "git checkout -q -b foo origin/foo" is not quiet

On 02/03/2017 10:36 PM, Kevin Layer wrote: > Note that git version 1.8.3.1 is quiet and does not print the > "tracking remote" message. So what you are saying is, that git v1.8.3.1 *is* quiet, but v1.7.1 is not? Sounds like a fixed bug to me. I also checked with the latest version and it did not

[PATCH v2 3/7] completion: improve bash completion for git-add

From: Cornelius Weig <cornelius.w...@tngtech.com> Command completion for git-add did not recognize some long-options. This commits adds completion for all long-options that are mentioned in the man-page synopsis. In addition, if the user specified `--update` or `-u`, path completion wil

[PATCH v2 4/7] completion: teach ls-remote to complete options

From: Cornelius Weig <cornelius.w...@tngtech.com> ls-remote needs to complete remote names and its own options. In addition to the existing remote name completions, do also complete the options --heads, --tags, --refs, --get-url, and --symref. Signed-off-by: Cornelius Weig <co

[PATCH v2 7/7] completion: recognize more long-options

From: Cornelius Weig <cornelius.w...@tngtech.com> Command completion only recognizes a subset of the available options for the various git commands. The set of recognized options needs to balance between having all useful options and to not clutter the terminal. This commit adds all long-o

[PATCH v2 0/7] completion bash: add more options and commands

From: Cornelius Weig <cornelius.w...@tngtech.com> This is the re-roll of patch series <2017015724.19360-1-cornelius.w...@tngtech.com>. This patch series adds all long-options that are mentioned in the synopsis of the man-page for the respective git-command. There are only a fe

[PATCH v2 5/7] completion: teach replace to complete options

From: Cornelius Weig <cornelius.w...@tngtech.com> Git-replace needs to complete references and its own options. In addition to the existing references completions, do also complete the options --edit --graft --format= --list --delete. Signed-off-by: Cornelius Weig <cornelius.w...@tn

[PATCH v2 6/7] completion: teach remote subcommands to complete options

From: Cornelius Weig <cornelius.w...@tngtech.com> Git-remote needs to complete remote names, its subcommands, and options thereof. In addition to the existing subcommand and remote name completion, do also complete the options - add: --track --master --fetch --tags --no-tags --mirror=

[PATCH v2 1/7] completion: teach submodule subcommands to complete options

From: Cornelius Weig <cornelius.w...@tngtech.com> Each submodule subcommand has specific long-options. Therefore, teach bash completion to support option completion based on the current subcommand. All long-options that are mentioned in the man-page synopsis are added. Signed-off-by: Cor

[PATCH v2 2/7] completion: add subcommand completion for rerere

From: Cornelius Weig <cornelius.w...@tngtech.com> Managing recorded resolutions requires command-line usage of git-rerere. Added subcommand completion for rerere and path completion for its subcommand forget. Signed-off-by: Cornelius Weig <cornelius.w...@tngtech.com> Reviewed-by:

Re: [PATCH v2 7/7] completion: recognize more long-options

On 02/02/2017 03:00 AM, SZEDER Gábor wrote: >> Personally, I agree with you that >>> Adding more long options that git commands learn along the way is >>> always an improvement. >> However, people may start complaining that their terminal becomes too >> cluttered when doing a double-Tab. In my

Re: [PATCH 4/7] completion: teach ls-remote to complete options

On 02/02/2017 02:40 AM, SZEDER Gábor wrote: > >> ls-remote needs to complete remote names and its own options. > > And refnames, too. Yes, right. However, do you think it is reasonable to complete remote refnames? I don't think so, because it would mean we would have to run ls-remote during

Re: [PATCH 2/7] completion: add subcommand completion for rerere

On 02/02/2017 01:57 AM, SZEDER Gábor wrote: > You didn't add 'rerere' to the list of porcelain commands, i.e. it > won't be listed after 'git '. I'm not saying it should be > listed there, because I can't decide whether 'rerere' is considered > porcelain or plumbing... Just wanted to make sure

Re: [PATCH] doc: add note about ignoring --no-create-reflog

> The negated form `--no-create-reflog` only overrides an earlier > `--create-reflog`, but currently does not negate the setting of > `core.logallrefupdates`. Even better than Junio's version. I especially like that it mentions where the default setting comes from.

Re: [PATCH] doc: add note about ignoring --no-create-reflog

to create a reflog caused by the setting of >> core.logallrefupdates. This corner case is quite important. Glad you thought about it! > -- >8 -- > From: Cornelius Weig <cornelius.w...@tngtech.com> > Date: Wed, 1 Feb 2017 23:07:27 +0100 > Subject: [PATCH] doc: add note about ignoring '

[PATCH 1/2] doc: add doc for git-push --recurse-submodules=only

From: Cornelius Weig <cornelius.w...@tngtech.com> Add documentation for the `--recurse-submodules=only` option of git-push. The feature was added in commit 225e8bf (add option to push only submodules). Signed-off-by: Cornelius Weig <cornelius.w...@tngtech.com> --- Notes:

[PATCH 2/2] completion: add completion for --recurse-submodules=only

From: Cornelius Weig <cornelius.w...@tngtech.com> Command completion for 'git-push --recurse-submodules' already knows to complete some modes. However, the recently added mode 'only' is missing. Adding 'only' to the recognized modes completes the list of non-trivial modes. Sign

[PATCH] doc: add note about ignoring --no-create-reflog

From: Cornelius Weig <cornelius.w...@tngtech.com> The commands git-branch and git-tag accept a `--create-reflog` argument. On the other hand, the negated form `--no-create-reflog` is accepted as a valid option but has no effect. This silent noop may puzzle users. To commu

Re: [PATCH v2 7/7] completion: recognize more long-options

Hi Gabor, thanks for taking a look at these commits. On 01/31/2017 11:17 PM, SZEDER Gábor wrote: > On Fri, Jan 27, 2017 at 10:17 PM, <cornelius.w...@tngtech.com> wrote: >> From: Cornelius Weig <cornelius.w...@tngtech.com> >> >> Recognize several new

Re: [PATCH v3 2/3] refs: add option core.logAllRefUpdates = always

On 01/31/2017 06:08 PM, Junio C Hamano wrote: > I think it is probably a good idea to document the behaviour > (i.e. "--no-create" single-shot from the command line is ignored). > I am not sure we should error out, though, in order to "disallow" > it---a documented silent no-op may be sufficient.

Re: [PATCH v3 2/3] refs: add option core.logAllRefUpdates = always

On 01/31/2017 12:37 AM, Jeff King wrote: > On Mon, Jan 30, 2017 at 01:58:10PM -0800, Junio C Hamano wrote: > >>> When writing the test for git-tag, I realized that the option >>> --no-create-reflog to git-tag does not take precedence over >>> logAllRefUpdate=always. IOW the setting

Re: [PATCH v3 2/3] refs: add option core.logAllRefUpdates = always

Hi, > The extra free(refname) is to plug the leak I pointed out, and the > type of refname is no longer const, because "const char *" cannot be > free()d without casting, and in this codepath I do not see a reason > to mark it as const. Ooops.. thanks for not yelling at me for that :-/ > When

[PATCH v2 0/7] completion: recognize more long-options

From: Cornelius Weig <cornelius.w...@tngtech.com> This revision addresses Johannes' concerns. Changes wrt v1: - fixed the commit message: two of the "dangerous" options erroneously ended up in the commit message. These options were already in the list of auto-com

[PATCH v2 7/7] completion: recognize more long-options

From: Cornelius Weig <cornelius.w...@tngtech.com> Recognize several new long-options for bash completion in the following commands: - apply: --recount --directory= - archive: --output - branch: --column --no-column --sort= --points-at - clone: --no-single-branch --shallow-subm

Re: [PATCH] doc: clarify distinction between sign-off and pgp-signing

lphabetic order. With your explanation, I guess the most accurate sign-off chain would be: Signed-off-by: Stefan Beller <sbel...@google.com> (as you sent a patch) Helped-by: Philip Oakley <philipoak...@iee.org> (no patch, but helpful) Signed-off-by: Cornelius Weig <cornelius.w...@tngtech.com&g

[PATCH] doc: clarify distinction between sign-off and pgp-signing

From: Cornelius Weig <cornelius.w...@tngtech.com> The documentation for submission discourages pgp-signing, but demands a proper sign-off by contributors. However, when skimming the headings, the wording of the section for sign-off could mistakenly be understood as concerning pgp-signing

Re: [PATCH] doc: clarify distinction between sign-off and pgp-signing

Sorry, I forgot to mark this patch as follow-up to message

Re: SubmittingPatches: drop temporal reference for PGP signing

On 01/26/2017 09:58 PM, Philip Oakley wrote: > From: "Junio C Hamano" <gits...@pobox.com> >> Cornelius Weig <cornelius.w...@tngtech.com> writes: >> >>> How about something along these lines? Does the forward reference >>> break the

[PATCH v3 1/3] config: add markup to core.logAllRefUpdates doc

From: Cornelius Weig <cornelius.w...@tngtech.com> Signed-off-by: Cornelius Weig <cornelius.w...@tngtech.com> --- Notes: Changes wrt v2: Remove duplicated line. Documentation/config.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/D

[PATCH v3 2/3] refs: add option core.logAllRefUpdates = always

From: Cornelius Weig <cornelius.w...@tngtech.com> When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) are not meant to change, and that unknown hierarchies

[PATCH v3 3/3] update-ref: add test cases for bare repository

From: Cornelius Weig <cornelius.w...@tngtech.com> The default behavior of update-ref to create reflogs differs in repositories with worktree and bare ones. The existing tests cover only the behavior of repositories with worktree. This commit adds tests that assert the correct behavior i

[PATCH v2 2/3] refs: add option core.logAllRefUpdates = always

From: Cornelius Weig <cornelius.w...@tngtech.com> When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) do not typically change, and that unknown hierarchies

[PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc

From: Cornelius Weig <cornelius.w...@tngtech.com> Signed-off-by: Cornelius Weig <cornelius.w...@tngtech.com> --- Notes: As suggested, I moved the modification of the markup to its own commit. Documentation/config.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

[PATCH v2 3/3] update-ref: add test cases for bare repository

From: Cornelius Weig <cornelius.w...@tngtech.com> The default behavior of update-ref to create reflogs differs in repositories with worktree and bare ones. The existing tests cover only the behavior of repositories with worktree. This commit adds tests that assert the correct behavior i

Re: [PATCH] refs: add option core.logAllRefUpdates = always

Hi Peff, thanks for your thoughts. > I tried to read this patch with fresh eyes. But given the history, you > may take my review with a grain of salt. :) Does it mean another reviewer is needed? > I don't think my original had tests for this, but it might be worth > adding a test for this

Re: SubmittingPatches: drop temporal reference for PGP signing

> > Yeah I agree. My patch was not the best shot by far. > How about something along these lines? Does the forward reference break the main line of thought too severly? diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 08352de..c2b0cbe 100644 ---

[PATCH] refs: add option core.logAllRefUpdates = always

Hi peff, you made it easy for me. Most of your patch still applied, only the tests didn't quite fit. Maybe you can have a look if I've overlooked something, since you know the changes best? Thanks for supporting this with your patch!

[PATCH] refs: add option core.logAllRefUpdates = always

From: Cornelius Weig <cornelius.w...@tngtech.com> When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) do not typically change, and that unknown hierarchies

Re: [PATCH] tag: add tag.createReflog option

> > It may have been obvious, but to be explicit for somebody new, > !prefixcmp() corresponds to starts_with(). IOW, we changed the > meaning of the return value when moving from cmp-lookalike (where 0 > means "equal") to "does it start with this string?" bool (where 1 > means "yes"). > I see.

Re: [PATCH] tag: add tag.createReflog option

On 01/25/2017 07:00 PM, Jeff King wrote: > - Is that the end of it, or is the desire really "I want reflogs for > _everything_"? That seems like a sane thing to want. > > If so, then the update to core.logallrefupdates should turn it into > a tri-state: > > - false; no

Re:

On 01/25/2017 01:21 AM, Stefan Beller wrote: >> >>> Do not PGP sign your patch, at least *for now*. (...) >> > > And maybe these 2 small words are the bug in the documentation? > Shall we drop the "at least for now" part, like so: > > ---8<--- > From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon

Re: [PATCH 7/7] completion: recognize more long-options

On 01/25/2017 12:43 AM, Stefan Beller wrote: > On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig > <cornelius.w...@tngtech.com> wrote: >> On 01/25/2017 12:24 AM, Junio C Hamano wrote: >>> Cornelius Weig <cornelius.w...@tngtech.com> writes: >>> &

[PATCH] tag: add tag.createReflog option

From: Cornelius Weig <cornelius.w...@tngtech.com> Git does not create a history for tags, in contrast to common expectation to simply version everything. This can be changed by using the `--create-reflog` flag when creating the tag. However, a config option to enable this behavior by d

Re: [PATCH 7/7] completion: recognize more long-options

On 01/25/2017 12:24 AM, Junio C Hamano wrote: > Cornelius Weig <cornelius.w...@tngtech.com> writes: > >>> Please study item (5) "Sign your work" in >>> Documentation/SubmittingPatches and sign off your work. >> >> I followed the recommend

Re: [PATCH 7/7] completion: recognize more long-options

On 01/24/2017 08:15 AM, Johannes Sixt wrote: > If at all possible, please use your real email address as the From > address. It is pointless to hide behind a fake address because as Git > contributor you will have to reveal your identity anyway. These are both real addresses, but for send-mail I