On Sun, Apr 22, 2018 at 1:15 AM, Igor Korot wrote:
> MyMac:git-2.17.0 igorkorot$ cat config.mak
> NO_GETTEXT=Yes
> NO_OPENSSL=Yes
>
> MyMac:dbhandler igorkorot$ /Users/igorkorot/git-2.17.0/git pull
> fatal: unable to access
> 'https://github.com/oneeyeman1/dbhandler.git/': error:1407742E:SSL
> rou
Hi,
Sorry for the long delay. Been busy with life things.
I built git from sources. The build was successful.
[code]
MyMac:git-2.17.0 igorkorot$ cat config.mak
NO_GETTEXT=Yes
NO_OPENSSL=Yes
[/code]
Next I tried to do git pull for my project:
[code]
MyMac:dbhandler igorkorot$ /Users/igorkorot/gi
On Sat, Apr 21, 2018 at 5:48 AM, Johannes Schindelin
wrote:
> This option is intended to help with the transition away from the
> now-deprecated graft file.
>
> Signed-off-by: Johannes Schindelin
> ---
> diff --git a/builtin/replace.c b/builtin/replace.c
> @@ -454,6 +455,38 @@ static int create_g
Jakub Narebski writes:
> Derrick Stolee writes:
>> On 4/11/2018 3:32 PM, Jakub Narebski wrote:
>
>>> What would you suggest as a good test that could imply performance? The
>>> Google Colab notebook linked to above includes a function to count
>>> number of commits (nodes / vertices in the commit
On Sat, Apr 21, 2018 at 12:37 PM, Elijah Newren wrote:
> Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
> Since we create a temporary index in o->result, then discard o->dst_index
> and overwrite it with o->result, when o->src_index == o->dst_index it is
> safe to just
Currently, all callers of unpack_trees() set o->src_index == o->dst_index.
Since we create a temporary index in o->result, then discard o->dst_index
and overwrite it with o->result, when o->src_index == o->dst_index it is
safe to just reuse o->src_index's split_index for o->result. However,
o->src
On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Changes:
>
> - remove the deprecated column in command-list.txt. My change break it
> anyway if anyone uses it.
> - fix up failed tests that I marked in the RFC and kinda forgot about it.
> - fix bashisms in generate-cmdlist
This is useful for git-completion.bash because it needs this set of
commands. Right now we have to maintain a separate command category in
there.
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
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
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
Changes:
- remove the deprecated column in command-list.txt. My change break it
anyway if anyone uses it.
- fix up failed tests that I marked in the RFC and kinda forgot about it.
- fix bashisms in generate-cmdlist.sh
- fix segfaul in "git help"
Nguyễn Thái Ngọc Duy (6):
git.c: convert --list
common-cmds.h is used to extract the list of common commands (by
group) and a one-line summary of each command. Some information is
dropped, for example command category or summary of other commands.
Update generate-cmdlist.sh to keep all the information. The extra info
will be used shortly.
The "
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 2 +-
git.c | 2 ++
help.c | 18 ++
help.h | 1 +
4 files changed, 22 insertions(+), 1 deletion(-)
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
On 21/04/18 11:33, Johannes Schindelin wrote:
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.
On 20/04/18 13:18, Johannes Schindelin wrote:
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
However, if the last of these fixup/squash
I didn't get any reply from you concerning my last email..
Br
LiN
__
Sky Silk, http://aknet.kz
From: Philip Oakley
The short and sweet PREFIX can be confused when used in many places.
Rename both usages to better describe their purpose. EXEC_CMD_PREFIX is
used in full to disambiguate it from the nearby GIT_EXEC_PATH.
The PREFIX in sideband.c, while nominally independant of the exec_cmd
P
The runtime of a simple `git.exe version` call on Windows is currently
dominated by the gettext setup, adding a whopping ~150ms to the ~210ms
total.
Given that this cost is added to each and every git.exe invocation goes
through common-main's invocation of git_setup_gettext(), and given that
scrip
We carried a slightly different version of the git_setup_gettext() patch
(which took care of releasing the buffer allocated by system_path()),
and we carry two more patches that touch the same area, so now that
dj/runtime-prefix hit `next`, it seems a good time to contribute those,
too.
Changes si
The system_path() function returns a freshly-allocated string. We need
to release it.
Signed-off-by: Johannes Schindelin
---
gettext.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/gettext.c b/gettext.c
index 701355d66e7..7272771c8e4 100644
--- a/gettext.c
+++ b/ge
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
This one is a bit tricky to explain, so let's try with a diagram:
C
/ \
A - B - E - F
\ /
D
To illustrate what this new mode is all about, let's consider what
happens upon `git rebase -i --rebase-merges B`, in particular to
the commit `D`. So far, the new branch structure
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-
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)
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
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-
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
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
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
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
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 `
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
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
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
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(+
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
Hi Ævar,
On Sat, 21 Apr 2018, Ævar Arnfjörð Bjarmason wrote:
> I still stand by the observation that the "why don't we" isn't clear at
> all from your patch's commit message and that should be fixed. It
> doesn't mention any of the actual reasons for the change which have been
> revealed in this
To help users discern large chunks of white text (when the push
succeeds) from large chunks of white text (when the push fails), let's
add some color to the latter.
The original contribution came in via Pull Request from the Git for
Windows project:
https://github.com/git-for-windows/git/
So far, we only ever asked whether stdout wants to be colorful. In the
upcoming patches, we will want to make push errors more prominent, which
are printed to stderr, though.
So let's refactor the want_color() function into a want_color_fd()
function (which expects to be called with fd == 1 or fd
This actually only tests whether the push errors/hints are colored if
the respective color.* config settings are `always`, but in the regular
case they default to `auto` (in which case we color the messages when
stderr is connected to an interactive terminal), therefore these tests
should suffice.
Let's make it easier for users to find out how to customize these colors.
Signed-off-by: Johannes Schindelin
---
Documentation/config.txt | 28
1 file changed, 28 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2659153cb37..2cea0
From: Ryan Dammrose
This is an attempt to resolve an issue I experience with people that are
new to Git -- especially colleagues in a team setting -- where they miss
that their push to a remote location failed because the failure and
success both return a block of white text.
An example is if I
Now that grafts are deprecated, we should start to assume that readers
have no idea what grafts are. So it makes more sense to describe the
"shallow" feature in terms of replace refs.
Suggested-by: Eric Sunshine
Signed-off-by: Johannes Schindelin
---
Documentation/technical/shallow.txt | 19 +++
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
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/
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
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
---
t/t6050-replace.sh | 20
1 file cha
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 | 44 ++-
2 files changed, 51 insertions(+), 4 deletions
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
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
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
[...]`.
Hi Gábor,
On Sat, 21 Apr 2018, SZEDER Gábor wrote:
> > 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
Hi Stefan,
On Fri, 20 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 20, 2018 at 3:20 PM, Johannes Schindelin
> wrote:
> > 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
--
Hello My Dear
Calvary Greetings in the name of the ALMIGHTY
I am Mrs Lillian Allan from Switzerland I am married to Late Mr.Allan
Joseph who is a wealthy business man here in Burkina Faso we were
married for many years without a child before he died after a
brief illness Before his sudden d
On 21 April 2018 at 05:45, Taylor Blau wrote:
> This commit teaches 'git-grep(1)' a new option, '--column-number'. This
> option builds upon previous commits to show the column number of the
> first match on a non-context line.
>
> For example:
>
> $ git grep -mn example | head -n3
> .clang-fo
On 21 April 2018 at 05:45, Taylor Blau wrote:
> diff --git a/grep.c b/grep.c
> index 29bc799ecf..7872a5d868 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -95,6 +95,10 @@ int grep_config(const char *var, const char *value, void
> *cb)
> opt->linenum = git_config_bool(var, value);
>
On Fri, Apr 20 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Fri, 20 Apr 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Fri, Apr 20 2018, Martin Ågren wrote:
>>
>> > On 20 April 2018 at 11:59, Ævar Arnfjörð Bjarmason
>> > wrote:
>> >>
>> >> On Fri, Apr 20 2018, Johannes Schindelin wrote:
>>
During a series of fixup/squash commands, the interactive rebase builds
up a commit message with comments. This will be presented to the user in
the editor if at least one of those commands was a `squash`.
However, if the last of these fixup/squash commands fails with merge
conflicts, and if the u
In the upcoming patch to clean up fixup/squash commit messages even when
skipping a final fixup/squash that failed with merge conflicts, we will
need to have some indicator what happened.
As we need to remove the message-fixup and message-squash files upon
failure, we cannot use those. So let's ju
When multiple fixup/squash commands are processed and the last one
causes merge conflicts and is skipped, we leave the "This is a
combination of ..." comments in the commit message.
Noticed by Eric Sunshine.
This regression test also demonstrates that we rely on the localized
version of
Eric Sunshine pointed out that I had such a commit message in
https://public-inbox.org/git/CAPig+cRrS0_nYJJY=o6cbov630snqhpv5qgrqdd8mw-syzn...@mail.gmail.com/
and I went on a hunt to figure out how the heck this happened.
Turns out that if there is a fixup/squash chain where the *last* command
fai
We previously relied on the localized versions of
# This is a combination of commits
(which we write into the commit messages during fixup/squash chains)
to contain as ASCII.
This is not true in general, and certainly not in GETTEXT_POISON, as
demonstrated by the regression test we jus
Hi Stefan,
On Fri, 20 Apr 2018, Stefan Beller wrote:
> > static GIT_PATH_FUNC(rebase_path_amend, "rebase-merge/amend")
> > +/*
> > + * If there was a merge conflict in a fixup/squash series, we need to
> > + * record the type so that a `git rebase --skip` can clean up the commit
> > + * message
Hi Stefan,
On Fri, 20 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 20, 2018 at 2:07 PM, Johannes Schindelin
> wrote:
> > We previously relied on the localized versions of
> >
> > # This is a combination of commits
> >
> > (which we write into the commit messages during fixup/squash chai
On 21 April 2018 at 05:43, Junio C Hamano wrote:
> but I do not think the updated "fix" below is better. It might be
> just aesthetics and I suspect I won't find it as disturbing if we
> could push with
>
> object_array_push(commits, (struct object *)commit);
>
> or something that is more
70 matches
Mail list logo
