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 __git_complete_index_file() and Bash's
er one has 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, wrote:
>> From: Cornelius Weig
>> Note that one corner-case is not covered by t
On 02/14/2017 10:31 PM, Junio C Hamano wrote:
> cornelius.w...@tngtech.com writes:
>
>> From: Cornelius Weig
>>
>> Git-checkout completes words starting with '--' as options and other
>> words as refs. Even after specifying a ref, further words not sta
From: Cornelius Weig
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 after specifyin
From: Cornelius Weig
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 revision is specified elsewher
On 02/14/2017 01:50 AM, SZEDER Gábor wrote:
> On Tue, Feb 14, 2017 at 12:33 AM, wrote:
>> From: Cornelius Weig
>>
>> The command line completion for git-checkout bails out when seeing '--'
>> as an isolated argument. For git-checkout this signifies the sta
From: Cornelius Weig
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 files, therefore completion ca
From: Cornelius Weig
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, pull) also complete remote names and
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 'update'
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. But if you do
> use
From: Cornelius Weig
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 example:
6e3a7b3 refs/ta
On 02/08/2017 10:28 PM, Junio C Hamano wrote:
> cornelius.w...@tngtech.com writes:
>
>> From: Cornelius Weig
>>
>> When tags are created with `--create-reflog` or with the option
>> `core.logAllRefUpdates` set to 'always', a reflog is created for th
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
+++ b/Documentation/glossary-content.t
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 +387,
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 .gitattributes
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
`cle
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 th
From: Cornelius Weig
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 of unknown type like
> th
From: Cornelius Weig
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 example:
6e3a7b3 refs/ta
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 this
From: Cornelius Weig
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 example:
6e3a7b3 refs/ta
From: Cornelius Weig
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 example:
"6e3a7b3 re
From: Cornelius Weig
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 example:
"6e
Shouldn't this be part of v2.12-rc0? I just checked but it's not there.
Cheers,
Cornelius
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
From: Cornelius Weig
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 will only suggest modified tracked files
From: Cornelius Weig
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
Reviewed-by: SZEDER Gábor
---
contrib
From: Cornelius Weig
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-options that are mentioned in the
From: Cornelius Weig
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 few exceptions,
as discussed in the
From: Cornelius Weig
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
Reviewed-by: SZEDER Gábor
---
contrib/completion/git
From: Cornelius Weig
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=
- set-url: --push --add --delete
From: Cornelius Weig
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: Cornelius Weig
Reviewed-by: SZEDER
From: Cornelius Weig
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
Reviewed-by: SZEDER Gábor
---
contrib/completion/git-completion.bash | 11
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 cove
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 co
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
> 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.
the setting of
>> core.logallrefupdates.
This corner case is quite important. Glad you thought about it!
> -- >8 --
> From: Cornelius Weig
> Date: Wed, 1 Feb 2017 23:07:27 +0100
> Subject: [PATCH] doc: add note about ignoring '--no-create-reflog'
>
> The comma
From: Cornelius Weig
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
---
Notes:
This feature is already in 'next' but was undocumented. Unles
From: Cornelius Weig
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.
Signed-off-by
From: Cornelius Weig
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 communicate that this behavior is intentional, add a
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, wrote:
>> From: Cornelius Weig
>>
>> Recognize several new long-options for bash completion in the following
>> commands:
>
&
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.
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 can
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 qu
From: Cornelius Weig
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-completable options.
- removed the pos
From: Cornelius Weig
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-submodules
- commit: --patch --short --date
ssion in alphabetic order.
With your explanation, I guess the most accurate sign-off chain would be:
Signed-off-by: Stefan Beller (as you sent a patch)
Helped-by: Philip Oakley (no patch, but helpful)
Signed-off-by: Cornelius Weig (this patch)
Signed-off-by: Junio C Hamano (once he decides it's good)
From: Cornelius Weig
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. Thus, new contributors could
Sorry, I forgot to mark this patch as follow-up to message
On 01/26/2017 09:58 PM, Philip Oakley wrote:
> From: "Junio C Hamano"
>> Cornelius Weig writes:
>>
>>> How about something along these lines? Does the forward reference
>>> break the main line of thought too severly?
>>
>> I find
From: Cornelius Weig
Signed-off-by: Cornelius Weig
---
Notes:
Changes wrt v2:
Remove duplicated line.
Documentation/config.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index af2ae4c..c7d8a01
From: Cornelius Weig
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 might not want reflogs at all (e.g
From: Cornelius Weig
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 in bare
repositories for update-ref
From: Cornelius Weig
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 might not want reflogs at all (e.g
From: Cornelius Weig
Signed-off-by: Cornelius Weig
---
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(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
From: Cornelius Weig
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 in bare
repositories for update-ref
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 last
>
> 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
--- a/Documentat
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!
From: Cornelius Weig
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 might not want reflogs at all (e.g
>
> 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.
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 reflog
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 S
On 01/25/2017 12:43 AM, Stefan Beller wrote:
> On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig
> wrote:
>> On 01/25/2017 12:24 AM, Junio C Hamano wrote:
>>> Cornelius Weig writes:
>>>
>>>>> Please study item (5) "Sign your work" in
>&
From: Cornelius Weig
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 default is missing.
This commit adds
On 01/25/2017 12:24 AM, Junio C Hamano wrote:
> Cornelius Weig writes:
>
>>> Please study item (5) "Sign your work" in
>>> Documentation/SubmittingPatches and sign off your work.
>>
>> I followed the recommendations to submitting work, and in the fi
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 w
68 matches
Mail list logo
