I am on git version 2.20.0
$ git remote
does not show remotes configured in named files in $GIT_DIR/remotes/
I do not think that this is the intended behavior.
In particular:
$ git init --bare test.git
Initialized empty Git repository in /home/guraltsev/admin/test/git/test.git/
$ cd test.git
The latest maintenance release Git v2.20.1 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.20.1'
tag and the 'maint' branch that the tag points at:
url = https://kern
On Fri, Dec 14, 2018 at 04:51:54PM -0500, Mr&Mrs D wrote:
> Thanks for looking to it - git attributes was added in
> 4b0863a8b834c5804fd3a568ed56ff85b27acdeb
>
> The file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23
>
> So you mean to say that because a gitattributes was adde
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe a
--
Good day,
I have interest to set up a profitable Joint Venture Investment
on Real Estate or any viable business within your region/area.
Kindly contact me via my private email address for further discussion:
mansourmoh...@gmail.com
Regards
Mohamed Mansour,
CEO Mansour Group
Christian Halstrick writes:
> Question:
> - is this because the index which jgit created is so corrupt that only
> special commands
> like "git status" can repair it?
No.
> - or is "git apply" not trying hard enough to consume a index with
> smudged entries
No.
Lower level "plumbing" commands
Jeff King writes:
> I actually started by doing that, but "struct serve_options" is not
> currently known by ls-refs.c, upload-pack.c, etc. So they'd have to
> start including "serve.h". I don't think that's the end of the world,
> but it felt like a funny mutual circular to me (my mental model n
Michał Górny writes:
> Just a suggestion: since the raw signature is not very useful without
> the commit data to check it against, and the commit data is non-trivial
> to construct (requires mangling raw data anyway), maybe you could either
> add another placeholder to get the data for signature
In push_submodule(), because we do not actually need access to objects
in the submodule, do not invoke add_submodule_odb().
(for_each_remote_ref_submodule() does not require access to those
objects, and the actual push is done by spawning another process,
which handles object access by itself.)
Th
Pass the object pool to free_commit_buffer and release_commit_memory,
such that we can eliminate access to 'the_repository'.
Also remove the TODO in release_commit_memory, as commit->util was
removed in 9d2c97016f (commit.h: delete 'util' field in struct commit,
2018-05-19)
Signed-off-by: Stefan
git_pathdup uses the_repository internally, but the macro
REPO_GIT_PATH_FUNC is specifically made for arbitrary repositories.
Switch to repo_git_path which works on arbitrary repositories.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
path.h | 2 +-
1 file changed, 1 insertion(
Convert all functions to handle arbitrary repositories in commit-graph.c
that are used by functions taking a repository argument already.
Notable exclusion is write_commit_graph and its local functions as that
only works on the_repository.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hama
dade47c06c (commit-graph: add repo arg to graph readers, 2018-07-11)
brought more independence from the_repository to the commit graph, however
it was not completely independent of the_repository, as the previous
patches show.
To ensure we're not accessing the_repository by accident, we'd ideally
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
contrib/coccinelle/the_repository.pending.cocci | 10 ++
pretty.c| 15 ---
pretty.h| 7 ++-
3 files changed, 24 insertions(+), 8
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit.c| 6 --
commit.h| 7 ++-
contrib/coccinelle/the_repository.pending.cocci | 8
3 files changed, 18 insertions(+), 3 deletions(-)
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit-reach.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/commit-reach.c b/commit-reach.c
index 81015830cb..b3b1f62aba 100644
--- a/commit-reach.c
+++ b/commit-reach.c
@@ -216,7 +216,8 @@ static
Similarly to previous patches, the get_merge_base functions are used
often in the code base, which makes migrating them hard.
Implement the new functions, prefixed with 'repo_' and hide the old
functions behind a wrapper macro.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
com
As read_object_file is a widely used function (which is also regularly used
in new code in flight between master..pu), changing its signature is painful
is hard, as other series in flight rely on the original signature. It would
burden the maintainer if we'd just change the signature.
Introduce re
Just like the previous commit, parse_commit and friends are used a lot
and are found in new patches, so we cannot change their signature easily.
Re-introduce these function prefixed with 'repo_' that take a repository
argument and keep the original as a shallow macro.
Signed-off-by: Stefan Beller
I realized next has not been rewound, so I can resend sb/more-repo-in-api,
which I hereby do. The changes are minimal and address the only comment
by Jonathan so far.
Thanks,
Stefan
Stefan Beller (23):
sha1_file: allow read_object to read objects in arbitrary repositories
packfile: allow has_
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit-reach.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/commit-reach.c b/commit-reach.c
index 67c2e43d5e..a53b31e6a2 100644
--- a/commit-reach.c
+++ b/commit-reach.c
@@ -95,7 +95,9 @@ static st
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
.../coccinelle/the_repository.pending.cocci | 30 +++
object-store.h| 22 ++
sha1-file.c | 15 ++
3 files changed, 56 insertions(
read_object_file_extended is not widely used, so migrate it all at once.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
object-store.h | 5 +++--
sha1-file.c| 11 ++-
streaming.c| 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/object-stor
As the function is file local and not widely used, migrate it all at once.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit-reach.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/commit-reach.c b/commit-reach.c
index 9f79ce0a22..67c2e43d
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit-reach.c | 15 +--
commit-reach.h | 12 ++--
contrib/coccinelle/the_repository.pending.cocci | 17 +
3 files changed, 36 inse
This converts the 'show_submodule_header' function to use
the repository API properly, such that the submodule objects
are not added to the main object store.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
submodule.c | 75 ++---
1
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit.h| 8
contrib/coccinelle/the_repository.pending.cocci | 9 +
pretty.c| 13 +++--
3 files changed, 24 insertions(+), 6 d
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit.c| 8 +---
commit.h| 7 ++-
contrib/coccinelle/the_repository.pending.cocci | 8
3 files changed, 19 insertions(+), 4 deletions(-
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
commit-reach.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/commit-reach.c b/commit-reach.c
index a53b31e6a2..81015830cb 100644
--- a/commit-reach.c
+++ b/commit-reach.c
@@ -156,7 +156,7 @@ struct co
In 8e4b0b6047 (object.c: allow parse_object to handle
arbitrary repositories, 2018-06-28), we forgot to pass the
repository down to the read_object_file.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
object.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --g
has_packed_and_bad is not widely used, so just migrate it all at once.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
packfile.c | 5 +++--
packfile.h | 2 +-
sha1-file.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/packfile.c b/packfile.c
index 841b3
Allow read_object (a file local functon in sha1_file) to
handle arbitrary repositories by passing the repository down
to oid_object_info_extended.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
sha1-file.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --
v2:
I reworded the commit messages to explain the patches from the ground up
instead of only linking to the old commits, that got reverted.
> Just pretend that the ealier commits and their reversion never
> happened, and further pretend that we are doing the best thing that
> should happen to our
When a submodules work tree is removed, we should unset its core.worktree
setting as the worktree is no longer present. This is not just in line
with the conceptual view of submodules, but it fixes an inconvenience
for looking at submodules that are not checked out:
git clone --recurse-submodu
74d4731da1 (submodule--helper: replace connect-gitdir-workingtree by
ensure-core-worktree, 2018-08-13) missed to update the BUG message.
Fix it.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/submodule--hel
When a submodule is deinit'd, the working tree is gone, so the setting of
core.worktree is bogus. Unset it. As we covered the only other case in
which a submodule loses its working tree in the earlier step
(i.e. switching branches of top-level project to move to a commit that did
not have the submo
As f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'",
2018-09-07) was produced shortly before a release, nobody asked for
a regression test to be included. Add a regression test that makes sure
that the invocation of `git submodule update` on old setups doesn't
produce errors as pointe
On Fri, Dec 14 2018, Derrick Stolee via GitGitGadget wrote:
> Despite these potential drawbacks, the benefits of the algorithm
> are clear. By adding a counter to 'add_children_by_path' and
> 'mark_tree_contents_uninteresting', I measured the number of
> parsed trees for the two algorithms in a
Hello, I have sent the transaction details.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
On Fri, Dec 14, 2018 at 6:10 PM John Passaro wrote:
>
> On Fri, Dec 14, 2018 at 11:49 AM Michał Górny wrote:
> >
> > On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> > > On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> > > >
> > > > On Thu, 2018-12-13 at 16:22 -0500, John Passaro w
On Fri, Dec 14, 2018 at 11:49 AM Michał Górny wrote:
>
> On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> > On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> > >
> > > On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > > > Currently, users who do not have GPG installed have n
On Fri, Dec 14 2018, Clement Moyroud wrote:
> My group at work is migrating a CVS repo to Git. The biggest issue we
> face so far is the performance of git blame, especially compared to
> CVS on the same file. One file especially causes us trouble: it's a
> 30k lines file with 25 years of histor
On Fri, Dec 14 2018, Josh Steadmon wrote:
> On 2018.12.14 21:20, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Nov 16 2018, Josh Steadmon wrote:
>>
>> I started looking at this to address
>> https://public-inbox.org/git/nycvar.qro.7.76.6.1812141318520...@tvgsbejvaqbjf.bet/
>> and was about to sen
On 2018.12.14 21:20, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Nov 16 2018, Josh Steadmon wrote:
>
> I started looking at this to address
> https://public-inbox.org/git/nycvar.qro.7.76.6.1812141318520...@tvgsbejvaqbjf.bet/
> and was about to send a re-roll of my own series, but then...
>
> > Cu
Thanks for looking to it - git attributes was added in
4b0863a8b834c5804fd3a568ed56ff85b27acdeb
The file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23
So you mean to say that because a gitattributes was added after the
fact this resulted in an illegal state?
But _shouldn't gi
Signed-off-by: Anthony Sottile
---
Documentation/git-update-index.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 1c4d146a4..9c03ca167 100644
--- a/Documentation/git-update-index.txt
+++ b/Docum
$ git --version
git version 2.19.2
Mac os mojave
Hmm the latest version here: https://git-scm.com/download/mac seems to
be this one - where do I get 2.20?
Thanks!
On Fri, Dec 14, 2018 at 4:22 PM John Passaro wrote:
>
> On Fri, Dec 14, 2018 at 4:08 PM Mr&Mrs D wrote:
> >
> > Hi all,
> >
> > I m
On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:
> Hi all,
>
> I maintain a python project you can clone from:
>
> g...@github.com:wrye-bash/wrye-bash.git
>
> For reasons unknown git sees a particular file as changed
> (Mopy/Docs/Bash Readme Template.html, sometimes others too). This fi
On 12/14/2018 1:29 PM, Clement Moyroud wrote:
My group at work is migrating a CVS repo to Git. The biggest issue we
face so far is the performance of git blame, especially compared to
CVS on the same file. One file especially causes us trouble: it's a
30k lines file with 25 years of history in 3k
From: Derrick Stolee
In preparation for a new algorithm that walks fewer trees when
creating a pack from a set of revisions, create a method that
takes an oidset of tree oids and marks reachable objects as
UNINTERESTING.
The current implementation uses the existing
mark_tree_uninteresting to rec
From: Derrick Stolee
The '--sparse' flag in 'git pack-objects' changes the algorithm
used to enumerate objects to one that is faster for individual
users pushing new objects that change only a small cone of the
working directory. The sparse algorithm is not recommended for a
server, which likely
From: Derrick Stolee
When enumerating objects to place in a pack-file during 'git
pack-objects --revs', we discover the "frontier" of commits
that we care about and the boundary with commit we find
uninteresting. From that point, we walk trees to discover which
trees and blobs are uninteresting.
From: Derrick Stolee
Create a test variable GIT_TEST_PACK_SPARSE to enable the sparse
object walk algorithm by default during the test suite. Enabling
this variable ensures coverage in many interesting cases, such as
shallow clones, partial clones, and missing objects.
Signed-off-by: Derrick Sto
From: Derrick Stolee
Add a '--sparse' option flag to the pack-objects builtin. This
allows the user to specify that they want to use the new logic
for walking trees. This logic currently does not differ from the
existing output, but will in a later change.
Create a new test script, t5322-pack-ob
On Fri, Dec 14, 2018 at 4:08 PM Mr&Mrs D wrote:
>
> Hi all,
>
> I maintain a python project you can clone from:
>
> g...@github.com:wrye-bash/wrye-bash.git
>
> For reasons unknown git sees a particular file as changed
> (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file
> was p
From: Derrick Stolee
When creating a pack-file using 'git pack-objects --revs' we provide
a list of interesting and uninteresting commits. For example, a push
operation would make the local topic branch be interesting and the
known remote refs as uninteresting. We want to discover the set of
new
One of the biggest remaining pain points for users of very large
repositories is the time it takes to run 'git push'. We inspected some slow
pushes by our developers and found that the "Enumerating Objects" phase of a
push was very slow. This is unsurprising, because this is why reachability
bitmap
Hi all,
I maintain a python project you can clone from:
g...@github.com:wrye-bash/wrye-bash.git
For reasons unknown git sees a particular file as changed
(Mopy/Docs/Bash Readme Template.html, sometimes others too). This file
was probably committed to the svn repository this git repo was created
On Fri, Nov 16 2018, Josh Steadmon wrote:
I started looking at this to address
https://public-inbox.org/git/nycvar.qro.7.76.6.1812141318520...@tvgsbejvaqbjf.bet/
and was about to send a re-roll of my own series, but then...
> Currently the client advertises that it supports the wire protocol
>
On Fri, Dec 14, 2018 at 10:29 AM Clement Moyroud
wrote:
>
> Hello,
>
> My group at work is migrating a CVS repo to Git. The biggest issue we
> face so far is the performance of git blame, especially compared to
> CVS on the same file. One file especially causes us trouble: it's a
> 30k lines file
The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.
Currently -G looks also into patches of binary files (which
according to [1]) is binary as well.
This has a couple of issues:
- It makes the pickaxe search slow. In a proprietary reposi
On Fri, Dec 14, 2018 at 9:47 AM Duy Nguyen wrote:
>
> On Fri, Dec 14, 2018 at 6:38 PM Duy Nguyen wrote:
> >
> > On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
> > >
> > > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > > > Even with a new ref storage, I'm pretty sure pseudo refs lik
On Fri, Dec 14, 2018 at 9:38 AM Duy Nguyen wrote:
>
> On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
> >
> > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> > > FETCH_HEAD... will forever be backed by filesystem.
> Junio C Hamano hat am 29. November 2018 um 08:22
> geschrieben:
>
>
> Junio C Hamano writes:
>
> >> +test_expect_success 'log -G ignores binary files' '
> >> + git checkout --orphan orphan1 &&
> >> + printf "a\0a" >data.bin &&
> >> + git add data.bin &&
> >> + git commit -m "message" &&
> Junio C Hamano hat am 29. November 2018 um 08:10
> geschrieben:
>
>
> Thomas Braun writes:
>
> > Subject: Re: [PATCH v2] log -G: Ignore binary files
>
> s/Ig/ig/; (will locally munge--this alone is no reason to reroll).
Done.
> The code changes looked sensible.
Thanks.
> > diff --git
> Ævar Arnfjörð Bjarmason hat am 28. November 2018 um 13:54
> geschrieben:
>
>
>
> On Wed, Nov 28 2018, Thomas Braun wrote:
>
> Looks much better this time around.
Thanks.
> > The -G option of log looks for the differences whose patch text
> > contains added/removed lines that match regex.
On Fri, Dec 14 2018, Johannes Schindelin wrote:
> Hi,
>
> this morning Travis sounded quite a few claxons:
> https://travis-ci.org/git/git/builds/467839114
>
> It seems that quite a few tests in t5601-clone.sh fail, the first of which
> reading like this:
>
> -- snip --
> expecting success:
>
Hello,
My group at work is migrating a CVS repo to Git. The biggest issue we
face so far is the performance of git blame, especially compared to
CVS on the same file. One file especially causes us trouble: it's a
30k lines file with 25 years of history in 3k+ commits. The complete
repo has 200k+ c
On Fri, Dec 14, 2018 at 6:38 PM Duy Nguyen wrote:
>
> On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
> >
> > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> > > FETCH_HEAD... will forever be backed by filesystem.
On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
>
> On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> > FETCH_HEAD... will forever be backed by filesystem. HEAD for example
> > is part of the repository signature and m
On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> FETCH_HEAD... will forever be backed by filesystem. HEAD for example
> is part of the repository signature and must exist as a file. We could
> also lookup pseudo refs with re
On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> >
> > On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > > Currently, users who do not have GPG installed have no way to discern
> > > signed from unsigned commits without exami
On Fri, 14 Dec 2018, Oliver Joseph Ash wrote:
> I believe I have found a bug in `git commit --fixup`.
>
> Steps to reproduce:
> 1. Create a git history with two commits (A and B) with the same
> commit message (e.g. foo)
> 2. Create a new commit using `git commit --fixup {SHA}`, referring to
> th
On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
>
> On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > Currently, users who do not have GPG installed have no way to discern
> > signed from unsigned commits without examining raw commit data. I
> > propose two new pretty-print placehold
--
Dear beneficiary,
You are one of the beneficiaries of $1 donation from IMF support program
For details contact: i...@visatmonline.com
Morris Sydor
Olivier Serge
On Fri, Dec 14, 2018 at 12:30:28PM +, Oliver Joseph Ash wrote:
> I believe I have found a bug in `git commit --fixup`.
That's not a bug, it's actually the documented behaviour of rebase
--autosquash.
As you figured out, the squash/fixup is based on whether the message
has the squash!/fixup! p
Hi Oliver,
On Fri, 14 Dec 2018, Oliver Joseph Ash wrote:
> I believe I have found a bug in `git commit --fixup`.
>
> Steps to reproduce:
> 1. Create a git history with two commits (A and B) with the same
> commit message (e.g. foo)
> 2. Create a new commit using `git commit --fixup {SHA}`, refer
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch allows '-m 1' for non-merge commit
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-cherry-pick-sequence.sh | 8 ++--
1
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch series allow '-m 1' for non-merge
Signed-off-by: Sergey Organov
---
t/t3502-cherry-pick-merge.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merge.sh
index b160271..3259bd5 100755
--- a/t/t3502-cherry-pick-merge.sh
+++ b/t/t3502-cherry-pick-me
Signed-off-by: Sergey Organov
---
t/t3506-cherry-pick-ff.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3506-cherry-pick-ff.sh b/t/t3506-cherry-pick-ff.sh
index fb889ac..127dd00 100755
--- a/t/t3506-cherry-pick-ff.sh
+++ b/t/t3506-cherry-pick-ff.sh
@@ -64,10 +64,1
Hi,
I believe I have found a bug in `git commit --fixup`.
Steps to reproduce:
1. Create a git history with two commits (A and B) with the same
commit message (e.g. foo)
2. Create a new commit using `git commit --fixup {SHA}`, referring to
the last commit SHA
3. Run an interactive rebase
Expected
Hi,
this morning Travis sounded quite a few claxons:
https://travis-ci.org/git/git/builds/467839114
It seems that quite a few tests in t5601-clone.sh fail, the first of which
reading like this:
-- snip --
expecting success:
git clone myhost:src ssh-clone &&
expect_ssh "-o SendEn
Hi Hannes,
On Thu, 13 Dec 2018, Johannes Sixt wrote:
> Am 13.12.18 um 07:25 schrieb Johannes Sixt:
> > Am 13.12.18 um 03:48 schrieb Junio C Hamano:
> > > So,... what's the conclusion? The patch in the context of my tree
> > > would be a no-op, and we'd need a prerequisite change to the support
>
Hi Brian,
On Fri, 14 Dec 2018, brian m. carlson wrote:
> On Wed, Dec 12, 2018 at 10:14:53AM -0800, Derrick Stolee via GitGitGadget
> wrote:
> >
> > diff --git a/.gitattributes b/.gitattributes
> > index acf853e029..3738cea7eb 100644
> > --- a/.gitattributes
> > +++ b/.gitattributes
> > @@ -13,3
On Fri, Dec 14 2018, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Dec 14 2018, Jeff King wrote:
>
>> On Thu, Dec 13, 2018 at 05:08:43PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>>> Now that we have this maybe we should discuss why these tests show
>>> different things:
>>>
>>> > diff --git a/t/t5500
On Fri, Dec 14 2018, Jeff King wrote:
> On Thu, Dec 13, 2018 at 05:08:43PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> Now that we have this maybe we should discuss why these tests show
>> different things:
>>
>> > diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
>> > index 086f2c40f6..
Hi Michael,
On Thu, 13 Dec 2018, Michael Rappazzo via GitGitGadget wrote:
> Pull-Request: https://github.com/gitgitgadget/git/pull/100
What a nice thing that the 100th GitGitGadget Pull Request is celebrated
by a new GitGitGadget user.
Pleased,
Johannes
Hi Erin,
On Thu, 13 Dec 2018, Erin Dahlgren wrote:
> setup_git_directory_gently() expects two types of failures to
> discover a git directory (e.g. .git/):
>
> - GIT_DIR_HIT_CEILING: could not find a git directory in any
> parent directories of the cwd.
> - GIT_DIR_HIT_MOUNT_POINT: cou
On Thu, Dec 13, 2018 at 04:58:16PM +0100, Ævar Arnfjörð Bjarmason wrote:
> From: Jonathan Tan
>
> Currently, if support for running Git's entire test suite with protocol
> v2 were added, some tests would fail because the fetch-pack CLI command
> dies if it encounters protocol v2. To avoid this,
I see that when I call "git apply --3way ..." on an index which was
previously created
by JGit and which contains smudged entries the command fails with
message "error: foo.txt:
does not match index". If I do a "git status" afterwards and then the
same "git apply --3way ..." it
succeeds. Looks like
On Thu, Dec 13, 2018 at 05:08:43PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Now that we have this maybe we should discuss why these tests show
> different things:
>
> > diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> > index 086f2c40f6..8b1217ea26 100755
> > --- a/t/t5500-fetch-pack.s
On Fri, Dec 14, 2018 at 12:12:01PM +0900, Junio C Hamano wrote:
> > I have a strange situation and need help with resolving funky characters in
> > .git/config. My situation is this:
> >
> > [diff "*.dat"]
> > textconv = enscribe-conv
> > --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d
On Fri, Dec 14, 2018 at 01:28:20AM -0800, Jonathan Nieder wrote:
> > Certainly if that information was carried from the client request it
> > would work fine, and ls-refs would have enough to know which config to
> > respect. But I could not find any documentation on this, nor discussion
> > of pl
Jeff King wrote:
> On Fri, Dec 14, 2018 at 12:36:21AM -0800, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> In protocol v2, instead of just running "upload-pack", we have a generic
>>> "serve" loop which runs command requests from the client. What used to
>>> be "upload-pack" is now generally spli
On Fri, Dec 14, 2018 at 12:36:21AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > In protocol v2, instead of just running "upload-pack", we have a generic
> > "serve" loop which runs command requests from the client. What used to
> > be "upload-pack" is now generally split into two operat
On Thu, Dec 13, 2018 at 10:54:50AM -0800, Jonathan Tan wrote:
> -static int parse_commit_in_graph_one(struct commit_graph *g, struct commit
> *item)
> +static struct commit *parse_commit_in_graph_one(struct repository *r,
> + struct commit_graph *g,
> +
Good day. My name is Mr.Donald Omeniru, please did you receive my
previous email to you?
Hi,
Jeff King wrote:
> In protocol v2, instead of just running "upload-pack", we have a generic
> "serve" loop which runs command requests from the client. What used to
> be "upload-pack" is now generally split into two operations: "ls-refs"
> and "fetch". The latter knows it must respect uploadp
1 - 100 of 102 matches
Mail list logo
