On Wed, May 15, 2019 at 10:34 PM Elijah Newren wrote:
>
> On Wed, May 15, 2019 at 8:30 AM Ævar Arnfjörð Bjarmason
> wrote:
> >
> > On Wed, May 15 2019, Piotr Krukowiecki wrote:
> >
> > > Hello,
> > >
> > > I'm migrating two repositories from svn. I already did svn->git
> > > migration (git-svn cl
On Wed, May 15, 2019 at 5:25 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, May 15 2019, Piotr Krukowiecki wrote:
>
> > Hello,
> >
> > I'm migrating two repositories from svn. I already did svn->git
> > migration (git-svn clone) and now have two git repositories.
> >
> > I would like to merge the
On Wed, May 15, 2019 at 5:36 PM Elijah Newren wrote:
> with during the fast-import process. However, the whole reason for
> your patch is because checkpoints are in use *and* people are updating
> the repo during the fast-import process, so this area that was likely
> overlooked in the past now i
On Wed, May 15, 2019 at 11:10:17PM +, brian m. carlson wrote:
> > An alternative name is onError, probably more often used for event
> > callbacks. But I don't know, maybe errorBehavior is actually better.
>
> I'm going to use "errorStrategy", since we already have
> submodule.alternateErrorS
On Tue, May 14, 2019 at 12:23:31AM +, brian m. carlson wrote:
> 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.
On Tue, May 14, 2019 at 01:59:28AM +, brian m. carlson wrote:
> There are two aspects here which I think are worth discussing. Let's
> discuss the inheritance issue first.
>
> Order with multiple hooks matters. The best hook as an example for this
> is prepare-commit-msg. If I have a hook whi
Jeff King writes:
> On Thu, May 16, 2019 at 11:24:25AM +0900, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> >> lacked the "const" for that reason, but apparently some compilers
>> >> complain about the parameter type mismatch.
>> >
>> > We could be more explicit, as we know exact
On Wed, May 15, 2019 at 08:59:47PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, May 15 2019, Martin Langhoff wrote:
>
> > Spotted this on the internet...
> >
> > https://github.blog/2019-05-14-git-ransom-campaign-incident-report/
> >
> > Haven't hacked on git for a while, and I am not affil
On Wed, May 15, 2019 at 10:20:03PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Since this is going to have to happen anyway
>
> The SHA-1 <-> SHA-256 transition is planned to happen, but there's some
> strong opinions that this should be *only* for munging the content for
> hashing, not adding new
On Thu, May 16, 2019 at 10:43:03AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I agree that the current implementation (and probably any sane
> > implementation) would not send us a delta if we have not provided any
> > haves. But this does mean that a malicious server could send a cl
On Thu, May 16, 2019 at 11:24:25AM +0900, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> lacked the "const" for that reason, but apparently some compilers
> >> complain about the parameter type mismatch.
> >
> > We could be more explicit, as we know exactly that it is MS Visual C 201
On Thu, May 16, 2019 at 09:37:36AM +0900, Mike Hommey wrote:
> use_pack has its own error message on mmap error, but it can't be
> reached when using xmmap, which dies with its own error.
Makes sense. Amusingly this xmmap comes from c4712e4553 (Replace mmap
with xmmap, better handling MAP_FAILED.
On Thu, May 16, 2019 at 09:37:35AM +0900, Mike Hommey wrote:
> When a remote helper exposes the "import" capability, stdout of the
> helper is sent to stdin of a new fast-import process. This is done by
> setting the corresponding child_process's in field to the value of the
> out field of the hel
On Thu, May 16, 2019 at 09:48:02AM +0900, Mike Hommey wrote:
> > diff --git a/transport-helper.c b/transport-helper.c
> > index fcd2a58d0e..45cdf891ec 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -433,7 +433,7 @@ static int get_importer(struct transport *transport,
> >
Junio C Hamano wrote:
> Currently the only use of the function is to see if the log message
> matches with the given pattern (yes/no), but it is conceivable that
> new callers may want to prepare in-core data and use it to see if
> that matches the pattern, or even to _show_ the lines that match t
Hi,
Emily Shaffer wrote:
> grep_buffer creates a struct grep_source gs and calls grep_source()
> with it. However, gs.name is null, which eventually produces a
> segmentation fault in
> grep_source()->grep_source_1()->show_line() when grep_opt.status_only is
> not set.
Thanks for catching it. T
Emily Shaffer writes:
> I don't know if adding a placeholder name is the right answer (hence RFC
> patch).
>
> Jonathan Nieder proposed alternatively adding some check to grep_source()
> to ensure that if opt->status_only is unset, gs->name must be non-NULL
> (and yell about it if not), as well a
Johannes Schindelin writes:
>> lacked the "const" for that reason, but apparently some compilers
>> complain about the parameter type mismatch.
>
> We could be more explicit, as we know exactly that it is MS Visual C 2017
> that is complaining.
We could be, but I do not see a point of shaming on
Duy Nguyen writes:
> I think it depends on whether use actively use the index, or you
> mostly ignore it and always do "git commit -a" and friends.
>
> When you do use the index, the "worktree <-> index <-> HEAD" is the
> three stages that you are aware, in that order, and restoring from the
> "n
grep_buffer creates a struct grep_source gs and calls grep_source()
with it. However, gs.name is null, which eventually produces a
segmentation fault in
grep_source()->grep_source_1()->show_line() when grep_opt.status_only is
not set.
This seems to be unreachable from existing commands but is reac
Philip Oakley writes:
> While checking the html formatted git(1) manual page, it was noted
> that the link to https://git.github.io/htmldocs/git.html was formatted
> as code. Remove the backticks.
Good. I just ran
$ git grep '`https*://' Documentation/
to see if any hits I see are for
Derrick Stolee :
> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
> > The deeper problem is that I want something from Git that I cannot
> > have with 1-second granularity. That is: a unique timestamp on each
> > commit in a repository.
>
> This is impossible in a distributed version control system
Duy Nguyen writes:
>> That is an approach to make it harder to make mistakes by accepting
>> possibly a small wasted resource; but at that point, I think calling
>> repo_read_index() unconditionally from here and similar places would
>> be a simpler fix in the same spirit.
>
> For repo_read_index
Jeff King writes:
> I agree that the current implementation (and probably any sane
> implementation) would not send us a delta if we have not provided any
> haves. But this does mean that a malicious server could send a client
> into an infinite loop.
>
> Pretty unlikely, but should we put some k
Jason Pyeron :
> If we take the below example:
>
> committer Name 1557948240 -0400
>
> and we follow the rule that:
>
> 1. any trailing zero after the decimal point MUST be omitted
> 2. if there are no digits after the decimal point, it MUST be omitted
>
> This would allow:
>
> committer Name
On Thu, May 16, 2019 at 07:08:34AM +0900, Mike Hommey wrote:
> > >> - Except, well, fds being what they are, we in fact just closed a fd
> > >> from a packed_git->pack_fd. So, when use_pack is later called, and
> > >> tries to mmap data from that pack, it fails because the file
> > >> descri
On Tue, May 14, 2019 at 10:30 PM Junio C Hamano wrote:
>
> "Eric Rannaud" writes:
>
> > We now keep track of whether branches and tags have been changed by this
> > fast-import process since our last checkpoint (or startup). At the next
> > checkpoint, only refs and tags that new commands have ch
Derrick Stolee :
> What problem are you trying to solve where commit date is important?
I don't know what Jason's are. I know what mine are.
A. Portable commit identifiers
1. When I in-migrate a repository from (say) Subversion with
reposurgeon, I want to be able to patch change comments so tha
On Wed, May 15, 2019 at 07:56:09PM +0900, Mike Hommey wrote:
> Hi,
>
> I started getting a weird error message during some test case involving
> git-cinnabar, which is a remote-helper to access mercurial
> repositories.
>
> The error says:
> fatal: mmap failed: Bad file descriptor
>
> ... which
On Wed, May 15, 2019 at 07:53:40PM -0400, Jeff King wrote:
> On Thu, May 16, 2019 at 07:08:34AM +0900, Mike Hommey wrote:
>
> > > >> - Except, well, fds being what they are, we in fact just closed a fd
> > > >> from a packed_git->pack_fd. So, when use_pack is later called, and
> > > >> tries t
Ævar Arnfjörð Bjarmason :
> You put it key-values in the commit message and read it back out via
> git-interpret-trailers.
Speaking as a person who has done a lot of repository migrations, this
makes me shudder. It's fragile, kludgy, and does not maintain proper
separation of concerns.
The featu
On Mon, May 13, 2019 at 07:26:53PM -0700, Jonathan Nieder wrote:
> brian m. carlson wrote:
> In other words, use the standard config convention for the set of
> hooks, and treat the order in which they are invoked as a separate
> question. You could even use the hooks.d style alphabetical order
>
use_pack has its own error message on mmap error, but it can't be
reached when using xmmap, which dies with its own error.
Signed-off-by: Mike Hommey
---
packfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/packfile.c b/packfile.c
index 16bcb75262..6a66b605e9 100644
---
brian m. carlson wrote:
> Also, this is the way that most other programs on Unix do this behavior,
> and I think that is a compelling argument for this design in and of
> itself. I think Unix has generally made the best decisions in operating
> system design, and I aim to emulate it as much as pos
On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> Derrick Stolee :
>> What problem are you trying to solve where commit date is important?
>
> I don't know what Jason's are. I know what mine are.
>
> A. Portable commit identifiers
>
> 1. When I in-migrate a repository from (say) Subversion with
>
When a remote helper exposes the "import" capability, stdout of the
helper is sent to stdin of a new fast-import process. This is done by
setting the corresponding child_process's in field to the value of the
out field of the helper child_process.
The child_process API is defined to close the file
On 5/15/2019 7:32 PM, Eric S. Raymond wrote:
> Derrick Stolee :
>> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
>>> The deeper problem is that I want something from Git that I cannot
>>> have with 1-second granularity. That is: a unique timestamp on each
>>> commit in a repository.
>>
>> This is im
On Tue, May 14, 2019 at 02:10:55PM -0700, Jonathan Tan wrote:
> Support for lazy fetching should still generally be turned off in
> index-pack because it is used as part of the lazy fetching process
> itself (if not, infinite loops may occur), but we do need to fetch the
> REF_DELTA bases. (When f
On Tue, May 14, 2019 at 04:45:34AM -0400, Jeff King wrote:
> On Tue, May 14, 2019 at 02:14:19AM +, brian m. carlson wrote:
> > I think this is an improvement, not only because of the reasons you
> > mentioned, but because we remove the use of "type", which is not
> > guaranteed to be present in
On Tue, May 14, 2019 at 08:20:10PM +0700, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 7:24 AM brian m. carlson
> wrote:
> >
> > 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 t
On Tue, May 14, 2019 at 07:56:49PM +0700, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 7:24 AM brian m. carlson
> wrote:
> > - close(cp.in);
>
> In the old code, we close cp.in...
>
> > +int post_rewrite_rebase_hook(const char *name, const char *path, void
> > *input)
> > +{
> > + st
While checking the html formatted git(1) manual page, it was noted
that the link to https://git.github.io/htmldocs/git.html was formatted
as code. Remove the backticks.
While at it, add the https://git-scm.com/docs link which one reviewer
noted had linkable section headings.
Helped-by: Jeff King
This hopefully is a final version of the usage message to
show how to access the git(1) manual page.
The V3 change is Eric's suggestion to use 'See'.
I have also taken the opportunity [Patch 2/2] to pick up peff's suggestion
to include the git-scm doc link, and also correct the mis-quoting
of a l
It is not immediately obvious how to use the `git help` system to show
the git(1) page, with its overview and its background and coordinating
material, such as environment variables.
Let's simply list it as the last few words of the last usage line.
Signed-off-by: Philip Oakley
---
This follows
On Tue, May 14, 2019 at 05:12:39PM +0200, Johannes Schindelin wrote:
> Hi brian,
>
> On Tue, 14 May 2019, brian m. carlson wrote:
>
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 833ecb316a..29bf80e0d1 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -943,7 +943
On Tue, May 14, 2019 at 07:46:17PM +0700, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 7:24 AM brian m. carlson
> wrote:
> > - argv_array_push(&hook.args, p);
> > - while ((p = va_arg(args, const char *)))
> > - argv_array_push(&hook.args, p);
> > - hook.env = env;
>
On Wed, May 15, 2019 at 07:59:49PM +0200, Johannes Sixt wrote:
> Am 15.05.19 um 13:43 schrieb Ævar Arnfjörð Bjarmason:
> >
> > On Wed, May 15 2019, Mike Hommey wrote:
> >
> >> Hi,
> >>
> >> I started getting a weird error message during some test case involving
> >> git-cinnabar, which is a remot
On Wed, May 15 2019, Derrick Stolee wrote:
> On 5/15/2019 4:28 PM, Jason Pyeron wrote:
>> (please don’t cc me)
>
> Ok. I'll "To" you.
I'm a rebel!
>> and we follow the rule that:
>>
>> 1. any trailing zero after the decimal point MUST be omitted
>> 2. if there are no digits after the decimal p
On Wed, May 15, 2019 at 08:38:39PM +, Eric Wong wrote:
> I've also noticed objects/info/packs contains stale entries
> after repack/gc runs on current git.
>
> Tried adding reprepare_packed_git before update_server_info,
> but that didn't seem to work; so maybe something isn't cleared.
> Migh
fill_blame_origin() is a convenient place to store data that we will use
throughout the lifetime of a blame_origin. Some heuristics for
ignoring commits during a blame session can make use of this storage.
In particular, we will calculate a fingerprint for each line of a file
for blame_origins inv
From: Michael Platings
This algorithm will replace the heuristic used to identify lines from
ignored commits with one that finds likely candidate lines in the
parent's version of the file. The actual replacement occurs in an
upcoming commit.
The old heuristic simply assigned lines in the target
init_skiplist() took a file consisting of SHA-1s and comments and added
the objects to an oidset. This functionality is useful for other
commands and will be moved to oidset.c in a future commit.
In preparation for that move, this commit renames it to
oidset_parse_file() to reflect its more gener
Signed-off-by: Barret Rhoden
---
fsck.c | 35 ---
oidset.c | 35 +++
oidset.h | 8
3 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/fsck.c b/fsck.c
index a28cba6b05dd..58ff3c4de992 100644
--- a/fsck.c
+++
This patch set adds the ability to ignore a set of commits and their
changes when blaming. This can be used to ignore a commit deemed 'not
interesting,' such as reformatting.
The main change to this patchset from previous versions is the addition of
Michael's fuzzy fingerprinting logic. It's add
This commit integrates the fuzzy fingerprint heuristic into
guess_line_blames().
We actually make two passes. The first pass uses the fuzzy algorithm to
find a match within the current diff chunk. If that fails, the second
pass searches the entire parent file for the best match.
For an example
When ignoring commits, the commit that is blamed might not be
responsible for the change, due to the inaccuracy of our heuristic.
Users might want to know when a particular line has a potentially
inaccurate blame.
Furthermore, guess_line_blames() may fail to find any parent commit for
a given line
Commits that make formatting changes or function renames are often not
interesting when blaming a file. A user may deem such a commit as 'not
interesting' and want to ignore and its changes it when assigning blame.
For example, say a file has the following git history / rev-list:
---O---A---X---
The same code for splitting a blame_entry at a particular line was used
twice in blame_chunk(), and I'll use the helper again in an upcoming
patch.
Signed-off-by: Barret Rhoden
---
blame.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff
On 5/15/2019 4:28 PM, Jason Pyeron wrote:
> (please don’t cc me)
Ok. I'll "To" you.
> and we follow the rule that:
>
> 1. any trailing zero after the decimal point MUST be omitted
> 2. if there are no digits after the decimal point, it MUST be omitted
>
> This would allow:
>
> committer Name
(please don’t cc me)
> -Original Message-
> From: Derrick Stolee
> Sent: Wednesday, May 15, 2019 4:16 PM
>
> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
I disagree with many of Eric's reasons - and agree with most of
Derrick's refutation. But
>
> Changing the granularity of timestam
I've also noticed objects/info/packs contains stale entries
after repack/gc runs on current git.
Tried adding reprepare_packed_git before update_server_info,
but that didn't seem to work; so maybe something isn't cleared.
Might have time to investigate more this week, might not...
diff --git a/bu
On Wed, May 15, 2019 at 8:30 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, May 15 2019, Piotr Krukowiecki wrote:
>
> > Hello,
> >
> > I'm migrating two repositories from svn. I already did svn->git
> > migration (git-svn clone) and now have two git repositories.
> >
> > I would like to merge them
On Wed, May 15 2019, Eric S. Raymond wrote:
> The recent increase in vulnerability in SHA-1 means, I hope, that you
> are planning for the day when git needs to change to something like
> an elliptic-curve hash. This means you're going to have a major
> format break. Such is life.
Note that mo
On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
> The deeper problem is that I want something from Git that I cannot
> have with 1-second granularity. That is: a unique timestamp on each
> commit in a repository.
This is impossible in a distributed version control system like Git
(where the commits a
The recent increase in vulnerability in SHA-1 means, I hope, that you
are planning for the day when git needs to change to something like
an elliptic-curve hash. This means you're going to have a major
format break. Such is life.
Since this is going to have to happen anyway, let me request two
fu
On Wed, May 15 2019, Martin Langhoff wrote:
> Spotted this on the internet...
>
> https://github.blog/2019-05-14-git-ransom-campaign-incident-report/
>
> Haven't hacked on git for a while, and I am not affiliated with any of
> the stakeholders. However, reading it, I wanted to slam my head on th
From: Marc-André Lureau
This adds xfuncname and word_regex patterns for Rust, a quite
popular programming language. It also includes test cases for the
xfuncname regex (t4018) and updated documentation.
The word_regex pattern finds identifiers, integers, floats and
operators, according to the Ru
> > To resolve this, prefetch all missing REF_DELTA bases before attempting
> > to resolve them. This both ensures that all bases are attempted to be
> > fetched, and ensures that we make only one request per index-pack
> > invocation, and not one request per missing object.
>
> Hmm. I wonder whet
> > +# Converts bytes into their hexadecimal representation. For example,
> > +# "printf 'ab\r\n' | hex_unpack" results in '61620d0a'.
> > +hex_unpack () {
> > + perl -e '$/ = undef; $input = <>; print unpack("H2" x length($input),
> > $input)'
> > +}
> > +
> > +# Inserts $1 at the start of the
Am 15.05.19 um 13:43 schrieb Ævar Arnfjörð Bjarmason:
>
> On Wed, May 15 2019, Mike Hommey wrote:
>
>> Hi,
>>
>> I started getting a weird error message during some test case involving
>> git-cinnabar, which is a remote-helper to access mercurial
>> repositories.
>>
>> The error says:
>> fatal: m
Spotted this on the internet...
https://github.blog/2019-05-14-git-ransom-campaign-incident-report/
Haven't hacked on git for a while, and I am not affiliated with any of
the stakeholders. However, reading it, I wanted to slam my head on the
desk.
IIRC, git will sanely store a password elsewhere
Am 15.05.19 um 08:15 schrieb LI, BO XUAN:
> On Wed, May 15, 2019 at 1:57 PM Johannes Sixt wrote:
>>
>> Am 11.05.19 um 06:13 schrieb Boxuan Li:
>>> Octave pattern is almost the same as matlab. Besides,
>>> octave also uses '%%%' or '##' to begin code sections.
>>>
>>
>>> @@ -60,6 +60,11 @@ PATTERNS
On Wed, May 15 2019, Piotr Krukowiecki wrote:
> Hello,
>
> I'm migrating two repositories from svn. I already did svn->git
> migration (git-svn clone) and now have two git repositories.
>
> I would like to merge them into 1 git repository, but to merge also
> history - branches and tags.
>
> The
Hi Junio,
On Wed, 15 May 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> + test_path_is_file .git/MERGE_HEAD &&
> >> + test_path_is_file .git/MERGE_MODE &&
> >> + test_path_is_file .git/MERGE_MSG &&
> >> + test_path_is_file .git/MERGE_RR &&
> >
> > Isn't this a clear impleme
Hello,
I'm migrating two repositories from svn. I already did svn->git
migration (git-svn clone) and now have two git repositories.
I would like to merge them into 1 git repository, but to merge also
history - branches and tags.
The reason is that the svn repositories in fact represent one
"proj
Mijn naam is Eddy William. Ik ben van beroep advocaat. Ik wil je aanbieden
nabestaanden van mijn cliënt. Je ervaart de som van ($ 14,2 miljoen)
dollars die mijn cliënt voor zijn overlijden op de bank heeft achtergelaten.
Mijn klant is een burger van jouw land die stierf in auto-ongeluk met zijn vr
Hi all,
I discovered a potential bug regarding submodules and the use of
rebase and stash.
When setting the configuration submodule.recurse true, doing changes
in the super project and also given submodule, these changes are lost,
when doing a rebase or stash. The stash even shows these changes w
Greeting, Did you received my message? please let me
know.Thanks.Mr.David Keller.
On 15/05/2019 09:45, Ulrich Windl wrote:
reasoning for that.
It's that you are missing the idea behind the "Branches that track the
remote", which are local copies, but not YOUR branches. see below.
I clone the GitHub test repo. I get (a copy of) it all (the rtb's). Git
_creates_ a local branch '
Hello Bryan,
My project contains a Gradle build that is dependent on a
configuration found in a file called build.gradle. What I need to do
is run Gradle with a proper build.gradle file, meaning: if a new
build.gradle is staged, I will use that for my Gradle build, if not I
will use the latest app
[CC-list carried forward from the last SHA-1 thread I found]
Thought I'd sent a brief line about this since nobody else did.
There's a newly published "From Collisions to Chosen-Prefix Collisions
Application to Full SHA-1" paper making the news this week which builds
on the SHAttered attack: http
On Wed, May 15 2019, Duy Nguyen wrote:
> On Wed, May 15, 2019 at 09:38:59AM +, Poughon Victor wrote:
>> Hi
>>
>> I came across a description of a new git command currently in
>> development called 'git restore'. Since it's still not out, and the
>> original poster [1] seemed to ask for feedb
On Wed, May 15, 2019 at 12:59:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
> One thing that would be really useful (and maybe it even exists, I just
> haven't seen it in the mails) is some abbreviated cheatsheet style doc
> of before/after in the UI. Similar to cheatsheets like e.g.:
>
> https:/
On Tue, May 14 2019, Osipov, Michael wrote:
> Hi,
>
> Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
>> 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.
>>
>>
On Wed, May 15 2019, Mike Hommey wrote:
> Hi,
>
> I started getting a weird error message during some test case involving
> git-cinnabar, which is a remote-helper to access mercurial
> repositories.
>
> The error says:
> fatal: mmap failed: Bad file descriptor
>
> ... which was not making much s
Hi,
I started getting a weird error message during some test case involving
git-cinnabar, which is a remote-helper to access mercurial
repositories.
The error says:
fatal: mmap failed: Bad file descriptor
... which was not making much sense. Some debugging later, and it turns
out this is what ha
From: John Lin
Before this patch, there is inconsistency between the status
messages with hints and the ones without hints: there is an
empty line between the title and the file list if hints are
presented, but there isn't one if there are no hints.
This patch remove the inconsistency by removin
Before this patch, there is inconsistency between the status messages with
hints and the ones without hints: there is an empty line between the title
and the file list if hints are presented, but there isn't one if there are
no hints.
This patch remove the inconsistency by removing the empty lines
Hi Junio,
On Wed, 15 May 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do have a slight preference for going the _other_ way. There is no
> > need to mark the parameter as const in the definition. It is passed by
> > value, so nobody except the function body cares either way. And we ha
On Wed, May 15, 2019 at 09:38:59AM +, Poughon Victor wrote:
> Hi
>
> I came across a description of a new git command currently in
> development called 'git restore'. Since it's still not out, and the
> original poster [1] seemed to ask for feedback, I though I'd send
> some here. Hope that's
Hi
I came across a description of a new git command currently in development
called 'git restore'. Since it's still not out, and the original poster [1]
seemed to ask for feedback, I though I'd send some here. Hope that's ok!
Reading the documentation [2] I find it very confusing. In particular
On Wed, May 15, 2019 at 12:16 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > Also from my earlier message, if you missed it:
> >
> > I also wondered if we should simply allocate an empty index whenever
> > we have a non-toplevel "struct repository", which might be less
> > surprising
Johannes Schindelin writes:
>> See a few nits below, none of which are necessarily worth a re-roll.
>
> Thanks!
>
> Junio, do you agree, do you want to fix it up on your side?
I think you'd see all of them in what I've pushed out.
>> > +one-off testing you should report the behavior difference
Johannes Schindelin writes:
> As far as `--no-index` is concerned, all files are untracked anyway. There
> is no index, so there are no staged/committed/tracked files.
> ...
Ah, I see I completely misspoke; sorry, there should be no "pretend
as if there were no --dir-diff".
In the normal usage,
Hi Jonathan,
On Tue, 14 May 2019, Jonathan Tan wrote:
> When fetching, the client sends "have" commit IDs indicating that the
> server does not need to send any object referenced by those commits,
> reducing network I/O. When the client is a partial clone, the client
> still sends "have"s in this
>>> Philip Oakley schrieb am 15.05.2019 um 09:34 in
Nachricht :
> On 14/05/2019 12:49, Ulrich Windl wrote:
>> Hi!
>>
>> The confusing part actually is for me:
>> "git clone" does NOT "Clone a repository into a new directory", but "clone
> the current branch into a new directory" (IMHO).
>> So I w
Hi Jonathan,
On Tue, 14 May 2019, Jonathan Tan wrote:
> diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh
> index 9a8f9886b3..7cc0c71556 100755
> --- a/t/t5616-partial-clone.sh
> +++ b/t/t5616-partial-clone.sh
> @@ -244,11 +244,25 @@ test_expect_success 'fetch what is specified on
Hi Eric,
On Tue, 14 May 2019, Eric Sunshine wrote:
> On Tue, May 14, 2019 at 5:19 AM Johannes Schindelin via GitGitGadget
> wrote:
> > The stash.useBuiltin variable introduced in 90a462725e ("stash:
> > optionally use the scripted version again", 2019-02-25) was turned on by
> > default, but had
Hi Junio,
On Wed, 15 May 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Tue, 14 May 2019, Junio C Hamano wrote:
> >
> >> * js/difftool-no-index (2019-05-09) 1 commit
> >> - difftool --no-index: error out on --dir-diff (and don't crash)
> >>
> >> The "--dir-diff" mode of "gi
On Wed, May 15, 2019 at 4:11 AM Philip Oakley wrote:
> It is not immediately obvious how to use the `git help` system to show
> the git(1) page, with its overview and its background and coordinating
> material, such as environment variables.
>
> Let's simply list it as the last few words of the la
1 - 100 of 103 matches
Mail list logo
