Hi!
Thanks for that. It sounds plausible, but I wonder why it works automagically
for C, but not for Java (Politcal reasons put aside): Using ".c" for C is about
as common as using ".java" for Java ;-)
Regards,
Ulrich
>>> Alban Gruin schrieb am 25.04.2018 um 17:05 in
Nachricht
:
> Le 25/04/2018
Junio C Hamano writes:
>> - Rebased the patch series on top of current `master`, i.e. both
>> `pw/rebase-keep-empty-fixes` and `pw/rebase-signoff`, to resolve merge
>> conflicts myself.
>
> Good to see the last item, as this gave me a chance to make sure
> that the conflict resolution I've be
On Thu, Apr 26, 2018 at 02:32:54PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > diff --git a/builtin/config.c b/builtin/config.c
> > index d7acf912cd..ec5c11293b 100644
> > --- a/builtin/config.c
> > +++ b/builtin/config.c
> > @@ -61,6 +61,7 @@ static int show_origin;
> > #define TYPE
On Thu, Apr 26, 2018 at 02:25:44PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > Subject: Re: [PATCH 2/5] builtin/config.c: support `--type=` as
> > preferred alias for `--type`
>
> I'd retitle while queuing, as the last 'type' is a placeholder for
> concrete types like above.
Good i
As of this commit, the canonical way to retreive an ANSI-compatible
color escape sequence from a configuration file is with the
`--get-color` action.
This is to allow Git to "fall back" on a default value for the color
should the given section not exist in the specified configuration(s).
With the
Hi,
Here is an amended version of my combined series to add '--type' and
'--default'. My apologies for the re-roll, I thought that I had looked
everything over closely enough :-).
Since last time:
* Correct an obviously-wrong assignment into '*to_type' [1]. I have
moved both of these assig
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functio
In preparation for adding `--type=color` to the `git-config(1)` builtin,
let's introduce a color parsing utility, `git_config_color` in a similar
fashion to `git_config_`.
Signed-off-by: Taylor Blau
---
config.c | 10 ++
config.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/co
Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will n
For some use cases, callers of the `git-config(1)` builtin would like to
fallback to default values when the variable asked for does not exist.
In addition, users would like to use existing type specifiers to ensure
that values are parsed correctly when they do exist in the
configuration.
For exam
Taylor Blau writes:
> diff --git a/builtin/config.c b/builtin/config.c
> index d7acf912cd..ec5c11293b 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -61,6 +61,7 @@ static int show_origin;
> #define TYPE_BOOL_OR_INT 3
> #define TYPE_PATH4
> #define TYPE_EXPIRY_DAT
Taylor Blau writes:
> Subject: Re: [PATCH 2/5] builtin/config.c: support `--type=` as
> preferred alias for `--type`
I'd retitle while queuing, as the last 'type' is a placeholder for
concrete types like above.
> +static int option_parse_type(const struct option *opt, const char *arg,
> +
Elijah Newren writes:
> On Wed, Apr 25, 2018 at 1:37 AM, Junio C Hamano wrote:
>
>> * en/unpack-trees-split-index-fix (2018-04-24) 1 commit
>> * en/rename-directory-detection-reboot (2018-04-25) 36 commits
> ...
> Would you still like a re-roll?
Not really. We can just merge them together and
Hi,
Attached is a combination of my two series to add [--type=] and
[--default=] to 'git-config(1)'.
I have not changed anything in these patches since their last review in
[1], [2], other than to:
* Ensure that they merge cleanly into 'master' and,
* Incorporate the patch that I sent to Ju
In preparation for adding `--type=color` to the `git-config(1)` builtin,
let's introduce a color parsing utility, `git_config_color` in a similar
fashion to `git_config_`.
Signed-off-by: Taylor Blau
---
config.c | 10 ++
config.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/co
As of this commit, the canonical way to retreive an ANSI-compatible
color escape sequence from a configuration file is with the
`--get-color` action.
This is to allow Git to "fall back" on a default value for the color
should the given section not exist in the specified configuration(s).
With the
For some use cases, callers of the `git-config(1)` builtin would like to
fallback to default values when the variable asked for does not exist.
In addition, users would like to use existing type specifiers to ensure
that values are parsed correctly when they do exist in the
configuration.
For exam
Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will n
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functio
Johannes Schindelin writes:
> -if (export_object(&old_oid, type, raw, tmpfile))
> -return -1;
> -if (launch_editor(tmpfile, NULL, NULL) < 0)
> -return error("editing object file failed");
> -if (import_object(&new_oid, type, raw, tmpfile))
> +tmpfile
Johannes Schindelin writes:
> Changes since v8:
>
> - Disentangled the patch introducing `label`/`reset` from the one
> introducing `merge` again (this was one stupid, tired `git commit
> --amend` too many).
>
> - Augmented the commit message of "introduce the `merge` command" to
> describe
Derrick Stolee writes:
> Define compare_commits_by_gen_then_commit_date(), which uses generation
> numbers as a primary comparison and commit date to break ties (or as a
> comparison when both commits do not have computed generation numbers).
>
> Since the commit-graph file is closed under reacha
Derrick Stolee writes:
> @@ -439,6 +439,9 @@ static void write_graph_chunk_data(struct hashfile *f,
> int hash_len,
> else
> packedDate[0] = 0;
>
> + if ((*list)->generation != GENERATION_NUMBER_INFINITY)
> + packedDate[0] |=
SZEDER Gábor writes:
> These new tests, however, are primarily interested in the inner
> workings of __git_complete_index_file() in the presence of escapes
> and/or quotes in the path to be completed and/or in the output of 'git
> ls-files'. For these kind of tests we could simply invoke
> __git
Johannes Schindelin writes:
>> ...
>>
>> There is also a handy shortcut of GIT_DEBUGGER=1 meaning the same as
>> GIT_DEBUGGER="gdb --args"
>>
>> Original-patch-by: Johannes Schindelin
>> Signed-off-by: Elijah Newren
>
> Looks good to me!
> Dscho
Thanks, both.
Ben Peart writes:
> To be clear, this documentation change isn't trying to document any
> changes to the code or behavior - it is just an attempt to clarify
> what the existing behavior is.
Yeah, I know, and I do think the new text is a good first step in
the right direction; I merely was trying
Marc Branchaud writes:
>> But Git is not an archiver (tar), but is a source code control
>> system, so I do not think we should spend any extra cycles to
>> "improve" its behaviour wrt the relative ordering, at least for the
>> default case. Only those who rely on having build artifact *and*
>>
On Wed, Apr 25, 2018 at 05:37:52PM +0900, Junio C Hamano wrote:
> * bc/object-id (2018-04-24) 41 commits
> - merge-one-file: compute empty blob object ID
> - add--interactive: compute the empty tree value
> - Update shell scripts to compute empty tree object ID
> - sha1_file: only expose empty
On Wed, Apr 18, 2018 at 3:22 AM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>>> Do we want to test a more common case of a filename that is two
>>> words with SP in between, i.e.
>>>
>>> $ >'hello world' && git add hel
>>>
>>> or is it known to work just fine without quoting/escaping (b
On Wed, 25 Apr 2018 11:20:57 -0700
Stefan Beller wrote:
> v3:
> * fixed and extended the commit message of last commit
> * fixed the last patch, as Jonathan Tan suggested, see interdiff:
Thanks, all my comments have been addressed.
Reviewed-by: Jonathan Tan
On Wed, Apr 25, 2018 at 11:18:26AM -0400, Marc Branchaud wrote:
> > The best approach to do so is to have those people do the "touch"
> > thing in their own post-checkout hook. People who use Git as the
> > source control system won't have to pay runtime cost of doing the
> > touch thing, and we d
Am 25.04.2018 um 11:21 schrieb Phillip Wood:
On 24/04/18 17:59, Johannes Sixt wrote:
In modern setups, less, the pager, uses alternate screen to show
the content. When it is closed, it switches back to the original
screen, and all content is gone.
Are you setting LESS explicitly in the enviro
Am 25.04.2018 um 09:41 schrieb Johannes Schindelin:
Hi Hannes,
On Wed, 25 Apr 2018, Johannes Sixt wrote:
Am 25.04.2018 um 02:05 schrieb Junio C Hamano:
Johannes Sixt writes:
It is not uncommon to request that the output remains visible in
the terminal.
I ran `git log` and then hit `q`, an
On 25 April 2018 at 01:51, brian m. carlson
wrote:
> On Tue, Apr 24, 2018 at 11:50:16AM +0200, Martin Ågren wrote:
>> On 24 April 2018 at 01:39, brian m. carlson
>> wrote:
>> > The code for reading certain pack v2 offsets had a hard-coded 5
>> > representing the number of uint32_t words that we n
On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy
wrote:
> Later on we may support non-overlapping command groups to
> --list-cmds. Allow the user to execute just one "git" process and get
> multiple groups. This may matter for git-completion.bash on Windows
> because we don't want the user t
Add a repository argument to allow the callers of unpack_entry
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to catch call
Add a repository argument to allow the callers of cache_or_unpack_entry
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to c
Add a repository argument to allow the callers of packed_to_object_type
to be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to c
From: Jonathan Nieder
Add a repository argument to allow callers of packed_object_info to be
more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits,
On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy
wrote:
> 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 lists guide
Add a repository argument to allow the callers of oid_object_info
to be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to catch c
This involves also adapting oid_object_info_extended and a some
internal functions that are used to implement these. It all has to
happen in one patch, because of a single recursive chain of calls visits
all these functions.
oid_object_info_extended is also used in partial clones, which allow
fetc
Add a repository argument to allow the callers of read_object
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to catch calle
Add a repository argument to allow the callers of retry_bad_packed_offset
to be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to
v3:
* fixed and extended the commit message of last commit
* fixed the last patch, as Jonathan Tan suggested, see interdiff:
$ git diff remotes/origin/sb/oid-object-info (which is v2)
diff --git c/sha1_file.c w/sha1_file.c
index 94123e0299..dcd6b879ac 100644
--- c/sha1_file.c
+
Add a repository argument to allow oid_object_info_extended callers
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
Signed-off-by: Stefan Beller
---
builtin/cat-fil
On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy
wrote:
> 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 b
On Wed, Apr 25, 2018 at 7:59 PM Eric Sunshine
wrote:
> On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy
> wrote:
> > This makes it easier to reuse the same code in another place (very
> > soon).
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
> > diff --git a/generate-cmdlist.sh b/gen
On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy
wrote:
> 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 classific
On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy
wrote:
> This makes it easier to reuse the same code in another place (very
> soon).
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
> @@ -1,5 +1,17 @@
> +get_synopsis () {
> + loca
On 04/25, Ævar Arnfjörð Bjarmason wrote:
> > * bw/protocol-v2 (2018-03-15) 35 commits
> > (merged to 'next' on 2018-04-11 at 23ee234a2c)
> > + remote-curl: don't request v2 when pushing
> > + remote-curl: implement stateless-connect command
> > + http: eliminate "# service" line when using pro
On 25.04.18 02:32, Lev wrote:
> Hi list,
>
>
> I'm struggling with git connecting to Github.
>
> The problem might be SSL/TLS related.
>
> https://githubengineering.com/crypto-removal-notice/
>
> I suspect that my setup still uses tlsv1 or tlsv1.1.
>
> I've tried to explicitly set git to use
On 25/04/18 13:48, Johannes Schindelin wrote:
Hi Phillip,
On Mon, 23 Apr 2018, Phillip Wood wrote:
On 23/04/18 19:11, Stefan Beller wrote:
On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin
wrote:
Eric Sunshine pointed out that I had such a commit message in
https://public-inbox.org/git
Even if these are hidden options, let's make them a bit more generic
since we're introducing more listing types shortly.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 2 +-
git.c | 12 +++-
t/t0012-help.sh
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
any
This category, combined with 'external' and 'mainporcelain', is
intended to replace the "porcelain command list" in git-completion.bash.
In other words, these are the commands that will show up by default
when you type "git ".
Compared to the current list in git-completion.bash (which is
basically
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 lists guides in git.txt, but I'll leave that for
now.
Signed-off-by: Nguyễn Thái
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 ++---
generate-cmdlist.sh | 46 ++
Instead of maintaining a separate list of command classification,
which often could go out of date, let's centralize the information
back in git.
Note that the current completion script incorrectly classifies
filter-branch as porcelain and t9902 tests this behavior. We keep it
this way in t9902 be
Later on we may support non-overlapping command groups to
--list-cmds. Allow the user to execute just one "git" process and get
multiple groups. This may matter for git-completion.bash on Windows
because we don't want the user to way for long when TAB-ing and
Windows is slow on launching new proces
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 hel
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.
S
Instead of parsing "git help -a" output, which is tricky to get right,
less elegant and also slow, make git provide the list in
machine-friendly form.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 2 +-
git.c | 2 ++
help.c
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 keeps
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 | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index eeea4b67ea..17d6809ef5 1
This is not exactly v4 and likely broken. But I've made several
debatable changes and would like your opinions before making even more
changes in this direction.
In 03/12 I made a format change in command-list.txt. The group
description is no longer in this file but in help.c instead. This
simplif
Hi Junio,
On Wed, Apr 25, 2018 at 1:37 AM, Junio C Hamano wrote:
> * en/unpack-trees-split-index-fix (2018-04-24) 1 commit
> - unpack_trees: fix breakage when o->src_index != o->dst_index
>
> The split-index feature had a long-standing and dormant bug in
> certain use of the in-core merge mac
When passing an option '--foo' that it does not recognize, the
aggregate.perl script should die with an helpful error message
like:
Unknown option: foo
./aggregate.perl [options] [--] [...] [--] \
[...] >
Options:
--codespeed * Format output for Codespeed
--reponame * Send
On Tue, Apr 24, 2018 at 1:31 PM, Ben Peart wrote:
> On 4/24/2018 2:59 PM, Elijah Newren wrote:
>> On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart
>> wrote:
>>>
>>> diff --git a/builtin/merge.c b/builtin/merge.c
>>> index 8746c5e3e8..3be52cd316 100644
>>> --- a/builtin/merge.c
>>> +++ b/builtin/merge.
On 4/24/2018 8:13 PM, Junio C Hamano wrote:
Ben Peart writes:
diff.renameLimit::
The number of files to consider when performing the copy/rename
- detection; equivalent to the 'git diff' option `-l`.
+ detection; equivalent to the 'git diff' option `-l`. This setting
+
On 2018-04-25 04:48 AM, Junio C Hamano wrote:
"Robin H. Johnson" writes:
In the thread from 6 years ago, you asked about tar's behavior for
mtimes. 'tar xf' restores mtimes from the tar archive, so relative
ordering after restore would be the same, and would only rebuild if the
original source
On Tue, Apr 24, 2018 at 2:46 AM, Stefan Beller wrote:
> Hi Git community,
>
> This year we'll participate once again in Google Summer or Code!
> We'll have 3 students and 3 mentors, which is more than in recent years.
>
> Paul-Sebastian Ungureanu mentored by DScho, wants to convert git-stash
> int
Le 25/04/2018 à 14:53, Ulrich Windl a écrit :
> Hi!
>
> This is for git 2.13.6, and it may be an FAQ or frequent feature request.
> Anyway:
> I'm new to Java, and writing my first project using Git, I found that "git
> diff" only reports the class in the diff context, but not the method (as seen
Le 23/04/2018 à 23:01, Stefan Beller a écrit :
> Hi Git community,
>
> This year we'll participate once again in Google Summer or Code!
> We'll have 3 students and 3 mentors, which is more than in recent years.
>
> Paul-Sebastian Ungureanu mentored by DScho, wants to convert git-stash
> into a bu
On 4/24/2018 7:57 PM, Junio C Hamano wrote:
Ben Peart writes:
That said, it makes sense to me to do
this when rename detection is turned off. In fact, I think you'd
automatically want to set aggressive to true whenever rename detection
is turned off (whether by your merge.renames option or
On Wed, Apr 25, 2018 at 3:46 PM, SZEDER Gábor wrote:
> On Tue, Apr 24, 2018 at 6:17 PM, Duy Nguyen wrote:
>> On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen wrote:
>>> git-completion.bash will be updated to ask git "give me the commands
>>> in the mainporcelain, completable or external category". Th
On Mon, Apr 23, 2018 at 5:12 PM, SZEDER Gábor wrote:
> On Thu, Apr 19, 2018 at 9:07 PM, Florian Gamböck wrote:
>> On 2018-04-18 21:51, SZEDER Gábor wrote:
>>> I believe the main bash-completion repository can be found at:
>>>
>>> https://github.com/scop/bash-completion.git
>>>
>>> This repositor
As promised, here is the diff from v3.
Thanks,
-Stolee
-- >8 --
diff --git a/builtin/merge.c b/builtin/merge.c
index 7e1da6c6ea..b819756946 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1148,6 +1148,7 @@ int cmd_merge(int argc, const char **argv, const
char *prefix)
branch = b
On Wed, Apr 25, 2018 at 3:06 PM, SZEDER Gábor wrote:
>> -__git_list_all_commands ()
>
>> -__git_list_porcelain_commands ()
>
> Users can have their own completion scriptlets for their own git
> commands, and these should be able to rely on helper functions in
> git-completion.bash to do things lik
Now that we use generation numbers from the commit-graph, we must
ensure that all commits that exist in the commit-graph are loaded
from that file instead of from the object database. Since the
commit-graph file is only checked if core.commitGraph is true, we
must check the default config before we
We now calculate generation numbers in the commit-graph file and use
them in paint_down_to_common().
Expand the section on generation numbers to discuss how the three
special generation numbers GENERATION_NUMBER_INFINITY, _ZERO, and
_MAX interact with other generation numbers.
Signed-off-by: Derr
Define compare_commits_by_gen_then_commit_date(), which uses generation
numbers as a primary comparison and commit date to break ties (or as a
comparison when both commits do not have computed generation numbers).
Since the commit-graph file is closed under reachability, we know that
all commits i
The containment algorithm for 'git branch --contains' is different
from that for 'git tag --contains' in that it uses is_descendant_of()
instead of contains_tag_algo(). The expensive portion of the branch
algorithm is computing merge bases.
When a commit-graph file exists with generation numbers c
Most code paths load commits using lookup_commit() and then
parse_commit(). In some cases, including some branch lookups, the commit
is parsed using parse_object_buffer() which side-steps parse_commit() in
favor of parse_commit_buffer().
With generation numbers in the commit-graph, we need to ensu
When running 'git branch --contains', the in_merge_bases_many()
method calls paint_down_to_common() to discover if a specific
commit is reachable from a set of branches. Commits with lower
generation number are not needed to correctly answer the
containment query of in_merge_bases_many().
Add a ne
A commit A can reach a commit B only if the generation number of A
is strictly larger than the generation number of B. This condition
allows significantly short-circuiting commit-graph walks.
Use generation number for '--contains' type queries.
On a copy of the Linux repository where HEAD is cont
The generation number of a commit is defined recursively as follows:
* If a commit A has no parents, then the generation number of A is one.
* If a commit A has parents, then the generation number of A is one
more than the maximum generation number among the parents of A.
Add a uint32_t generat
Thanks for the feedback on the previous version. I think this series is
stabilizing nicely. I'll reply to this message with an inter-diff as it
is not too large to share but would clutter this cover letter.
Thanks,
-Stolee
-- >8 --
This is the one of several "small" patches that follow the seria
While preparing commits to be written into a commit-graph file, compute
the generation numbers using a depth-first strategy.
The only commits that are walked in this depth-first search are those
without a precomputed generation number. Thus, computation time will be
relative to the number of new c
The in_commit_list() method does not check the parents of
the candidate for containment in the list. Fix the comment
that incorrectly states that it does.
Reported-by: Jakub Narebski
Signed-off-by: Derrick Stolee
---
ref-filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 4/24/2018 2:56 PM, Jakub Narebski wrote:
Derrick Stolee writes:
One way to fix this is to call 'prepare_commit_graph()' directly and
then test that 'commit_graph' is non-null before performing any
parses. I'm not thrilled with how that couples the commit-graph
implementation to this feature,
On Tue, Apr 24, 2018 at 6:17 PM, Duy Nguyen wrote:
> On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen wrote:
>> git-completion.bash will be updated to ask git "give me the commands
>> in the mainporcelain, completable or external category". This also
>> addresses another thing that bugs me: I wanted a
On Sat, Apr 21, 2018 at 6:54 PM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index a5f13ade20..7d17ca23f6 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -8
Hi!
This is for git 2.13.6, and it may be an FAQ or frequent feature request.
Anyway:
I'm new to Java, and writing my first project using Git, I found that "git
diff" only reports the class in the diff context, but not the method (as seen
for C, for example).
I'd wish to have the method where t
On Sat, Apr 21, 2018 at 5:50 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> Not necessarily worth a re-roll.
>>
>> Not that it matters in this case, but just as a bit of Perl rx pedantry,
>> yes his is tighter & more correct. You didn't consider how "." interacts
>> with newlin
Hi Phillip,
On Mon, 23 Apr 2018, Phillip Wood wrote:
> On 23/04/18 19:11, Stefan Beller wrote:
> >
> > On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin
> > wrote:
> > > Eric Sunshine pointed out that I had such a commit message in
> > > https://public-inbox.org/git/CAPig+cRrS0_nYJJY=o6cbov
Hi Junio,
On Wed, 25 Apr 2018, Junio C Hamano wrote:
> * js/rebase-recreate-merge (2018-04-24) 16 commits
> - rebase -i --rebase-merges: add a section to the man page
> - rebase -i: introduce --rebase-merges=[no-]rebase-cousins
> - pull: accept --rebase=merges to recreate the branch topology
>
I installed from `Git-2.16.2-64-bit.exe` from git-scm.com. `iconv` is
included in this package. I think `iconv` should have the encoding
`ISO646-SE2`. Ubuntu 16.04 has this encoding. I use it to read old
Swedish text files, which there are a lot of e.g.:
`curl -s https://www.abc.se/programbanken
The `git merge` command does not allow merging commits that are already
reachable from HEAD: `git merge HEAD^`, for example, will report that we
are already up to date and not change a thing.
In an interactive rebase, such a merge could occur previously, e.g. when
competing (or slightly modified)
The --rebase-merges mode is probably not half as intuitive to use as
its inventor hopes, so let's document it some.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 135 +++
1 file changed, 135 insertions(+)
diff --git a/Documentation/git-reb
1 - 100 of 142 matches
Mail list logo
