Hi Stefan,
On Tue, 24 Apr 2018, Stefan Beller wrote:
> On Tue, Apr 24, 2018 at 11:51 AM, Johannes Schindelin
> wrote:
>
> >
> > Oy vey. How many more mistakes can I introduce in one commit...
> >
>
> I ask this myself all the time, but Software is hard when not having
> computer assisted check
W dniu śro, 25.04.2018 o godzinie 06∶58 +, użytkownik Robin H.
Johnson napisał:
> On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
> > --- a/entry.c
> > +++ b/entry.c
> > @@ -411,6 +411,7 @@ int checkout_entry(struct cache_entry *ce,
> > {
> > static struct strbuf path = STRBU
On Tue, Apr 24, 2018 at 08:41:07AM +0900, Junio C Hamano wrote:
> "Robin H. Johnson" writes:
>
> > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
> >> Currently git does not control mtimes of files being checked out. This
> >> means that the only assumption you could make is that
Hi Philip & Junio,
On Wed, 25 Apr 2018, Junio C Hamano wrote:
> "Philip Oakley" writes:
>
> > Perhaps something like:
> > +$GIT_DIR/shallow, and handle its contents similar to replace
> > +refs (with the difference that shallow does not actually
> > +create those replace refs) with the differen
Hi Elijah,
On Tue, 24 Apr 2018, Elijah Newren wrote:
> This allows us to run git, when using the script from bin-wrappers, under
> other programs. A few examples for usage within testsuite scripts:
>
>debug git checkout master
>debug --debugger=nemiver git $ARGS
>debug -d "valgrind
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`, and the latest screen contents were
still
Hi Junio,
On Wed, 25 Apr 2018, Junio C Hamano wrote:
> I really want to see that the runtime prefix stuff mature enough during
> this cycle, so these follow-up patches are all very much appreciated.
FWIW I merged these patches (including my touch-ups) into Git for Windows'
`master` branch early.
Hi Elijah,
On Tue, 24 Apr 2018, Elijah Newren wrote:
> On Tue, Apr 24, 2018 at 4:58 AM, Johannes Schindelin
> wrote:
> >
> > On Tue, 24 Apr 2018, Junio C Hamano wrote:
> >
> >> Yeah, but as opposed to passing "oh, let's see if we can get a
> >> reasonable result without rename detection just thi
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
On Mon, Apr 23 2018, Junio C. Hamano wrote:
> "Robin H. Johnson" writes:
>
>> On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
>>> Currently git does not control mtimes of files being checked out. This
>>> means that the only assumption you could make is that all files created
>>>
"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 happened to be dirty.
>
> This behavior
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 environment?
From the git config man page:
When the
It is fragile, as there is no way for the revision machinery to say "but
now I want to traverse the graph ignoring the graft file" e.g. when
pushing commits to a remote repository (which, as a consequence, can
miss commits).
And we already have a better solution with `git replace --graft
[...]`.
We have the BUG() macro for that purpose.
Signed-off-by: Johannes Schindelin
---
builtin/replace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 245d3f4164e..e345a5a0f1c 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -5
This is a simple function that will interpret a string as a whitespace
delimited list of values, and add those values into the array.
Note: this function does not (yet) offer to split by arbitrary delimiters,
or keep empty values in case of runs of whitespace, or de-quote Unix shell
style. All fo
The grafts feature was a convenient way to "stitch together" ancient
history to the fresh start of linux.git.
Its implementation is, however, not up to Git's standards, as there are
too many ways where it can lead to surprising and unwelcome behavior.
For example, when pushing from a repository w
The proof, as the saying goes, lies in the pudding. So here is a
regression test that not only demonstrates what the option is supposed to
accomplish, but also demonstrates that it does accomplish it.
Signed-off-by: Johannes Schindelin
---
builtin/replace.c | 1 -
t/t6050-replace.sh | 20 +
The graft file is deprecated now, so let's use replace refs in the example
in filter-branch's man page instead.
Suggested-by: Eric Sunshine
Signed-off-by: Johannes Schindelin
---
Documentation/git-filter-branch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentatio
Now that grafts are deprecated, we should start to assume that readers
have no idea what grafts are. So it makes more sense to make the
description of the "shallow" feature stand on its own.
Suggested-by: Eric Sunshine
Helped-by: Junio Hamano
Signed-off-by: Johannes Schindelin
---
Documentatio
The functionality is now implemented as `git replace
--convert-graft-file`.
Signed-off-by: Johannes Schindelin
---
contrib/convert-grafts-to-replace-refs.sh | 28 ---
1 file changed, 28 deletions(-)
delete mode 100755 contrib/convert-grafts-to-replace-refs.sh
diff --git a/c
This is yet another patch to be filed under the keyword "libification".
There is one subtle change in behavior here, where a `git log` that has
been asked to show the mergetags would now stop reporting the mergetags
upon the first failure, whereas previously, it would have continued to the
next me
File this away as yet another patch in the "libification" category.
As with all useful functions, in the next commit we want to use
create_graft() from a higher-level function where it would be
inconvenient if the called function simply die()s: if there is a
problem, we want to let the user know h
This option is intended to help with the transition away from the
now-deprecated graft file.
Signed-off-by: Johannes Schindelin
---
Documentation/git-replace.txt | 11 ++---
builtin/replace.c | 45 ++-
2 files changed, 52 insertions(+), 4 deletions
It is tempting to do away with commit_graft altogether (in the long
haul), now that grafts are deprecated.
However, the shallow feature needs a couple of things that the replace
refs cannot fulfill. Let's point that out in the documentation.
Signed-off-by: Johannes Schindelin
---
Documentation/
On Wed, Apr 25 2018, Junio C. Hamano wrote:
> THe command line completion (in contrib/) has been taught that "git
> * js/colored-push-errors (2018-04-24) 4 commits
> - config: document the settings to colorize push errors/hints
> - push: test to verify that push errors are colored
> - push:
On 25 April 2018 at 11:54, Johannes Schindelin
wrote:
> Now that grafts are deprecated, we should start to assume that readers
> have no idea what grafts are. So it makes more sense to make the
> description of the "shallow" feature stand on its own.
>
> Suggested-by: Eric Sunshine
> Helped-by: J
As pointed out in a review of the `--rebase-merges` patch series,
`rollback_lock_file()` clobbers errno. Therefore, we have to report the
error message that uses errno before calling said function.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 10 ++
1 file changed, 6 insertions(+
Previously, we did a lot of arithmetic gymnastics to get at the line in
the todo list (as stored in todo_list.buf). This might have been fast,
but only in terms of execution speed, not in terms of developer time.
Let's refactor this to make it a lot easier to read, and hence to
reason about the co
There are some commands that have to be skipped from rearranging by virtue
of not handling any commits.
However, the logic was not quite obvious: it skipped commands based on
their position in the enum todo_command.
Instead, let's make it explicit that we skip all commands that do not
handle any
Previously, we did that just magically, and potentially left some users
quite puzzled. Let's err on the safe side instead, telling the user what
is happening, and how they are supposed to continue.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 16
1 file changed, 16 inser
Junio, I think this is now ready for `next`. Thank you for your patience
and help with this.
Once upon a time, I dreamed of an interactive rebase that would not
linearize all patches and drop all merge commits, but instead recreate
the commit topology faithfully.
My original attempt was --preserv
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo list
The sequencer just learned new commands intended to recreate branch
structure (similar in spirit to --preserve-merges, but with a
substantially less-broken design).
Let's allow the rebase--helper to generate todo lists making use of
these commands, triggered by the new --rebase-merges option. For
From: Stefan Beller
Up to now each command took a commit as its first argument and ignored
the rest of the line (usually the subject of the commit)
Now that we are about to introduce commands that take different
arguments, clarify each command by giving the argument list.
Signed-off-by: Stefan
Just like with regular `pick` commands, if we are trying to rebase a
merge commit, we now test whether the parents of said commit match HEAD
and the commits to be merged, and fast-forward if possible.
This is not only faster, but also avoids unnecessary proliferation of
new objects.
Signed-off-by
From: Phillip Wood
If there are empty commits on the left hand side of $upstream...HEAD
then the empty commits on the right hand side that we want to keep are
being pruned.
Signed-off-by: Phillip Wood
---
t/t3421-rebase-topology-linear.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t
This allows for rebases to be run in parallel in separate worktrees
(think: interrupted in the middle of one rebase, being asked to perform
a different rebase, adding a separate worktree just for that job).
Signed-off-by: Johannes Schindelin
---
refs.c | 3 ++-
t/t3430-rebase-
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this
Similar to the `preserve` mode simply passing the `--preserve-merges`
option to the `rebase` command, the `merges` mode simply passes the
`--rebase-merges` option.
This will allow users to conveniently rebase non-trivial commit
topologies when pulling new commits, without flattening them.
Signed-
In the previous patches, we implemented the basic functionality of the
`git rebase -i --rebase-merges` command, in particular the `merge`
command to create merge commits in the sequencer.
The interactive rebase is a lot more these days, though, than a simple
cherry-pick in a loop. For example, it
When running `git rebase --rebase-merges` non-interactively with an
ancestor of HEAD as (or leaving the todo list unmodified),
we would ideally recreate the exact same commits as before the rebase.
However, if there are commits in the commit range .. that do not
have as direct ancestor (i.e. if
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
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
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
>
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
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!
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 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
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 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,
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
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 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
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 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
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
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
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
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
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
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 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
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
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
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
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 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 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.
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
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
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
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
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
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
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
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
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
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
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 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 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 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 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: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
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
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
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
1 - 100 of 142 matches
Mail list logo
