Denton Liu writes:
> I was in the process of deprecating `git diff ..` as
> discussed here[1].
>
> [1]: https://public-inbox.org/git/xmqqmumy6mxe@gitster-ct.c.googlers.com/
I didn't (and don't) advocate such a deprecation, FWIW, in that
message. I simply do not think it is worth the cost.
Denton Liu writes:
> =>content="$(git diff HEAD^! | tail -n 1)"
> ...
> It gets caught in my attempt to only deprecate ..'s. Technically, it's
> undocumented behaviour and it only happens to work because git-diff
> accept ranges but it doesn't operate in an intuitive way.
It reuses t
Jeff King writes:
> The problem to me is not that the steps that a developer has to do, but
> rather that we are dependent on the upstream project to make a simple
> fix (which they may not agree to do, or may take a long time to do).
Yeah. In practice, I think the recommended way to work for a
On Mon, Mar 11 2019, Jeff King wrote:
> On Mon, Mar 11, 2019 at 07:15:12PM +0100, Thomas Braun wrote:
>
>> Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
>> > On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
>> >> And AFAIK there is no good way to
>> >> modify the submodule-provided content as par
On Tue, Mar 12 2019, Eric Wong wrote:
> Jeff King wrote:
>> On Sat, Mar 09, 2019 at 02:49:44AM +, Eric Wong wrote:
>> > It would make life easier for people new to hosting git servers
>> > (and hopefully reduce centralization :)
>>
>> I do think they're a net win for people hosting git serv
On Mon, Mar 11 2019, Eric Sunshine wrote:
> [cc:+Ævar]
>
> On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
>> I enabled self tests for Solaris. Solaris has some anemic utilities so
>> I put /usr/gnu/bin first on-path.
>
> The first question is if you are really running GNU 'sed'? My guess
Hi Elijah,
thanks for explaining the motivation behind the current solution!
I still believe the situation could be improved without breaking compatibility:
* in the documentation the paragraph about "Omitting the from command" should
change "existing branches" into something like "existing bran
On Mon, Mar 11, 2019 at 09:18:47PM -0300, Matheus Tavares Bernardino wrote:
> I've been thinking on how I could implement a test to estimate the
> lock contention but had no success until now. I wanted to try
> mutrace[2] but couldn't install it; I tried valgrind's drd but it
> didn't seem to repor
On Tue, Mar 12, 2019 at 5:02 PM Duy Nguyen wrote:
> We have to analyze case by case. It may turn out that there are many
s/are/aren't/
> opportunity to utilize multi threads. I think checkout is definitely a
> good candidate. For "git diff" and "git log" maybe you can try "perf"
> to see how muc
On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
wrote:
> This works without problems most of the time (well, usually there are
> conflicts and all, but that's a burden I have to carry). However,
> sometimes I notice that git fails with:
>
> # git rebase origin/master
> ...
> Applying:
On Tue, Mar 12, 2019 at 03:13:03AM +, Eric Wong wrote:
> > I do think they're a net win for people hosting git servers. But if
> > that's the goal, I think at most you'd want to make bitmaps the default
> > for bare repos. They're really not much help for normal end-user repos
> > at this poin
On Tue, Mar 12, 2019 at 04:27:57PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The problem to me is not that the steps that a developer has to do, but
> > rather that we are dependent on the upstream project to make a simple
> > fix (which they may not agree to do, or may take a long
Hi Elijah
On 11/03/2019 22:04, Elijah Newren wrote:
On Mon, Mar 11, 2019 at 1:51 PM Phillip Wood wrote:
On 11/03/2019 17:24, Elijah Newren wrote:
On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy
On Tue, Mar 12, 2019 at 09:53:41AM +0100, Ævar Arnfjörð Bjarmason wrote:
> There's a at least a couple of aspects to this.
>
> One is whether we should have the submodule in
> sha1collisiondetection/. I agree that's probably a bad idea now
> per-se. Honestly I wasn't expecting the answer when I s
Hi Elijah
On 11/03/2019 17:54, Elijah Newren wrote:
A few other comments that I thought of while responding elsewhere in
the thread that didn't make sense to include elsewhere...
On Fri, Mar 8, 2019 at 2:00 AM Nguyễn Thái Ngọc Duy wrote:
+-m::
+--merge::
+ If you have local modificatio
Hi Denton
I've got a couple of small comments, but this looks fine to me
On 11/03/2019 03:42, Denton Liu wrote:
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Signed-off-by: Denton Liu
---
Do
I am interested to do a project on improving git log --oneline.I can program in
C language,I have learnt how to send patches and I am also comfortable with
using git.I wanted to know what are the prerequisites for doing the project.Can
I get some help regarding this matter.
On Tue, Mar 12, 2019 at 12:03 AM Phillip Wood wrote:
>
> Hi Duy
>
> On 11/03/2019 11:47, Duy Nguyen wrote:
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > wrote:
> >>
> >>
> >> Hi Duy
> >>
> >> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> >>> "git checkout" doing too many things is a
On Tue, Mar 12, 2019 at 12:25 AM Elijah Newren wrote:
>
> On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
> >
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > wrote:
> > >
> > > Hi Duy
> > >
> > > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > > "git checkout" doing too many thing
On Tue, Mar 12, 2019 at 06:49:54AM -0400, Jeff King wrote:
> I'm not sure what we're trying to accomplish with this unpacking,
> though. Running "git repack -ad" should generate bitmaps whether the
> objects were already in a single pack or not. So I think this test can
> just be:
>
> git clone
On Tue, Mar 12 2019, Jeff King wrote:
> On Tue, Mar 12, 2019 at 09:53:41AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> There's a at least a couple of aspects to this.
>>
>> One is whether we should have the submodule in
>> sha1collisiondetection/. I agree that's probably a bad idea now
>> per-se.
On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood wrote:
> > then it'd make sense to use --recreate instead. But if you
> > think some might adopt a workflow where they just use -C without first
> > trying -c ("create this branch, and I don't care if I made it before
> > just create it here"), then --
Corentin BOMPARD writes:
> Applying CodingGuidelines about monospace on pathnames and URLs.
>
> See Documentation/CodingGuidelines.txt for more information.
>
> Signed-off-by: Corentin BOMPARD
> Signed-off-by: Nathan BERBEZIER
> Signed-off-by: Pablo CHABANNE
> Signed-off-by: Matthieu MOY
> --
The sparse connectivity algorithm saves a whole lot of time when there
are UNINTERESTING trees around.
---
Documentation/git-repack.txt | 4
builtin/repack.c | 10 ++
2 files changed, 14 insertions(+)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.t
From: Christian Couder
The callers of the fetch_object() and fetch_objects() might
be interested in knowing if these functions succeeded or not.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
fetch-object.c | 13 -
fetch-object.h | 4 ++--
sha1-file.c| 4 +
From: Christian Couder
The promisor-remote.{c,h} files will contain functions to
manage many promisor remotes.
We expect that there will not be a lot of promisor remotes,
so it is ok to use a simple linked list to manage them.
Helped-by: Jeff King
Signed-off-by: Christian Couder
---
Makefile
This path series is a follow up from the "remote odb" patch series
that I sent last year, which were a follow up from previous
series. See the links section for more information.
The goal of this patch series is to make it possible to have and to
fetch missing objects from multiple remotes instead
From: Christian Couder
We will need to reinitialize the promisor remote configuration
as we will make some changes to it in a later commit.
Signed-off-by: Christian Couder
---
promisor-remote.c | 14 --
promisor-remote.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
di
A remote specified using the extensions.partialClone config
option should be considered a promisor remote too.
This remote should be at the end of the promisor remote list,
so that it is used only if objects have not been found in other
remotes.
Signed-off-by: Christian Couder
---
promisor-remo
As the infrastructure for more than one promisor remote
has been introduced in previous patches, we can remove
code that forbids the registration of more than one
promisor remote.
Signed-off-by: Christian Couder
---
builtin/fetch.c | 20 +---
1 file changed, 5 insertions(+), 15 d
Instead of using the repository_format_partial_clone global
and fetch_objects() directly, let's use has_promisor_remote()
and promisor_remote_get_direct().
This way all the configured promisor remotes will be taken
into account, not only the one specified by
extensions.partialClone.
Also when clo
This makes it possible to specify a different partial clone
filter for each promisor remote.
Signed-off-by: Christian Couder
---
builtin/fetch.c | 2 +-
list-objects-filter-options.c | 27 +++
list-objects-filter-options.h | 3 ++-
promisor-remote.c
From: Christian Couder
This is implemented for now by calling fetch_objects(). It fetches
from all the promisor remotes.
Signed-off-by: Christian Couder
---
promisor-remote.c | 17 +
promisor-remote.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/promisor-remote.c b/p
From: Christian Couder
This shows that it is now possible to fetch objects from more
than one promisor remote, and that fetching from a new
promisor remote can configure it as one.
Signed-off-by: Christian Couder
---
t/t0410-partial-clone.sh | 47 +++-
1 fil
Signed-off-by: Christian Couder
---
Documentation/config/remote.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/config/remote.txt b/Documentation/config/remote.txt
index 6c4cad83a2..a8e6437a90 100644
--- a/Documentation/config/remote.txt
+++ b/Documentation/config/re
While at it, let's remove a reference to ODB effort as the ODB
effort has been replaced by directly enhancing partial clone
and promisor remote features.
Signed-off-by: Christian Couder
---
Documentation/technical/partial-clone.txt | 83 ---
1 file changed, 58 insertions(+),
This patch series improves handling of very large repositories, as generated
by, for example, bup (https://github.com/bup/bup). Prolonged operation
thereof creates quite a lot of small pack files; repacking improves
filesystem performance of the objects/pack directory, but is quite
expensive, in t
Specifically: number of kept packs, size of kept packs (and indexes),
and number of objects in kept packs.
Signed-off-by: Nathaniel Filardo
---
builtin/count-objects.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/builtin/count-objects.c b/builtin/count-o
If the user is careful to mark .pack files as kept only when they refer
to (other) kept packs, then we can rely on this when walking the object
graph in subsequent repack operations and reduce the time and memory
spent building the object graph.
Towards that end, then, teach git repack to enumerat
The only caller that passes a non-zero value to prepare_revision_walk
after this patch is builtin/pack-objects. Without this, sparsity seems
to do little good therein, as prepare_revision_walk will densely
propagate UNINTERESTING flags from trees to tree contents, before
mark_edges_uninteresting h
On 3/12/2019 9:18 AM, Nathaniel Filardo wrote:
> The sparse connectivity algorithm saves a whole lot of time when there
> are UNINTERESTING trees around.
Interesting! Do you have some performance numbers to include with
this statement?
> @@ -48,6 +49,10 @@ static int repack_config(const char *var,
On 3/12/2019 9:18 AM, Nathaniel Filardo wrote:
> The only caller that passes a non-zero value to prepare_revision_walk
> after this patch is builtin/pack-objects. Without this, sparsity seems
> to do little good therein, as prepare_revision_walk will densely
> propagate UNINTERESTING flags from tr
Mes salutations au nom du Seigneur.
Je suis Mme Erica Nomani, une veuve âgée de 58 ans de la République
d'Azerbaïdjan mais vivant actuellement au Angleterre (England). Je suis
légalement marié au regretté Dr Castillo Nomani, qui travaillait pour
l'ambassade d'Azerbaïdjan en Angleterre avant son
On 2019-03-12 13:47, Derrick Stolee wrote:
On 3/12/2019 9:18 AM, Nathaniel Filardo wrote:
The sparse connectivity algorithm saves a whole lot of time when there
are UNINTERESTING trees around.
Interesting! Do you have some performance numbers to include with
this statement?
Not UNINTERESTING
In commit 735285b403 ("am: fix signoff when other trailers are present",
2017-08-08) tests using variable $signoff were rewritten and it is no
longer used, so just remove it from the test setup.
Signed-off-by: Andrei Rybak
---
t/t4150-am.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-
On Tue, Mar 12, 2019 at 8:19 AM Duy Nguyen wrote:
> On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood
> wrote:
> > I tend to agree with this but that's probably because I don't really use
> > checkout -B. I'm not sure if it's widely used or not. I do find checkout
> > -b convenient though.
>
> Yeah I
On Tue, Mar 12, 2019 at 9:16 AM Matthieu Moy wrote:
> Corentin BOMPARD writes:
> > Changes: We listen to Matthieu MOY and Eric SUNSHINE's remarks about
> > our mistakes on the last patch.
>
> This addresses all my previous remarks, so this (patches 1 and 2) is now
>
> Reviewed-by: Matthieu Moy
On Tue, Mar 12, 2019 at 4:06 AM Phillip Wood wrote:
>
> Hi Elijah
>
> On 11/03/2019 17:54, Elijah Newren wrote:
> > A few other comments that I thought of while responding elsewhere in
> > the thread that didn't make sense to include elsewhere...
> >
> > On Fri, Mar 8, 2019 at 2:00 AM Nguyễn Thái
On Tuesday, March 12 2019, Duy Nguyen wrote:
> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
> wrote:
>> This works without problems most of the time (well, usually there are
>> conflicts and all, but that's a burden I have to carry). However,
>> sometimes I notice that git fails with:
>
On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine wrote:
>
> On Tue, Mar 12, 2019 at 8:19 AM Duy Nguyen wrote:
> > On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood
> > wrote:
> > > I tend to agree with this but that's probably because I don't really use
> > > checkout -B. I'm not sure if it's widely us
From: Jeff King
Signed-off-by: Ramsay Jones
---
Hi Jeff,
I recently tried (yet again) to tidy up some old branches. When I get
around to doing a 'git gc; git fsck' I always take a quick look at
the 'dangling' commits, just before a 'git gc --prune=now'.
I had no recollection of this commit, f
On Tue, Mar 12, 2019 at 4:58 AM Duy Nguyen wrote:
> On Tue, Mar 12, 2019 at 12:25 AM Elijah Newren wrote:
> > On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
> > > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > > wrote:
> > > > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > > > "g
never noticed this before ... when i do a regular "git commit" and
enter my "vi" edit session and change my mind, i can bail with ":q!",
regardless of what i've set up as a commit message, and i'll see:
Aborting commit due to empty commit message.
however, i was just playing with "git rever
On Mär 12 2019, Junio C Hamano wrote:
> I however think it may be worth making sure that our docs do not
> encourage "diff A..B" and teach "diff A B" when comparing two
> endpoints. That can be done without changing anything in the code.
The nice thing about "diff A..B" is that you can c&p the
On Tue, Mar 12, 2019 at 12:51 PM Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine wrote:
> > It's not much of a datapoint, but I do use "git checkout -B" (and
> > therefore would use "git switch -C") periodically (in addition to
> > -b/-c, which I use all the time). And, conve
On 12/03/2019 16:55, Ramsay Jones wrote:
> From: Jeff King
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Jeff,
>
> I recently tried (yet again) to tidy up some old branches. When I get
> around to doing a 'git gc; git fsck' I always take a quick look at
> the 'dangling' commits, just before
When cloning with --recurse-submodules a superproject with at least one
submodule with HEAD pointing to an unborn branch, the clone goes
something like this:
Cloning into 'test'...
Submodule '' () registered for path ''
Cloning into ''...
fatal: Couldn't fi
On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day wrote:
>
> never noticed this before ... when i do a regular "git commit" and
> enter my "vi" edit session and change my mind, i can bail with ":q!",
> regardless of what i've set up as a commit message, and i'll see:
>
> Aborting commit due to
On 2019-03-12 16:48, Eric Sunshine wrote:
> Thanks. A few comments:
>
> In patch 1/2:
>
> * drop the full stop from the first line of the commit message
>
> * s/futur/future/ in the commit message
>
> * s/There are false/& positives/ in the commit message
>
> * s/both, It/both, it/
Also,
* s/inco
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> wrote:
> >
> > never noticed this before ... when i do a regular "git commit" and
> > enter my "vi" edit session and change my mind, i can bail with ":q!",
> > regardless of what i've set up as a com
On Tue, Mar 12, 2019 at 01:22:51PM -0400, Robert P. J. Day wrote:
>
> never noticed this before ... when i do a regular "git commit" and
> enter my "vi" edit session and change my mind, i can bail with ":q!",
> regardless of what i've set up as a commit message, and i'll see:
>
> Aborting com
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> wrote:
> >
> > never noticed this before ... when i do a regular "git commit" and
> > enter my "vi" edit session and change my mind, i can bail with ":q!",
> > regardless of what i've set up as a com
On Tue, Mar 12, 2019 at 11:01 AM Robert P. J. Day wrote:
>
> On Tue, 12 Mar 2019, Bryan Turner wrote:
>
> > On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> > wrote:
> > >
> > > never noticed this before ... when i do a regular "git commit" and
> > > enter my "vi" edit session and change my
On Tue, 12 Mar 2019, Kevin Daudt wrote:
... snip ...
> The only reason why `:q!` works just for comitting is because there
> is no default message, so the final message ends up empty.
>
> When you do things like git revert or git commit --amend, there is
> already a commit message, which you are
On Tue, Mar 12, 2019 at 11:14 AM Robert P. J. Day wrote:
>
> On Tue, 12 Mar 2019, Bryan Turner wrote:
>
> > On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> > wrote:
> > >
> > > never noticed this before ... when i do a regular "git commit" and
> > > enter my "vi" edit session and change my
On Tue, Mar 12, 2019 at 02:14:37PM -0400, Robert P. J. Day wrote:
> On Tue, 12 Mar 2019, Bryan Turner wrote:
>
> > On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> > wrote:
> > >
> > > never noticed this before ... when i do a regular "git commit" and
> > > enter my "vi" edit session and ch
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 11:01 AM Robert P. J. Day
> wrote:
> >
> > On Tue, 12 Mar 2019, Bryan Turner wrote:
> >
> > > On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> > > wrote:
> > > >
> > > > never noticed this before ... when i do a regular "g
On Tue, Mar 12, 2019 at 11:21 AM Robert P. J. Day wrote:
>
> On Tue, 12 Mar 2019, Kevin Daudt wrote:
>
> ... snip ...
>
> > The only reason why `:q!` works just for comitting is because there
> > is no default message, so the final message ends up empty.
> >
> > When you do things like git revert
On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
wrote:
> On Tuesday, March 12 2019, Duy Nguyen wrote:
>
> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
> > wrote:
> >> This works without problems most of the time (well, usually there are
> >> conflicts and all, but that's a burden
On Tuesday, March 12 2019, Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
> wrote:
>> On Tuesday, March 12 2019, Duy Nguyen wrote:
>>
>> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
>> > wrote:
>> >> This works without problems most of the time (well, usu
On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior
wrote:
>
> On Tuesday, March 12 2019, Elijah Newren wrote:
>
> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
> > wrote:
> >> On Tuesday, March 12 2019, Duy Nguyen wrote:
> >>
> >> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Jun
On Tuesday, March 12 2019, Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior
> wrote:
>>
>> On Tuesday, March 12 2019, Elijah Newren wrote:
>>
>> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
>> > wrote:
>> >> On Tuesday, March 12 2019, Duy Nguyen wrote:
>>
On Tue, Mar 12, 2019 at 05:39:13PM +, Ramsay Jones wrote:
> On 12/03/2019 16:55, Ramsay Jones wrote:
> > From: Jeff King
> >
> > Signed-off-by: Ramsay Jones
Could definitely use a commit message. I think it's something like:
We use the "offset" variable for two purposes. It's the offset
Hello there,
Apologies for "jumping in". I was mentioned in [PATCH 0/3] but then for
a (good) reason or another, I wasn't CC-ed in the patches.
I was the original "suggester" for this feature in the mailing list
(https://public-inbox.org/git/cahmhmxxxo4zxcribje2k3mwgwaj7kga_achuemyciesgoc_...@mai
On Tue, Mar 12, 2019 at 01:09:42PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > To be clear, I do sympathize with the notion that not pulling things
> > in-tree keeps our relationship with upstream more disciplined, and that
> > has value. I'm just not altogether clear how much it's really hurt us
>
On Tue, Mar 12 2019, Andreas Schwab wrote:
> On Mär 12 2019, Junio C Hamano wrote:
>
>> I however think it may be worth making sure that our docs do not
>> encourage "diff A..B" and teach "diff A B" when comparing two
>> endpoints. That can be done without changing anything in the code.
>
> Th
On Sun, Mar 10, 2019 at 11:37:55PM -0400, Jeff King wrote:
> Unfortunately, I don't think sha1dc currently supports #defines in that
> direction. The only logic is "if we are on intel, do unaligned loads"
> and "even if we are not on intel, do it anyway". There is no "even if we
> are on intel, do
On Tue, Mar 12 2019, Jeff King wrote:
> On Sun, Mar 10, 2019 at 11:37:55PM -0400, Jeff King wrote:
>
>> Unfortunately, I don't think sha1dc currently supports #defines in that
>> direction. The only logic is "if we are on intel, do unaligned loads"
>> and "even if we are not on intel, do it anyw
On Tue, Mar 12, 2019 at 10:17:56PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > Here's a commit which updates Git to use the new feature. I've tested it
> > with both the in-tree and submodule builds like:
> >
> > make DC_SHA1_SUBMODULE=Yes SANITIZE=undefined && (cd t && ./t0001-*)
> > make DC_SH
In the contributing guide and PR template seen by people who open pull
requests on GitHub, we mention the submitGit tool, which gives an
alternative to figuring out the mailing list. These days we also have
the similar Git Git Gadget tool, and we should make it clear that this
is also an option.
W
Hi Pierre,
On Mon, 11 Mar 2019, Garcia, Pierre wrote:
> Hello Johannes,
>
> I installed the following snapshot on the problematic machine:
> Sun, 10 Mar 2019 17:37:25 +0100
> (commit eb5d06f545)
> Git for Windows installer: 64-bit
>
> And the problem is gone! No more issue!
Thank you for confi
On 12/03/2019 20:26, Jeff King wrote:
> On Tue, Mar 12, 2019 at 05:39:13PM +, Ramsay Jones wrote:
>
>> On 12/03/2019 16:55, Ramsay Jones wrote:
>>> From: Jeff King
>>>
>>> Signed-off-by: Ramsay Jones
>
> Could definitely use a commit message. I think it's something like:
>
> We use th
Hi Thomas,
On Mon, 11 Mar 2019, Thomas Gummerer wrote:
> Passing the pathspec by value is potentially confusing, as the copy is
> only a shallow copy, so save the overhead of the copy, and pass the
> pathspec struct as a pointer.
Not only confusing, but also wasteful ;-)
> In addition use copy_
Hi Jack,
On Mon, 11 Mar 2019, Jack Adrian Zappa wrote:
> Are you sure that you have 8.3 active on the partition you are using?
> IIRC, It is not on by default anymore.
It is still on by default on system drives (usually C:), but it is
switched off on other drives by default.
Yet another reason
On Tue, 12 Mar 2019 at 21:34, Jeff King wrote:
...
> We could continue to mention _both_ tools, but it's probably better to
> pick one in order to avoid overwhelming the user with choice. After all,
> one of the purposes here is to reduce friction for first-time or
> infrequent contributors. And t
Hi,
please always Cc: the potential mentors of a microproject when you
want to discuss it. That makes it much more likely for the mentors to
notice your email and discuss it for you. I added Christian, who's
listed as possible mentor on the project page to Cc: here.
On 03/12, Sushma Unnibhavi w
I'm still working on fixing a race condition I encountered in "gc"
recently, but am not 100% sure of the fix. So I thought I'd send a
braindump of what I have so far in case it jolts any memories.
The problem is that when we "gc" we run "reflog expire --all". This
iterates over the reflogs, and ta
Add a definition for what overlay means in the context of git, to
clarify the recently introduced overlay-mode in git checkout.
Helped-by: Elijah Newren
Signed-off-by: Thomas Gummerer
---
v2 addresses Elijah's comments (thanks!), using the wording he
suggested in [*1*], which I agree is slightl
On 03/12, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Mon, 11 Mar 2019, Thomas Gummerer wrote:
>
> > Passing the pathspec by value is potentially confusing, as the copy is
> > only a shallow copy, so save the overhead of the copy, and pass the
> > pathspec struct as a pointer.
>
> Not only co
On Wed, Mar 13, 2019 at 6:30 AM Thomas Gummerer wrote:
>
> Add a definition for what overlay means in the context of git, to
> clarify the recently introduced overlay-mode in git checkout.
>
> Helped-by: Elijah Newren
> Signed-off-by: Thomas Gummerer
> ---
>
> v2 addresses Elijah's comments (tha
On Wed, Mar 13, 2019 at 12:26 AM Andreas Schwab wrote:
>
> On Mär 12 2019, Junio C Hamano wrote:
>
> > I however think it may be worth making sure that our docs do not
> > encourage "diff A..B" and teach "diff A B" when comparing two
> > endpoints. That can be done without changing anything in t
Thomas Gummerer writes:
> diff --git a/Documentation/glossary-content.txt
> b/Documentation/glossary-content.txt
> index 023ca95e7c..53df6ecb0a 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -287,6 +287,13 @@ This commit is referred to as a "mer
Ævar Arnfjörð Bjarmason writes:
> I'm still working on fixing a race condition I encountered in "gc"
> recently, but am not 100% sure of the fix. So I thought I'd send a
> braindump of what I have so far in case it jolts any memories.
>
> The problem is that when we "gc" we run "reflog expire --a
Thomas Gummerer writes:
>> I see that you added the `const` keyword. While it does not hurt, I would
>> probably not have bothered...
>
> That's fair, I went with what seemed most common in the codebase.
> More than half the parameters seem to be using "const struct
> pathspec", so that seems to
Jeff King writes:
> infrequent contributors. And there are a few reasons to prefer GGG:
>
> 1. submitGit seems to still have a few rough edges. E.g., it doesn't
> munge timestamps to help threaded mail readers handled out-of-order
> delivery.
Hmph, I had an impression that the recent
Jeff King wrote:
> OK. I still think of bitmaps as something that might need manual care
> and feeding, but I think that may be leftover superstition. I can't
> offhand think of any real downsides to this.
It's a _relatively_ new feature to long-time users like us, so
maybe the "new == immature"
Eric Sunshine writes:
>> Do you use checkout -B only when checkout -b fails, or do you use it
>> pre-emptively? The former would suggest we should use a name like
>> --recreate, while the latter would suggest a name more like
>> --force-create.
>
> It doesn't come up often, but I use "git checko
Jonathan Tan writes:
> When cloning with --recurse-submodules a superproject with at least one
> submodule with HEAD pointing to an unborn branch, the clone goes
> something like this:
>
> Cloning into 'test'...
>
> Submodule '' () registered for path ''
> Cloning into ''
Jeff King writes:
> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/)
> to
The pointed-at page calls the tool a single word with three capital
Gs without SP in it. We should match it here an
Andrei Rybak writes:
> In commit 735285b403 ("am: fix signoff when other trailers are present",
> 2017-08-08) tests using variable $signoff were rewritten and it is no
> longer used, so just remove it from the test setup.
>
> Signed-off-by: Andrei Rybak
> ---
> t/t4150-am.sh | 4 +---
> 1 file
1 - 100 of 112 matches
Mail list logo
