Automatic re-encoding of commit messages (and dropping of the encoding
header) hurts attempts to do reversible history rewrites (e.g. sha1sum
<-> sha256sum transitions, some subtree rewrites), and seems
inconsistent with the general principle followed elsewhere in
fast-export of requiring explicit
The find_encoding() function returned the encoding used by a commit
message, returning a default of git_commit_encoding (usually UTF-8).
Although the current code does not differentiate between a commit which
explicitly requested UTF-8 and one where we just assume UTF-8 because no
encoding is set,
This test used an author with non-ascii characters in the name, but no
special commit message. It then grep'ed for those non-ascii characters,
but those are guaranteed to exist regardless of the reencoding process
since the reencoding only affects the commit message, not the author or
committer na
Since git supports commit messages with an encoding other than UTF-8,
allow fast-import to import such commits. This may be useful for folks
who do not want to reencode commit messages from an external system, and
may also be useful to achieve reversible history rewrites (e.g. sha1sum
<-> sha256su
When fast-export encounters a commit with an 'encoding' header, it tries
to reencode in UTF-8 and then drops the encoding header. However, if it
fails to reencode in UTF-8 because e.g. one of the characters in the
commit message was invalid in the old encoding, then we need to retain
the original
While stress testing `git filter-repo`, I noticed an issue with
encoding; further digging led to the fixes and features in this series.
See the individual commit messages for details.
Changes since v5 (full range-diff below):
* s/utf-8/UTF-8/, as pointed out by Torsten (in commit messages and co
On Mon, May 13, 2019 at 04:17:25PM -0700, Elijah Newren wrote:
> The find_encoding() function returned the encoding used by a commit
> message, returning a default of git_commit_encoding (usually utf-8).
I think "UTF-8" is preferred over "utf-8".
Unless it is a function name like is_encoding_utf8()
On Mon, May 13, 2019 at 04:17:24PM -0700, Elijah Newren wrote:
> When fast-export encounters a commit with an 'encoding' header, it tries
> to reencode in utf-8 and then drops the encoding header. However, if it
> fails to reencode in utf-8 because e.g. one of the characters in the
> commit messag
On Mon, May 13, 2019 at 04:17:22PM -0700, Elijah Newren wrote:
> This test used an author with non-ascii characters in the name, but
> no special commit message. It then grep'ed for those non-ascii
> characters, but those are guaranteed to exist regardless of the
> reencoding process since the ree
Todd Zullinger wrote:
> The JGIT prereq uses 'type jgit' to determine whether jgit is present.
> While this should be sufficient, if the jgit found is broken we'll waste
> time running tests which fail due to no fault of our own.
>
> Use 'jgit --version' instead, to catch some badly broken jgit
>
Hi,
brian m. carlson wrote:
> On Mon, May 13, 2019 at 05:51:01PM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:
>>> the fact that inheritance in the configuration
>>> is in-order and can't be easily modified means that it's not likely to
>>> be very useful, but
On Mon, May 13, 2019 at 10:05:20PM -0400, Todd Zullinger wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 908ddb9c46..599fd70e14 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1522,7 +1522,7 @@ test_lazy_prereq NOT_ROOT '
> '
>
> test_lazy_prereq JGIT '
> - type jgit
>
The JGIT prereq uses 'type jgit' to determine whether jgit is present.
While this should be sufficient, if the jgit found is broken we'll waste
time running tests which fail due to no fault of our own.
Use 'jgit --version' instead, to catch some badly broken jgit
installations.
Signed-off-by: Tod
On Mon, May 13, 2019 at 02:51:37PM +0900, Junio C Hamano wrote:
> If the difference between "status" and "commit" bothers you so much,
> i.e.
>
> When typing "git status", there is an empty line between the
> "Changes not staged for commit:" block and the list of changed
> files. Howev
On Mon, May 13, 2019 at 05:51:01PM -0700, Jonathan Nieder wrote:
> Hi,
>
> brian m. carlson wrote:
>
> > I've thought a lot about the discussion over whether this series should
> > use the configuration as the source for multiple hooks. Ultimately, I've
> > come to the decision that it's not a go
Here is today's test coverage report. You can view it in HTML [1] or text [2]
form, and below.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-05-13.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-05-13.txt
---
pu 7965c284718b7b0dfb
Hi,
brian m. carlson wrote:
> I've thought a lot about the discussion over whether this series should
> use the configuration as the source for multiple hooks. Ultimately, I've
> come to the decision that it's not a good idea. Even adopting the empty
> entry as a reset marker, the fact that inher
Please see the test-coverage report for code added between v2.21.0 and
v2.22.0-rc0. These lines are not tested by the test suite on Linux with
standard build options.
Thanks,
-Stolee
---
builtin/blame.c
a544fb08f8b builtin/blame.c 1005) die("no such ref: HEAD");
builtin/branch.c
0ecb1fc7269
Add support for multiple post-checkout hooks. We test only one possible
path in the multiple hook case because the same code path is used for
all checkouts and we know the hooks work from earlier assertions.
Signed-off-by: brian m. carlson
---
builtin/worktree.c| 44 +
A variety of types of software take advantage of Git's hooks. However,
if a user would like to integrate multiple pieces of software which use
a particular hook, they currently must manage those hooks themselves,
which can be burdensome. Sometimes various pieces of software try to
overwrite each ot
Add support for multiple post-rewrite hooks, both for "git commit
--amend" and "git rebase". Unify the hook handling between the am-based
and sequencer-based code paths.
Additionally add support for multiple prepare-commit-msg hooks.
Note that the prepare-commit-msg hook is not passed a set of ho
Document the semantics and behavior of multiple hooks, including the
configuration options and requirements for them to be run.
Signed-off-by: brian m. carlson
---
Documentation/config.txt | 2 ++
Documentation/config/hook.txt | 19 +++
Documentation/githooks.txt| 9 ++
There are a variety of situations in which a user may want an error
behavior for multiple hooks other than the default. Add a config option,
hook..errorBehavior to allow users to customize this behavior on a
per-hook basis. Provide options for the default behavior (exiting
early), executing all hoo
Add support for multiple pre-push hooks.
Remove find_hook since there are no longer any callers of it.
Signed-off-by: brian m. carlson
---
run-command.c| 12
run-command.h| 6 --
t/t5571-pre-push-hook.sh | 19 +++
transport.c
Add support for multiple post-rewrite hooks, both for "git commit
--amend" and "git rebase".
Additionally add support for multiple prepare-commit-msg hooks.
Note that the prepare-commit-msg hook is not passed a set of hooks
directly because these are discovered later when the code calls
run_hooks
Add support for multiple hooks for the pre-receive, post-receive,
update, post-update, and push-to-checkout hooks. Add tests for these
hooks using the multiple hook test framework.
Because the invocations of test_multiple_hooks contain multiple test
assertions, they (and the cd commands that surro
Hi Junio,
Junio C Hamano 於 2019年5月13日 週一 下午1:51寫道:
>
> 林自均 writes:
>
> > Hi Junio,
> >> ...
> > Could you please give me some advice on my patch? Thank you.
>
> I tend to agree with what Phillip said in
> .
>
> If the difference between "status" and "commit" bothers you so much,
> i.e.
>
> W
This series introduces multiple hook support.
I've thought a lot about the discussion over whether this series should
use the configuration as the source for multiple hooks. Ultimately, I've
come to the decision that it's not a good idea. Even adopting the empty
entry as a reset marker, the fact t
On Mon, May 13, 2019 at 7:17 PM Elijah Newren wrote:
> Automatic re-encoding of commit messages (and dropping of the encoding
> header) hurts attempts to do reversible history rewrites (e.g. sha1sum
> <-> sha256sum transitions, some subtree rewrites), and seems
> inconsistent with the general prin
Hi,
Matthew DeVore wrote:
> On 2019/05/09, at 11:00, Jonathan Tan wrote:
>> - Supporting any combination of filter means that we have more to
>> implement and test, especially if we want to support more filters in
>> the future. In particular, the different filters (e.g. blob, tree)
>> have d
> On 2019/05/09, at 11:00, Jonathan Tan wrote:
>
> Thanks for the numbers. Let me think about it some more, but I'm still
> reluctant to introduce multiple filter support in the protocol and the
> implementation for the following reasons:
Correction to the original command - I was tweaking it
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> In f41179f16ba2 (parse-options: avoid magic return codes, 2019-01-27),
> the signature of the low-level parse-opt callback function was changed
> to return an `enum`.
>
> And while the implementations were changed, on
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When this function was changed in a97d00799a19 (remote-curl: use
> post_rpc() for protocol v2 also, 2019-02-21) from file-local to global,
> the declaration was incorrectly missing the `const` qualifier.
I do not qui
The find_encoding() function returned the encoding used by a commit
message, returning a default of git_commit_encoding (usually utf-8).
Although the current code does not differentiate between a commit which
explicitly requested utf-8 and one where we just assume utf-8 because no
encoding is set,
When fast-export encounters a commit with an 'encoding' header, it tries
to reencode in utf-8 and then drops the encoding header. However, if it
fails to reencode in utf-8 because e.g. one of the characters in the
commit message was invalid in the old encoding, then we need to retain
the original
Automatic re-encoding of commit messages (and dropping of the encoding
header) hurts attempts to do reversible history rewrites (e.g. sha1sum
<-> sha256sum transitions, some subtree rewrites), and seems
inconsistent with the general principle followed elsewhere in
fast-export of requiring explicit
Do not change the existing info/refs and objects/info/packs
files if they match the existing content on the filesystem.
This is intended to preserve mtime and make it easier for dumb
HTTP pollers to rely on the If-Modified-Since header.
Combined with stdio and kernel buffering; the kernel should b
While stress testing `git filter-repo`, I noticed an issue with
encoding; further digging led to the fixes and features in this series.
See the individual commit messages for details.
Changes since v4 (full range-diff below):
* Used git_parse_maybe_bool()
* Updated Documentation/git-fast-expor
This test used an author with non-ascii characters in the name, but
no special commit message. It then grep'ed for those non-ascii
characters, but those are guaranteed to exist regardless of the
reencoding process since the reencoding only affects the commit message,
not the author or committer na
Since git supports commit messages with an encoding other than utf-8,
allow fast-import to import such commits. This may be useful for folks
who do not want to reencode commit messages from an external system, and
may also be useful to achieve reversible history rewrites (e.g. sha1sum
<-> sha256su
Philip Oakley writes:
> Does the contrib/rerere-train.sh actually work?
Yes, but it predates many esoteric things like multiple worktrees.
Philip Oakley writes:
> On GfW I commonly use the `git --help` when things go wrong, so
> making the response to that give the right advice would be good.
There are three levels of details ;-) "git --help" is meant as a
shorter and sweeter version of "git help git" that is more detailed
than "g
MS Visual C detected a mismatch between the declaration and the definition
of set_packet_header(): it is declared with its second parameter missing the
const attribute.
It also detected a mismatch between the declaration and the definition of
parse_opt_unknown_cb().
These problems must have bee
From: Johannes Schindelin
When this function was changed in a97d00799a19 (remote-curl: use
post_rpc() for protocol v2 also, 2019-02-21) from file-local to global,
the declaration was incorrectly missing the `const` qualifier.
Let's fix that.
Signed-off-by: Johannes Schindelin
---
pkt-line.h |
From: Johannes Schindelin
In f41179f16ba2 (parse-options: avoid magic return codes, 2019-01-27),
the signature of the low-level parse-opt callback function was changed
to return an `enum`.
And while the implementations were changed, one declaration was left
unchanged, still claiming to return `i
Ævar Arnfjörð Bjarmason writes:
> -CC lkml & git-packagers.
>
> Some suggestions for fixes in RelNotes & last-minute observations:
Thanks.
>> * "git stash" has been rewritten in C.
>
> I just noticed that stash.useBuiltin added in 90a462725e ("stash:
> optionally use the scripted version again
Elijah Newren writes:
> +static int parse_opt_reencode_mode(const struct option *opt,
> +const char *arg, int unset)
> +{
> + if (unset || !strcmp(arg, "abort"))
> + reencode_mode = REENCODE_ABORT;
> + else if (!strcmp(arg, "yes") || !strcmp(arg
-CC lkml & git-packagers.
Some suggestions for fixes in RelNotes & last-minute observations:
On Mon, May 13 2019, Junio C Hamano wrote:
> * "git stash" has been rewritten in C.
I just noticed that stash.useBuiltin added in 90a462725e ("stash:
optionally use the scripted version again", 2019-
Hi All,
On 10/05/2019 15:59, Philip Oakley wrote:
You can publish your merged branch somewhere, and others can use
contrib/rerere-train.sh to learn from the resolution.
Supposedly, I've never actually used it...
Does the contrib/rerere-train.sh actually work? I'm reading the code to
ensure I
On Mon, May 13, 2019 at 12:27 PM Junio C Hamano wrote:
> * en/fast-export-encoding (2019-05-13) 5 commits
> - fast-export: do automatic reencoding of commit messages only if requested
> - fast-export: differentiate between explicitly utf-8 and implicitly utf-8
> - fast-export: avoid stripping e
Update sha1dc from the latest version by the upstream
maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
sha1dc with UBSan", 2019-03-12) for the last update.
This fixes an issue where HP-UX IA64 was wrongly detected as a
Little-endian instead of a Big-endian system, see [2] and [3].
Git
http://www.takuro-bbs.com/cgi-bin/click3/click3.cgi?cnt=akatuki&url=https://u.to/yVVfFQ
Duncan
Hi Peff
On 13/05/2019 21:53, Jeff King wrote:
On Mon, May 13, 2019 at 09:47:27PM +0100, Philip Oakley wrote:
Is there a cli way, especially on Git for Windows bash, to get the html man
page of git(1)? I have it on my system, so can go via another page but..
All the `git --help` appear to work
On Mon, May 13 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> # Variables we fill in automatically, or via prompting:
>> -my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@initial_bcc,$no_bcc,@xh,
>> +my (@to,@cc,,@xh,$envelope_sender,
>
> ,,???
Just a typo. I see you fi
On Mon, May 13 2019, Ben Avison wrote:
> @@ -792,6 +795,11 @@ static int checkout(int submodule_progress)
> if (option_verbosity < 0)
> argv_array_push(&args, "--quiet");
>
> + if (option_remote_submodules == 1) {
I see you copied this from code a
On Mon, May 13, 2019 at 09:47:27PM +0100, Philip Oakley wrote:
> Is there a cli way, especially on Git for Windows bash, to get the html man
> page of git(1)? I have it on my system, so can go via another page but..
>
> All the `git --help` appear to work, but I can't determine the correct
> inv
Is there a cli way, especially on Git for Windows bash, to get the html
man page of git(1)? I have it on my system, so can go via another page but..
All the `git --help` appear to work, but I can't determine the
correct invocation for bringing up the stupid content tracker's page in
the brows
As discussed in [1] there's a regression in the "pu" branch now
because a new test implicitly assumed that a previous test guarded by
a prerequisite had been run. Add a "GIT_TEST_FAIL_PREREQS" special
test setup where we'll skip (nearly) all tests guarded by
prerequisites, allowing us to easily emu
When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be checked out on their
remote-tracking branch rather than with the SHA-1 recorded in the superproject
From: Slavica Djukic
Just like in the Perl script `git-add--interactive.perl`, for each
command a unique prefix is determined (if there exists any within the
given parameters), and shown in the list, and accepted as a shortcut for
the command.
We use the prefix map implementation that we just ad
From: Johannes Schindelin
This imitates the code to show the help text from the Perl script
`git-add--interactive.perl` in the built-in version.
To make sure that it renders exactly like the Perl version of `git add
-i`, we also add a test case for that to `t3701-add-interactive.sh`.
Signed-off
From: Daniel Ferreira
This implements the `status` command of `git add -i`. The data
structures introduced in this commit will be extended as needed later.
At this point, we re-implement only part of the `list_and_choose()`
function of the Perl script `git-add--interactive.perl` and call it
`lis
From: Slavica Djukic
In the `git add -i` command, we show unique prefixes of the commands and
files, to give an indication what prefix would select them.
Naturally, the C implementation looks a lot different than the Perl
implementation: in Perl, a trie is much easier implemented, while we
alrea
From: Slavica Djukic
The error messages as well as the unique prefixes are colored in `git
add -i` by default; We need to do the same in the built-in version.
Signed-off-by: Slavica Djukic
Signed-off-by: Johannes Schindelin
---
add-interactive.c | 37 -
1 f
From: Johannes Schindelin
This is hardly the first conversion of a Git command that is implemented
as a script to a built-in. So far, the most successful strategy for such
conversions has been to add a built-in helper and call that for more and
more functionality from the script, as more and more
From: Johannes Schindelin
The reason why we did not start with the main loop to begin with is that
it is the first user of `list_and_choose()`, which uses the `list()`
function that we conveniently introduced for use by the `status`
command.
Apart from the "and choose" part, there are more diffe
From: Johannes Schindelin
For simplicity, we only implemented the `status` command without colors.
This patch starts adding color, matching what the Perl script
`git-add--interactive.perl` does.
Original-Patch-By: Daniel Ferreira
Signed-off-by: Slavica Djukic
Signed-off-by: Johannes Schindelin
From: Johannes Schindelin
With this change, we print out the same colored help text that the
Perl-based `git add -i` prints in the main loop when question mark is
entered.
Signed-off-by: Johannes Schindelin
---
add-interactive.c | 22 +-
1 file changed, 21 insertions(+), 1
This is the first leg on the long journey to a fully built-in git add -i
(next up: parts 2 [https://github.com/gitgitgadget/git/pull/171], 3
[https://github.com/gitgitgadget/git/pull/172], 4
[https://github.com/gitgitgadget/git/pull/173], 5
[https://github.com/gitgitgadget/git/pull/174], and 6
[ht
From: Johannes Schindelin
This is what the Perl version does, and therefore it is what the
built-in version should do, too.
Signed-off-by: Johannes Schindelin
---
add-interactive.c | 4 +++-
repository.c | 19 +++
repository.h | 7 +++
3 files changed, 29 insert
From: Daniel Ferreira
Make the diffstat interface (namely, the diffstat_t struct and
compute_diffstat) no longer be internal to diff.c and allow it to be used
by other parts of git.
This is helpful for code that may want to easily extract information
from files using the diff machinery, while fl
> > +- When cloning, the former implies --local option. See
> > + linkgit:git-clone[1] for details.
> > +
> > +- The latter is implemented using linkgit:git-upload-pack[1], which
> > + expects its repository to be a directory, and therefore does not
> > + work for bundles (see linkgit:git-bundle
When fast-export encounters a commit with an 'encoding' header, it tries
to reencode in utf-8 and then drops the encoding header. However, if it
fails to reencode in utf-8 because e.g. one of the characters in the
commit message was invalid in the old encoding, then we need to retain
the original
Since git supports commit messages with an encoding other than utf-8,
allow fast-import to import such commits. This may be useful for folks
who do not want to reencode commit messages from an external system, and
may also be useful to achieve reversible history rewrites (e.g. sha1sum
<-> sha256su
The find_encoding() function returned the encoding used by a commit
message, returning a default of git_commit_encoding (usually utf-8).
Although the current code does not differentiate between a commit which
explicitly requested utf-8 and one where we just assume utf-8 because no
encoding is set,
Automatic re-encoding of commit messages (and dropping of the encoding
header) hurts attempts to do reversible history rewrites (e.g. sha1sum
<-> sha256sum transitions, some subtree rewrites), and seems
inconsistent with the general principle followed elsewhere in
fast-export of requiring explicit
While stress testing `git filter-repo`, I noticed an issue with
encoding; further digging led to the fixes and features in this series.
See the individual commit messages for details.
Changes since v3 (full range-diff below):
* YES/NO changes suggested by Torsten
* more boolean synonyms as sug
This test used an author with non-ascii characters in the name, but
no special commit message. It then grep'ed for those non-ascii
characters, but those are guaranteed to exist regardless of the
reencoding process since the reencoding only affects the commit message,
not the author or committer na
On Mon, May 13, 2019 at 3:23 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Sat, 11 May 2019, Elijah Newren wrote:
>
> > [...] the craziness is based on how Windows behaves; it seems insane to
> > me that Windows decides to munge user data (in the form of the command
> > line provided), so mu
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.
An early preview 2.22-rc0 has been
An early preview release Git v2.22.0-rc0 is now available for
testing at the usual places. It is comprised of 648 non-merge
commits since v2.21.0, contributed by 58 people, 11 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The followi
Hi Eric,
On Mon, 13 May 2019, Eric Sunshine wrote:
> On Mon, May 13, 2019 at 10:06 AM Johannes Schindelin
> wrote:
> > I should have posted the link, as it may not be totally obvious where you
> > can download artifacts:
> >
> > https://dev.azure.com/mseng/AzureDevOps/_build/results?buildId=9464
On Mon, May 13, 2019 at 10:06 AM Johannes Schindelin
wrote:
> I should have posted the link, as it may not be totally obvious where you
> can download artifacts:
>
> https://dev.azure.com/mseng/AzureDevOps/_build/results?buildId=9464474&view=artifacts
This link leads to a Login page requiring som
Hi,
On Mon, 13 May 2019, Johannes Schindelin wrote:
> On Fri, 10 May 2019, Duy Nguyen wrote:
>
> > On Fri, May 10, 2019 at 3:54 AM Johannes Schindelin
> > wrote:
> > >
> > > Hi Junio & Duy,
> > >
> > > On Thu, 9 May 2019, Junio C Hamano wrote:
> > >
> > > > * nd/merge-quit (2019-05-07) 2 commits
Hi Duy,
On Fri, 10 May 2019, Duy Nguyen wrote:
> On Fri, May 10, 2019 at 3:54 AM Johannes Schindelin
> wrote:
> >
> > Hi Junio & Duy,
> >
> > On Thu, 9 May 2019, Junio C Hamano wrote:
> >
> > > * nd/merge-quit (2019-05-07) 2 commits
> > > - merge: add --quit
> > > - merge: remove drop_save() i
On Mon, May 13, 2019 at 5:56 AM Torsten Bögershausen wrote:
>
> On Mon, May 13, 2019 at 12:23:29PM +0200, Johannes Schindelin wrote:
> > Hi Elijah,
> >
> > On Sat, 11 May 2019, Elijah Newren wrote:
> >
> > > [...] the craziness is based on how Windows behaves; it seems insane to
> > > me that Wind
Hi Dscho
On 10/05/2019 14:49, Johannes Schindelin wrote:
Hi Phillip,
On Thu, 9 May 2019, Phillip Wood wrote:
On 08/05/2019 18:23, Junio C Hamano wrote:
* pw/rebase-abort-clean-rewritten (2019-05-08) 1 commit
- rebase --abort: cleanup refs/rewritten
(this branch uses pw/rebase-i-interna
On Mon, May 13, 2019 at 12:48 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > On Sat, May 11, 2019 at 2:07 PM Torsten Bögershausen wrote:
> >> On Fri, May 10, 2019 at 01:53:35PM -0700, Elijah Newren wrote:
> >
> >> This one is good:
> >> > + if (unset || !strcmp(arg, "abort"))
> >>
On Mon, May 13, 2019 at 12:23:29PM +0200, Johannes Schindelin wrote:
> Hi Elijah,
>
> On Sat, 11 May 2019, Elijah Newren wrote:
>
> > [...] the craziness is based on how Windows behaves; it seems insane to
> > me that Windows decides to munge user data (in the form of the command
> > line provided)
Hi Duy,
On Mon, 13 May 2019 at 10:21, Duy Nguyen wrote:
>
> On Sun, May 12, 2019 at 5:14 PM Shaheed Haque wrote:
> >
> > Hi,
> >
> > I'm running git v.2.20.1 on Ubuntu from a program which follows the pattern:
> >
> >
> > 1. create a temporary directory /tmp/tmpabc
>
> When is this
Hi Jeff,
On Thu, 18 Apr 2019, Jeff Hostetler wrote:
> On 4/10/2019 1:37 PM, Slavica Djukic via GitGitGadget wrote:
> > From: Slavica Djukic
> >
> > In the `git add -i` command, we show unique prefixes of the commands and
> > files, to give an indication what prefix would select them.
> >
> > Nat
Hi Nguyễn,
Thanks for the quick response. While I leave the code to the experts,
I can confirm that restoring the missing directory (but no content in
it) does allow "worktree add" to function again.
One point may be worth clarifying...
On Mon, 13 May 2019 at 11:50, Nguyễn Thái Ngọc Duy wrote:
Hi Jeff,
On Thu, 18 Apr 2019, Jeff Hostetler wrote:
> On 4/10/2019 1:37 PM, Johannes Schindelin via GitGitGadget wrote:
>
> > [...]
> > +
> > +/*
> > + * Returns the selected index.
> > + */
> > +static ssize_t list_and_choose(struct item **items, size_t nr,
> > + struct
On 5/13/2019 7:04 AM, Derrick Stolee wrote:
> On 5/12/2019 11:13 PM, Junio C Hamano wrote:
>> "Derrick Stolee via GitGitGadget" writes:
>>
>>> diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
>>> @@ -188,14 +187,14 @@ static int graph_write(int argc, const char **argv)
>>>
Hi Peff,
On Tue, 30 Apr 2019, Jeff King wrote:
> On Tue, Apr 30, 2019 at 07:40:06PM -0400, Johannes Schindelin wrote:
>
> > And I also tried pretty hard to *not* bleed any internal state of
> > `add-interactive` into `builtin/add`, as I wanted the new code to be
> > as libified as possible (in a
On 5/12/2019 11:13 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
>> @@ -188,14 +187,14 @@ static int graph_write(int argc, const char **argv)
>> UNLEAK(buf);
>> }
>>
>> -write_commit_g
On 5/12/2019 11:44 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> From: Derrick Stolee
>>
>> The write_commit_graph() and write_commit_graph_reachable() methods
>> currently take two boolean parameters: 'append' and 'report_progress'.
>> We will soon expand the possib
find_worktree() can die() unexpectedly because it uses real_path()
instead of the gentler version. When it's used in 'git worktree add' [1]
and there's a bad worktree, this die() could prevent people from adding
new worktrees.
The "bad" condition to trigger this is when a parent of the worktree's
Hi Elijah,
On Sat, 11 May 2019, Elijah Newren wrote:
> [...] the craziness is based on how Windows behaves; it seems insane to
> me that Windows decides to munge user data (in the form of the command
> line provided), so much so that it makes me wonder if I really
> understood Hannes' and Dscho's
Hi Elijah,
On Fri, 10 May 2019, Elijah Newren wrote:
> * Modified the testcases to pass on Windows[1], as verified via
> gitgitgadget pull request[2]. Required adding a couple new files
> (which store the desired bytes) and checking the size of the output
> instead of checking for
1 - 100 of 106 matches
Mail list logo