Hi all,
This simple two-line patch fixes a bug that makes gitweb unusable on
systems where the installed CGI.pm is version 4.04 or later (such as on
Debian unstable). That version removed the startform method, which had
previously been deprecated in favour of start_form since 2009.
I don't
On Thu, Oct 16, 2014 at 2:13 AM, Ben Aveling bena@optusnet.com.au wrote:
On 14/10/2014 19:21, Jeff King wrote:
On Mon, Oct 13, 2014 at 09:37:27AM +1100, Ben Aveling wrote:
A question about fsck - is there a reason it doesn't have an option to
delete bad objects?
If the objects are
Hi
I downloaded and started to Install Git.
There is a Virus on you setup.
Program that appears to have trojan-like features or behavior.
Git/bin/pdfinfo.exe
trojan.generic.[variant], gen:trojan.[variant]
Why???
Br.
Risto
--
To unsubscribe from this list: send the line unsubscribe git in
On Thu, 16 Oct 2014 12:35:33 +0300 (EEST)
risto.makini...@pp.inet.fi risto.makini...@pp.inet.fi wrote:
I downloaded and started to Install Git.
There is a Virus on you setup.
Program that appears to have trojan-like features or behavior.
Git/bin/pdfinfo.exe
trojan.generic.[variant],
Ben Aveling bena@optusnet.com.au writes:
And that seems sensible to me - the object is corrupt, it is unusable,
the object graph is already broken, we already have big problems,
removing the corrupt object(s) doesn't create any new problems, and it
allows the possibility that the damaged
On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote:
I simply copied the packfile containing the good copy into the
corrupted repo, and then ran a git gc, which happened to use the
good copy of the corrupted object and complete successfully (instead
of barfing on the bad copy). The
On Thu, Oct 16, 2014 at 2:25 PM, Jeff King p...@peff.net wrote:
On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote:
I simply copied the packfile containing the good copy into the
corrupted repo, and then ran a git gc, which happened to use the
good copy of the corrupted object and
Hi,
I've encountered an oddity with git describe.
Consider the following snippet:
-
mkdir test
cd test
git init
echo 1 file
git add file
git commit -m changes
$ git describe --always --dirty
8ad486e
$ cd ..
$ git --git-dir=test/.git describe --always --dirty
8ad486e-dirty
$ GIT_DIR=test/.git
For example:
git diff --color-words (echo a b c) (echo a d c)
Changes to struct diff_filespec:
- is_stdin renamed to skip_hashing, which is what it did
- follow_symlinks added, causing diff_populate_filespec to look at
file contents instead of the readlink value
Paths that are handled
On 14-10-15 05:50 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
Yes, but we're cloning gko, not the neighbour. Doesn't that mean that the
clone operation won't know about any of the neighbour's refs?
No. --reference (and a natural implementation of --borrow, I
I have relocated a file into another directory and committed that.
Using the --follow command on the NEW path of the file, I want to find
all commits to that file by a specific author:
$ git log --follow --author david -- new/path/to/file.cpp
When I do this, I get NO results. When I use the OLD
Johan Herland jo...@herland.net writes:
I simply copied the packfile containing the good copy into the
corrupted repo, and then ran a git gc, which happened to use the
good copy of the corrupted object and complete successfully (instead
of barfing on the bad copy). The GC then removed the old
Thomas Braun thomas.br...@virtuell-zuhause.de writes:
I've encountered an oddity with git describe.
Consider the following snippet:
-
mkdir test
cd test
git init
echo 1 file
git add file
git commit -m changes
$ git describe --always --dirty
8ad486e
$ cd ..
$ git
Jeff King p...@peff.net writes:
Otherwise, callers must do so or risk triggering warnings
-Wchar-subscript (and rightfully so; a signed char might
cause us to use a bogus negative index into the
hexval_table).
While we are dropping the now-unnecessary casts from the
caller in urlmatch.c,
Jeff King p...@peff.net writes:
This is not a lot of code, but it's a logical construct that
should not need to be repeated (and we are about to add a
third repetition).
Good, but I have two and a half tangential comments about the
context that appears in this patch ;-)
void
Jeff King p...@peff.net writes:
To find the set of reachable objects, we add a bunch of
possible sources to our rev_info, call prepare_revision_walk,
and then launch into a custom walker that handles each
object top. This is a subset of what traverse_commit_list
does, so we can just reuse
Brandon Turner bt at brandonturner.net writes:
On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano gitster at pobox.com wrote:
Actually the patch was slightly wrong. It did not quite matter as
cd '' is a no-op, but git -C '' cmd is not that lenient (which
may be something we may want to fix)
Jeff King p...@peff.net writes:
There is currently no easy way to ask the revision traversal
machinery to include objects reachable from the index (e.g.,
blobs and trees that have not yet been committed). This
patch adds an option to do so.
Signed-off-by: Jeff King p...@peff.net
---
I was
Am 16.10.2014 um 18:57 schrieb Junio C Hamano:
Thomas Braun thomas.br...@virtuell-zuhause.de writes:
I've encountered an oddity with git describe.
Consider the following snippet:
-
mkdir test
cd test
git init
echo 1 file
git add file
git commit -m changes
$ git describe --always
Junio C Hamano gits...@pobox.com writes:
Marc Branchaud marcn...@xiplink.com writes:
I think things would be more understandable if the option was --dissociate
repository and was an explicit alternative to --reference:
[[--reference | --dissociate] repository]
I'm still not liking the
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
core.filemode may better be set manually to false.
Update and improve the documentation.
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Torsten
Looks sensible to me; Jakub, ack?
Roland Mas lola...@debian.org writes:
Hi all,
This simple two-line patch fixes a bug that makes gitweb unusable on
systems where the installed CGI.pm is version 4.04 or later (such as on
Debian unstable). That version removed the startform method, which
Am 16.10.2014 um 21:29 schrieb Torsten Bögershausen:
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
core.filemode may better be set manually to false.
Update and improve the documentation.
Helped-by:
Hi,
On Thu, 16 Oct 2014, Thomas Braun wrote:
Am 16.10.2014 um 21:29 schrieb Torsten Bögershausen:
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
core.filemode may better be set manually to false.
Torsten Bögershausen tbo...@web.de writes:
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
core.filemode may better be set manually to false.
Update and improve the documentation.
Helped-by: Junio C
Jakub Narębski jna...@gmail.com writes:
On Thu, Oct 16, 2014 at 9:36 PM, Junio C Hamano gits...@pobox.com wrote:
Looks sensible to me; Jakub, ack?
Ack.
Nb. this code follows back to original gitweb.cgi by Kay Sievers, very
early in the development (2005)
Thanks. I realize that Ack
Michael Haggerty mhag...@alum.mit.edu writes:
This is a rif on Duy's oldish patch series [1]. I started reviewing
his patch series, but found that some of his patches did multiple
things, making it harder to review. I started pulling it apart into
smaller changes to aid my review, and I guess
On Wed, Oct 15, 2014 at 08:57:20PM +0200, Jens Lehmann wrote:
Am 15.10.2014 um 00:15 schrieb Max Kirillov:
I think the logic can be simple: it a submodule is not
checked-out in the repository checkout --to is called
from, then it is not checked-out to the new one also. If it
is, then checkout
Somewhere in this series the object enumeration seems to get
broken. git clone --no-local of git.git repository died
with
Cloning into 'victim-7'...
remote: Counting objects: 173727, done.
remote: Compressing objects: 100% (43697/43697), done.
remote: Total 173727 (delta 130908),
Junio C Hamano gits...@pobox.com writes:
Somewhere in this series the object enumeration seems to get
broken. git clone --no-local of git.git repository died
with
Cloning into 'victim-7'...
remote: Counting objects: 173727, done.
remote: Compressing objects: 100%
On Thu, Oct 16, 2014 at 02:07:47PM -0700, Junio C Hamano wrote:
Somewhere in this series the object enumeration seems to get
broken. git clone --no-local of git.git repository died
with
Cloning into 'victim-7'...
remote: Counting objects: 173727, done.
remote: Compressing
On Thu, Oct 16, 2014 at 05:21:12PM -0400, Jeff King wrote:
Hrm. I cannot reproduce the clone failure...
Oh, because I have bitmaps turned on, and we do not run the list-objects
code at all in that case.
The bug unsurprisingly bisects to traverse_commit_list: support
pending blobs/trees with
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
Junio C Hamano gits...@pobox.com writes:
Michael Haggerty mhag...@alum.mit.edu writes:
This is a rif on Duy's oldish patch series [1]. I started reviewing
his patch series, but found that some of his patches did multiple
things, making it harder to review. I started pulling it apart into
Jeff King p...@peff.net writes:
On Thu, Oct 16, 2014 at 05:21:12PM -0400, Jeff King wrote:
Hrm. I cannot reproduce the clone failure...
Oh, because I have bitmaps turned on, and we do not run the list-objects
code at all in that case.
;-)
We should probably add a test for cloning a tag
From: brian m. carlson sand...@crustytoothpaste.net
This series is designed to implement the changes necessary to build
Git
using Asciidoctor instead of AsciiDoc.
[..]
Even with these patches, Asciidoctor warns about everyday.txt and
user-manual.txt. I'm not sending patches for these right
On 10/16/2014 10:47 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This is a rif on Duy's oldish patch series [1]. I started reviewing
his patch series, but found that some of his patches did multiple
things, making it harder to review. I started pulling it apart
On 10/15/2014 02:45 AM, Jonathan Nieder wrote:
This series by Ronnie was last seen on-list at [1]. It includes some
improvements to the ref-transaction API, improves handling of poorly
named refs (which should make it easier to tighten the refname format
checks in the future), and is a
On Wed, Oct 15, 2014 at 10:06 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
As far as I know, Duy isn't actively working on this, so I hope my
reroll is not unwelcome.
I couldn't be happier that someone does the work for me and I still
benefit from it ;)
--
Duy
--
To unsubscribe from this
--
Are you in a financial distress? do you need financial assistant to
start up a business or to pay bills? we offer loans to individual's and
company investors at 3% interest rate.Email us at adeyemisu...@gmail.com
Fill out the details below:
Full name:
Country:
Address:
State:
Zip code:
On Thu, Oct 16, 2014 at 03:18:34PM -0700, Junio C Hamano wrote:
We should probably add a test for cloning a tag of an otherwise
unreferenced object, too.
Yeah, that too ;-)
Here's that test (after the scissors below). It can be applied totally
separately, though I stuck it in as patch
On Thu, Oct 16, 2014 at 11:41:35AM -0700, Junio C Hamano wrote:
I agree that --index is a bad name as it usually is used in a
particular context: the command can work on various combination of
working tree and the index, and I am asking it to work on both
(e.g. apply --index as opposed to
[subject tweaked as we have veered quite far off the original, and
this might get more attention from interested people]
On Thu, Oct 16, 2014 at 10:39:54AM -0700, Junio C Hamano wrote:
2. We use object_array_remove_duplicates() to de-dup git bundle
create x master master, which came
On Thu, Oct 16, 2014 at 08:12:31PM -0400, Jeff King wrote:
--indexed-objects (short for --show-objects-in-the-index) or
something?
That sounds reasonable. We could technically do `--indexed` as that is
different from `--index`, but maybe they are still confusingly close.
Here's a re-roll
This does the same thing as our custom code, so let's not
repeat ourselves.
Signed-off-by: Jeff King p...@peff.net
---
reachable.c | 52 +---
1 file changed, 1 insertion(+), 51 deletions(-)
diff --git a/reachable.c b/reachable.c
index
There is currently no easy way to ask the revision traversal
machinery to include objects reachable from the index (e.g.,
blobs and trees that have not yet been committed). This
patch adds an option to do so.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/rev-list-options.txt | 5
This saves us from having to bump the rp_av count when we
add new traversal options.
Signed-off-by: Jeff King p...@peff.net
---
builtin/pack-objects.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index
When we pack all objects, we use only the objects reachable
from references and reflogs. This misses any objects which
are reachable from the index, but not yet referenced.
By itself this isn't a big deal; the objects can remain
loose until they are actually used in a commit. However, it
does
When we are given an expiration time like
--unpack-unreachable=2.weeks.ago, we avoid writing out old,
unreachable loose objects entirely, under the assumption
that running prune would simply delete them immediately
anyway. However, this is only valid if we computed the same
set of reachable
If a pack.packSizeLimit is set, we may split the pack data
across multiple packfiles. This means we cannot generate
.bitmap files, as they require that all of the reachable
objects are in the same pack. We check that condition when
we are generating the list of objects to pack (and disable
bitmaps
On Thu, Oct 16, 2014 at 09:13:39PM -0700, Junio C Hamano wrote:
Just being curious, but would the same bug, if allowed to be triggered
cutting repacking of your repository, have corrupted the resulting bitmap?
I didn't test, but yes, almost certainly. The bug was in list-objects.c,
which is
51 matches
Mail list logo
