The new help option --config-for-completion is a machine friendlier
version of --config where all the placeholders and wildcards are
dropped, leaving only the good, completable prefixes for
git-completion.bash to consume.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/help.c
The only benefit from this move (apart from cleaner code) is that
advice.amWorkDir should now show up in `git help --config`. There
should be no regression since advice config is always read by the
git_default_config().
While at there, use advise() like other code. We now get "hint: "
prefix and
This array will be used by some other function than parse_msg_id() in
the following commit. Factor out this prep code so it could be called
from that one.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fsck.c | 38 ++
1 file changed, 22
Instead of hard coding the name-to-id mapping in C code, keep it in an
array and use a common function to do the parsing. This reduces code
and also allows us to list all possible color slots later.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 28
After performing a merge that has conflicts, git status will by default attempt
to detect renames which causes many objects to be examined. In a virtualized
repo, those objects do not exist locally so the rename logic triggers them to be
fetched from the server. This results in the status call
You found the problem Phillip! My editor was trimming trailing white space,
which breaks the context line.
I had tried to use an alternative editor to account for any editor specific
behaviour, but it turns out both the editors I tested in were doing this!
I suspect this change in behaviour
b2dc968e60 (t5516: refactor oddball tests, 2008-11-07) accidentaly
broke the &&-chain in the test 'push does not update local refs on
failure', but since it was in a subshell, chain-lint couldn't notice
it.
Signed-off-by: SZEDER Gábor
---
t/t5516-fetch-push.sh | 2 +-
1
In a while-at-it cleanup replacing a 'cd dir && <...> && cd ..' with a
subshell, commit 28391a80a9 (receive-pack: allow deletion of corrupt
refs, 2007-11-29) also moved the assignment of the $old_commit
variable to that subshell. This variable, however, is used outside of
that subshell as a
The two JGit tests 'we can read jgit bitmaps' and 'jgit can read our
bitmaps' in 't5310-pack-bitmaps.sh' fail when run with
GIT_TEST_SPLIT_INDEX=YesPlease. Both tests create a clone of the test
repository to check bitmap interoperability with JGit. With split
indexes enabled the index in the
On 10 May 2018 at 15:16, Oliver Joseph Ash wrote:
> (Apologies, I accidentally sent this as a reply to the original post, instead
> of your email. I'm new to this!)
(No worries.) ;-)
>> does your test involve unusual file systems, funny characters in filenames,
>> ..?
On 10/05/18 13:17, Martin Ågren wrote:
>
> On 10 May 2018 at 12:41, Oliver Joseph Ash wrote:
>> I just ran into a similar problem:
>> https://stackoverflow.com/questions/50258565/git-editing-hunks-fails-when-file-has-other-hunks
>>
>> I can reproduce on 2.17.0. The issue
(Apologies, I accidentally sent this as a reply to the original post, instead
of your email. I'm new to this!)
> does your test involve unusual file systems, funny characters in filenames,
> ..? You are on some sort of Linux, right?
I'm running macOS 10.13.4. I don't have any unusual file
> does your test involve unusual file systems, funny characters in filenames,
> ..? You are on some sort of Linux, right?
I'm running macOS 10.13.4. I don't have any unusual file system setup, as far
as I'm aware. The filename in my test case is simply `foo`.
I tried the steps you suggested:
On 10 May 2018 at 14:43, Ævar Arnfjörð Bjarmason wrote:
> The SHA1 prefix 06fa currently matches no blobs in git.git. When
> disambiguating short SHA1s we've been quietly ignoring the user's type
> selector as a fallback mechanism, this was intentionally added in
> 1ffa26c461
On 5/10/2018 3:00 AM, Junio C Hamano wrote:
Derrick Stolee writes:
We use the lockfile API to avoid multiple Git processes from writing to
the commit-graph file in the .git/objects/info directory. In some cases,
this directory may not exist, so we check for its
The arguments weren't lined up with the opening parenthesis. Fixes up
code added in aae0caf19e ("sha1-array.h: align function arguments",
2018-04-30).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-array.c | 4 ++--
sha1-array.h | 4 ++--
2 files changed, 4 insertions(+), 4
The SHA1 prefix 06fa currently matches no blobs in git.git. When
disambiguating short SHA1s we've been quietly ignoring the user's type
selector as a fallback mechanism, this was intentionally added in
1ffa26c461 ("get_short_sha1: list ambiguous objects on error",
2016-09-26).
I think that
This stray newline was accidentally introduced in
d2b7d9c7ed ("sha1_name: convert disambiguate_hint_fn to take
object_id", 2017-03-26).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-name.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sha1-name.c b/sha1-name.c
index
A subsequent change will make use of this static function in the
get_short_oid() function, which is defined above where the
collect_ambiguous() function is now. Without this we'd then have a
compilation error due to a forward declaration.
Signed-off-by: Ævar Arnfjörð Bjarmason
This was the only occurrence of "commitish" in the tree, but as the
log will reveal we've had others in the past. Fixes up code added in
00ad6e3182 ("git-p4: work with a detached head", 2015-11-21).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
git-p4.py | 6 +++---
1 file
This is like v3 except all the patches to the peel syntax & docs have
been dropped, which were controversial.
I think it's worthwhile to re-work that, but I don't have time for
that now, so I'm submitting this. Maybe I'll have time in the future
to re-work the rest, but then I can base it on top
Change the output emitted when an ambiguous object is encountered so
that we show tags first, then commits, followed by trees, and finally
blobs. Within each type we show objects in hashcmp() order. Before
this change the objects were only ordered by hashcmp().
The reason for doing this is that
On 10 May 2018 at 12:41, Oliver Joseph Ash wrote:
> I just ran into a similar problem:
> https://stackoverflow.com/questions/50258565/git-editing-hunks-fails-when-file-has-other-hunks
>
> I can reproduce on 2.17.0. The issue doesn't occur on 2.16.2, however.
>
> Is this a
On Thu, May 10, 2018 at 07:23:13PM +0900, Junio C Hamano wrote:
> This one was doing
>
> ptr = xmalloc(sizeof(*another_ptr))
>
> and it was OK because ptr and another_ptr happened to be of the same
> type. I wonder if we are making it safer, or making it more obscure
> to seasoned C
Hi,
I am writing with the hope of talking to the appropriate person who handles the
app's monetization.
If it makes sense to have a call, let me know how your schedule looks.
Best Regards,
--
Michal Sapozhnikov | Business Manager, Luminati SDK | +972-50-2826778 | Skype:
live:michals_43
René Scharfe writes:
> The standard says about uintptr_t that "any valid pointer to void can
> be converted to this type, then converted back to pointer to void, and
> the result will compare equal to the original pointer". So void * ->
> uintptr_t -> void * is a proper roundtrip,
I just ran into a similar problem:
https://stackoverflow.com/questions/50258565/git-editing-hunks-fails-when-file-has-other-hunks
I can reproduce on 2.17.0. The issue doesn't occur on 2.16.2, however.
Is this a bug?
Stefan Beller writes:
> This was missed in 5982da9d2ce (replace-object: allow
> prepare_replace_object to handle arbitrary repositories, 2018-04-11)
>
> Technically the code works correctly as the replace_map is the same
> size in different repositories, however it is hard to
Stefan Beller writes:
> The replace map for objects was missed to free in the object store in
> the conversion of 174774cd519 (Merge branch 'sb/object-store-replace',
> 2018-05-08)
I need a bit of clarification wrt the above. The above makes it
sound like the merge needed a
Complete the --color-moved option wherever we complete --diff-algorithm.
Signed-off-by: John Marshall
---
Complete this recently-added option in a slightly over-the-top number of
places. Patch based on the maint branch.
Cheers,
John
Luis Marsano writes:
> git-credential-netrc was hardcoded to decrypt with 'gpg' regardless of the
> gpg.program option
> this now uses the gpg command option if set, else, the gpg.program option set
> in the git repository or global configuration, else defaults to 'gpg'
Luis Marsano writes:
> until this change, git-credential-netrc did not test in a repository
> this change reuses the main test framework, which provides such tests
> specific changes
Sorry, but I cannot quite parse what the above is trying to say.
> - switch to
Stefan Beller writes:
> So this would go with the latest sb/object-store-alloc ?
>
> My impression was that we never call repo_clear() on
> the_repository, which would allow us to special case
> the_repository further just as I did in v2 of that series[1] by
> having static
Am 09.05.2018 um 23:06 schrieb René Scharfe:
> Clang 6 reports the following warning, which is turned into an error in a
> DEVELOPER build:
>
> builtin/fast-export.c:162:28: error: performing pointer arithmetic on a
> null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]
This lists all recognized commands [1] by category. The group order
follows closely git.txt.
[1] We may actually show commands that are not built (e.g. if you set
NO_PERL you don't have git-instaweb but it's still listed here). I
ignore the problem because on Linux a git package could be split
This is intended to help anybody who needs to update command-list.txt.
It gives a brief introduction of all attributes a command can take.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
command-list.txt | 44
1 file changed, 44
Instead of parsing "git help -a" output, which is tricky to get right,
less elegant and also slow, make git provide the list in a
machine-friendly form. This adds two separate listing types, main and
others, instead of just "all" for more flexibility.
Signed-off-by: Nguyễn Thái Ngọc Duy
Even if these are hidden options, let's make them a bit more generic
since we're introducing more listing types shortly. The code is
structured to allow combining multiple listing types together because
we will soon add more types the 'builtins'.
'parseopt' remains separate because it has
Instead of printing the command directly one by one, keep them in a
list and print at the end. This allows more modification before we
print out (e.g. sorting, removing duplicates or even excluding some
items).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
git.c | 22
This allows us to select any group of commands by a category defined
in command-list.txt. This is an internal/hidden option so we don't
have to be picky about the category name or worried about exposing too
much.
This will be used later by git-completion.bash to retrieve certain
command groups.
The previous commit added code generation for all_cmd_desc[] which
includes almost everything we need to generate common command list.
Convert help code to use that array instead and drop common_cmds[] array.
The description of each common command group is removed from
command-list.txt. This
After the last patch, common-cmds.h is no longer used (and it was
actually broken). Remove all related code. command-list.h will take
its place from now on.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
.gitignore | 1 -
Makefile| 17 ++---
The current generate-cmds.sh generates just enough to print "git help"
output. That is, it only extracts help text for common commands.
The script is now updated to extract help text for all commands and
keep command classification a new file, command-list.h. This will be
useful later:
- "git
Instead of maintaining a separate list of command classification,
which often could go out of date, let's centralize the information
back in git.
While the function in git-completion.bash implies "list porcelain
commands", that's not exactly what it does. It gets all commands (aka
The help command currently hard codes the list of guides and their
summary in C. Let's move this list to command-list.txt. This lets us
extract summary lines from Documentation/git*.txt. This also
potentially lets us list guides in git.txt, but I'll leave that for
now.
Signed-off-by: Nguyễn Thái
By default we show porcelain, external commands and a couple others
that are also popular. If you are not happy with this list, you can
now customize it. See the big comment block for details.
PS. perhaps I should make aliases a group too, which makes it possible
to _not_ complete aliases by
v7 is mostly code cleanup plus one more change:
git-completion.bash now always checks completion.commands config key.
This makes it much more convenient to customize the command complete
list. You only have to fall back to setting $GIT_COMPLETION_CMD_GROUPS
when you have very special needs.
This makes it easier to reuse the same code in another place (very
soon).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
generate-cmdlist.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index
On 10 May 2018 at 08:01, Junio C Hamano wrote:
> Jeff King writes:
>
>> I don't think it's worth re-rolling, but one thing to think about for
>> future cleanups: you split the patches by touched area, not by
>> functionality. So the first three patches have a
On Wed, Apr 18, 2018 at 01:24:55PM +0900, Junio C Hamano wrote:
> Martin Ågren writes:
>
> > This is a patch series to convert \-- to -- in our documentation. The
> > first patch is a reiteration of 1c262bb7b2 (doc: convert \--option to
> > --option, 2015-05-13) to fix
Derrick Stolee writes:
> We use the lockfile API to avoid multiple Git processes from writing to
> the commit-graph file in the .git/objects/info directory. In some cases,
> this directory may not exist, so we check for its existence.
>
> The existing code does the
On Thu, May 10, 2018 at 01:21:19PM +0900, Junio C Hamano wrote:
> When diagnosing such an error, we would give hints. The hint would
> show possible objects that the user could have meant with X. The
> ^{} suffix given to it may be used to limit the hints to
> subset of the objects that the
René Scharfe writes:
> Am 10.05.2018 um 02:04 schrieb Junio C Hamano:
> ...
>> $ git grep -v second
>> $ git grep --not -e second
>>
>> may hit all lines in this message (except for the obvious two
>> lines), but we cannot say which column we found a hit. I am
>>
On Wed, May 09, 2018 at 07:00:10PM -0700, Taylor Blau wrote:
> > - they test with context (-C3) for us. It looks like GNU grep omits
> >context lines with "-o", but we show a bunch of blank lines. This is
> >I guess a bug (though it seems kind of an odd combination to specify
> >in
Stefan Beller writes:
> +static void runcommand_in_submodule_cb(const struct cache_entry *list_item,
> +void *cb_data)
> +{
> + struct cb_foreach *info = cb_data;
> + const char *path = list_item->name;
> + const struct
On Wed, May 9, 2018 at 8:00 PM, Duy Nguyen wrote:
> discard_index(repo->index);
> if (repo->index != _index)
> FREE_AND_NULL(repo->index);
>
>> What is your use case of repo_clear(the_repository)?
>
> No actual use case right now. See [1] for the code that triggered
>
the_repository is special. One of the special things about it is that
it does not allocate a new index_state object like submodules but
points to the global the_index variable instead. As a global variable,
the_index cannot be free()'d.
Add an exception for this in repo_clear(). In the future
Jeff King writes:
> I don't think it's worth re-rolling, but one thing to think about for
> future cleanups: you split the patches by touched area, not by
> functionality. So the first three patches have a "while we're here..."
> that has to explain why dropping the "static" is
101 - 158 of 158 matches
Mail list logo